Spring CVEs Didn't Slow Down. June 2026 Brought 67.

TL;DR: The Spring ecosystem published 67 CVEs in June 2026, including 27 High Severity CVEs. HeroDevs patched everything in less than 1 week. This includes 2x the commercial lines that Broadcom supports or even evaluates for impact.

Something is happening with Spring

In March and April 2026, the Spring ecosystem published 37 CVEs. In June, Spring published 67 CVEs in a single month. This brings the total for 2026 to 112. For comparison, 17 CVEs were disclosed in all of 2025. We wrote about the first spike when it happened in Spring CVEs Surge in 2026, and the obvious question was whether it was a one-time clustering of advisories or a new baseline.

‍

What June actually delivered

Of June's 67 CVEs, 27 were rated High and 34 were rated Medium. That puts High-severity issues at roughly 40 percent of everything published in the month. For all of 2025, High or above accounted for about 20 percent of Spring CVEs. June 2026 alone brought almost a 4x increase to the number of CVEs compared to all of 2025, with the High severity CVE percentage doubling.

The surge was not confined to one corner of the portfolio. It reached across the whole ecosystem, with the heaviest concentrations here:

• Spring Framework: 18 CVEs, more than a quarter of the month, spanning the SpEL engine, the web stack, JMS, and static resource handling.
• Spring Web Services: 7 CVEs across WS-Security and the XML and SOAP layers.
• Spring Security: 6 CVEs, including SAML and X.509 authentication issues.
• Spring Data: 12 CVEs across Commons, Data REST, MongoDB, Relational, and KeyValue combined, which makes the data tier the second most affected area after the framework itself.
• Spring for GraphQL and Spring Kafka: 3 CVEs each, including remote code execution and unsafe deserialization.

The remaining advisories landed across Spring Boot, AMQP, HATEOAS, Web Flow, Integration, LDAP, Pulsar, Statemachine, Cloud Gateway, Cloud Sleuth, Retry, Authorization Server, and Spring AI. The complete per-CVE breakdown, with severity, affected versions, and the Boot lines each one maps to, is published in the data table at the bottom of this page and in the HeroDevs Vulnerability Directory.

‍

The CVEs that never reach your scanner

Here is the part that does not show up in a headline count, and the part that separates how HeroDevs and Broadcom treat an end-of-life version.

When Broadcom ends commercial support for a Spring version, it does not just stop shipping patches for that line. It stops evaluating new vulnerabilities against it. A researcher reports a flaw, Broadcom and the OSS Spring team confirm it against the branches they still support, and the advisory lists those branches. Older lines that have rolled off commercial support are not in the analysis, so they are not in the advisory.

That absence is what makes a CVE silent. The vulnerable code is still sitting in your runtime. The advisory simply never names your version, so your scanner has nothing to match against and reports you as clean. An attacker reading the same advisory and the same source history does not have that blind spot. They can see the flaw is present in your branch whether or not anyone wrote it down.

HeroDevs Never-Ending Support watches more lines than Broadcom does, and it evaluates every new advisory against the exact versions our customers run. In the June batch alone, the count of CVEs that are silent for a given line, meaning HeroDevs analyzed and patched them while no upstream or commercial fix names that version, breaks down like this:

• Spring Boot 1.5 Generation: 21 silent CVEs
• Spring Boot 2.5 Generation: 21 silent CVEs
• Spring Boot 3.2 Generation: 24 silent CVEs

These are confirmed vulnerabilities, present in widely deployed Boot lines, that a standard scanner will not surface because the advisories that drive the scanner were never run against those versions.

‍

The next wave of silent CVEs is already set up

This problem grows on a schedule, and the schedule just advanced.

Spring Boot 3.3 and Spring Framework 6.1 have now reached their end of Broadcom commercial support. From this point forward, new advisories are evaluated against the lines still in support, and those two are no longer on the list.

Run June's numbers through that change to see what it means. Fifteen of June's CVEs were Spring Framework issues that affected version 6.1. If that same disclosure had landed one month later, with Framework 6.1 already off the commercial support list, not one of those 15 would have been evaluated against Spring Framework. They would not have disappeared from the codebase. They would have disappeared from the paperwork. The exposure stays, the documentation that scanners rely on goes quiet, and every team still running those versions inherits a gap they cannot see.

This is the pattern repeating. Each version that ages out of Broadcom's support window converts from "patched late" to "not evaluated at all," and the silent CVE count climbs with it.

‍

What HeroDevs patches that upstream no longer touches

Step back from a single month and look at the full backlog that has accumulated since open source updates stopped for each Boot line. Every one of these is patched by HeroDevs. Not all of them are patched by Broadcom, and some are silent, meaning they are never evaluated against the version at all.

• Spring Boot 1.5 Generation: 56 CVEs
• Spring Boot 2.5 Generation: 96 CVEs
• Spring Boot 2.7 Generation: 97 CVEs
• Spring Boot 3.2 Generation: 79 CVEs
• Spring Boot 3.3 Generation: 79 CVEs
• Spring Boot 3.4 Generation: 52 CVEs

‍

Read down that list and the posture problem comes into focus. Every Spring Boot line below the current release carries a backlog that only grows, from 52 on the newest end-of-life branches to 97 on Spring Boot 2.7 generation projects, and none of it shrinks on its own. As time goes on older branches not only get more CVEs that impact them, the number of silent CVEs also increases.

‍

How to stay protected

At 2025's rate, slow patch cycles and lingering on an unsupported version were survivable for many teams. At a rate that puts 67 CVEs on the board in a single month, with the severity mix shifting up and whole version lines aging out of evaluation, that approach stops working.

Where your application sits on the support curve decides your real exposure.

HeroDevs Never-Ending Support for Spring is built for every line below the current OSS release. NES for Spring Boot delivers patches for your specific Spring Boot version with a long history of fast remediation times, and it includes the analysis Broadcom drops once a version leaves commercial support. For every CVE that Spring publishes, HeroDevs performs a full analysis and a determination of whether each new advisory applies to the exact NES for Spring version you run. If a move to 4.x is on the roadmap but not imminent, NES covers the gap. If staying put is the plan, NES is the coverage outright.

The Spring threat environment is not slowing down, and the list of versions nobody else is evaluating is getting longer every quarter. Your patch coverage should not have a cutoff date that your applications do not.

Talk to HeroDevs about your specific Spring exposure.

You can find the full CVE list below, complete with the expert analysis from HeroDevs. You can find the complete list of Spring CVEs at the Spring End-of-Life Resource Hub or a full list of all CVEs we remediate in the HeroDevs Vulnerability Directory. 

‍