Spring CVEs Surge in 2026: 30 Vulnerabilities in Two Months

In March 2026, the Spring ecosystem published 11 CVEs. In April 2026, it published 19 more. March alone produced nearly 4x as many CVEs as the busiest single month of 2025 (3 CVEs), and April produced more than 6x.

Combined, March and April 2026 produced 30 CVEs, nearly double what the Spring ecosystem disclosed in all of 2025 (17). Two months outpaced a full calendar year by a wide margin.

The numbers

All of 2025: 17 CVEs. 1 Critical, 2 High, the rest Medium or Low. The year's busiest month topped out at 3 CVEs.

March and April 2026: 30 CVEs. 4 Critical, 10 High, 13 Medium, 3 Low.

That's 4x as many Critical CVEs and 5x as many High CVEs in two months of 2026 as the Spring ecosystem produced in all of 2025. The pace is faster and the severity mix has shifted up.

‍

What's being disclosed

The surge isn't concentrated in any single project. It spans the breadth of the Spring portfolio:

• Spring Boot: 10 CVEs, including a Critical (CVE-2026-40976) and 4 High-severity issues. A single April 23 release accounted for 8 of them, including the Critical.
• Spring Security: 8 CVEs, including Criticals in both the Authorization Server (CVE-2026-22752) and Spring Security itself (CVE-2026-22732).
• Spring Framework, Spring MVC, and WebFlux: 5 CVEs across the web stack.
• Spring Cloud Gateway and Spring Cloud Config: 2 CVEs across the edge and config layer.
• Spring AI: 5 CVEs, including a Critical (CVE-2026-22738). A newer project reaching the same advisory cadence as the rest of the ecosystem.

For the full per-advisory breakdown (CVSS scores, vectors, and affected versions), see the HeroDevs vulnerability directory.

What's also new is the rhythm of batched, multi-CVE advisories. In 2025, multi-advisory months were the exception. In 2026, they are the pattern. April 2026 alone saw 8 Spring Boot CVEs disclosed on a single day and 7 Spring Security CVEs disclosed two days earlier.

‍

This isn't stopping

The drivers behind the surge aren't temporary. Research tooling has stepped up, some of it AI-assisted, meaningfully lowering the activation energy to find real vulnerabilities in mature Java frameworks.

These inputs compound. They don't revert. If this is what Spring's discovery rate looks like in 2026, it is what every other widely deployed server-side ecosystem will look like next.

‍

How to stay protected

At 2025's rate, many teams could get away with slow patch cycles, delayed upgrades, and running Spring versions that had dropped out of upstream support. At 2026's rate, that math breaks.

Every Spring advisory names the supported branches that receive the fix. If you're running older lines, including Spring Boot 2.x, Spring Framework 5.x, or unsupported Spring Security versions, you are, by definition, not getting the patch upstream. A 17-CVE year stretched that risk out. A rate that puts 30 CVEs on the board in two months collapses it.

This is what HeroDevs Never-Ending Support for Spring is built for. NES keeps your end-of-life Spring components patched so you can stay on the version your applications are built around without accumulating unpatched vulnerabilities. The Spring threat environment isn't slowing down. Your patch coverage shouldn't stop either, regardless of where your application sits on the upstream support curve.

Talk to HeroDevs about Spring NES →

‍

Which Spring Boot version are you on?

Not every Spring Boot line is exposed the same way. What matters is where your version sits on the support curve, and whether new CVEs are even being evaluated against it.

‍

If you're on 4.0, upstream is on your side. Patches arrive first, and your scanner is looking at a line the OSS Spring team actively maintains.

If you're on 3.5, upstream is still on your side for now, but not for long. July 2026 is a few months away, which is a shorter window than most enterprise migration plans assume. Start now.

If you're on 3.4, 3.3, or 2.7, the open source branch has moved on. The only way to stay protected is with a commercial or enterprise support plan.

The last group is where the risk gets harder to see. For 3.2, 2.5, and 1.5, the issue isn't only that patches aren't shipping to your branch. It's that new CVEs aren't evaluated against these versions at all. When an advisory lands, it names the branches researchers analyzed. Older lines that aren’t in enterprise support from Broadcom aren't in that list. The vulnerability may still be present in your runtime. It just doesn't show up in your scanner, because your scanner is matching against advisories that don't mention your version. Attackers doing their own reading don't have that gap.

This is where HeroDevs Never-Ending Support for Spring excels: patches for your specific Spring Boot line, on the same response window as upstream, including analysis of whether each new advisory applies to the exact version your applications run on. If upgrading to 4.x is on your roadmap but not imminent, NES is the coverage in the meantime. If upgrading isn't viable, NES is the coverage full stop.