Blog

June 25, 2026

Patching Spring CVEs in the Age of AI

Matthew Weier O’Phinney
Matthew Weier O’Phinney

Spring,

Security

As AI rewrites the rules of software security, the Spring ecosystem is feeling the impact in real time. Foundation models can now analyze codebases at a scale and speed no human security team can match, and the result is a flood of newly discovered Spring CVEs. According to The New Stack, monthly security advisories reported to Broadcom by the Spring community increased by 18x, or 1,700%, from March to April 2026. Spring runs in more than half of Fortune 500 companies, which puts it squarely at the center of this disruption.

The bottleneck has shifted. Finding Spring vulnerabilities is not the challenge; remediating them fast enough is. The patching window has become very small — and low-severity flaws are increasingly chained together into more dangerous exploits.

This blog walks through some of the recently disclosed high-severity Spring CVEs, the trade-offs that come with upstream patches, Tanzu commercial support, and long-term support, and how to keep legacy Spring applications secure when frequent upgrades simply aren't feasible.

Back to top

How AI Changed the Spring Threat Model

First, let’s acknowledge that this is a structural change in the security landscape, not a one-release problem. Frontier model-based scanning and validation workflows are surfacing Spring vulnerabilities in code that has been running quietly in production for years. What once stayed hidden is now exposed at machine speed.

For Java developers, architects, and engineering leaders, the stakes keep getting bigger. The State of Open Source Report identified several maintenance, security, and compliance challenges impacting enterprise Java teams. A significant number of teams are still running EOL versions of Spring Boot and Spring Framework, and with this influx of vulnerabilities, the risk of unpatched Spring dependencies is only going to grow.

Spring is a particularly high-value target because of its deep, transitive dependency graphs. Spring Boot 4.0 alone manages 1,768 dependencies. Every one of those libraries expands the attack surface, and a single outdated dependency can cascade into CVE exposure, build instability, and unresolvable version conflicts.

Back to top

What Are the Recent Spring CVEs?

New Spring CVEs continue to affect both current and end-of-life (EOL) versions of Spring Boot, Spring Framework, and the Spring Security component. Here are several recent disclosures worth your attention — all of which have been patched in OpenLogic Spring LTS:

CVESeverityDescriptionVersions Affected
CVE-2026-227329.1 (Critical)Improper handling of HTTP response headers under certain configurations, potentially impacting security controlsSpring Security 5.7.0 through 7.0.3
CVE-2026-227338.1 (High)Spring Boot applications with Actuator can be vulnerable to an "Authentication Bypass" vulnerability when an application endpoint that requires authentication is declared under the path used by the CloudFoundry Actuator endpoints.Spring Boot 2.7.0 through 4.0.3
CVE-2026-409737.0 (High)ApplicationTemp reused its temp directory without verifying ownership or permissions, allowing a local attacker on shared systems to pre-create or hijack it and access or modify application files.Spring Boot 2.7.0 through 4.0.5
CVE-2026-409757.5 (High)RandomValuePropertySource used java.util.Random for ${random.value}, which is not secure for secret generation and can produce guessable values.Spring Boot 2.7.0 through 4.0.5
CVE-2026-227455.3 (Medium)A Denial of Service (DoS) vulnerability in Spring MVC and WebFlux on Windows allowed malicious requests to exhaust server threads via slow filesystem path resolution.Spring Framework 5.3.0 through 7.0.6

The business stakes are significant. According to IBM, the average cost of a data breach has reached the multimillion-dollar range, and a successful Remote Code Execution (RCE) or Denial of Service (DoS) exploit can halt revenue-generating services entirely. For a deeper breakdown of EOL-specific threats, see this blog on managing end-of-life Spring vulnerabilities.

Back to top

Your Patching Options: Upstream, Tanzu, or LTS

The right Spring patching strategy depends on your team's capacity to upgrade and your tolerance for vendor lock-in. 

Option 1: Stay Current and Patch Upstream

If your team can upgrade frequently and stay on community-supported versions, you can pull patches directly from open source. 

However, Spring Framework lifecycle is fast, following a six-month, time-based release cadence aligned with OpenJDK. After factoring in testing delays, organizations realistically get about a year of community coverage. After that, versions out of community support receive no security updates at all. 

Some teams are not able to pull off an upgrade every 12 months. There's also this wrinkle: per Broadcom (and reported in SD Times), the Spring community will get access to patches after paying Tanzu commercial customers. 

Option 2: Pay for a Tanzu Spring Subscription

Broadcom’s commercial Spring offering does include extended support for Spring Boot 2.7, 3.3, and 3.4, Spring Framework 5.3 and 6.1, and Spring Security 5.7, 5.8, 6.3, and 6.4. However, this is an expensive path that may be out of budget for smaller organizations. 

This path also deepens your reliance on Broadcom, whose position as Spring’s lone committer continues to be a point of friction within the broader developer community. Longtime open source users have seen this kind of stewardship go sideways before and the risk of vendor lock-in is high.  

Read in-depth comparison of Tanzu Spring vs. Open Source Spring >>

Option 3: Long-Term Support 

Long-term support from vendors like OpenLogic exists for teams that cannot upgrade one to two times per year and want to avoid both EOL exposure and being locked in with Broadcom. This addresses a genuine market gap: according to Broadcom, roughly 60% of Spring runtimes being downloaded are older versions already out of community support.

Explore OpenLogic Spring LTS
 

Back to top

Dependency Management Checklist

Regardless of which patching path you choose, sound dependency management is essential. This vendor-neutral checklist will help:

  1. Audit: Identify all dependencies, including transitive ones, using mvn dependency:tree or Gradle's dependencies task.
  2. Govern: Implement policies for version control, approved dependencies, and continuous security scanning — ideally through an internal repository.
  3. Stabilize: Use dependency locking and reproducible builds to prevent unexpected runtime breakage.
  4. Migrate: Plan incremental, well-tested upgrades rather than deferring to a single high-risk jump, and include performance testing under realistic load.

Video 

Tips for Navigating Spring Dependencies 

Watch Full Webinar 
Back to top

Final Thoughts

Unfortunately, the spike in Spring CVEs this year is likely not an anomaly — it may be the new baseline.

The right response depends on your organization's capacity to upgrade and its tolerance for vendor lock-in risk. Teams that can move quickly may stay upstream. Teams that prioritize day-zero certainty may choose Tanzu. For organizations running legacy or soon-to-be-EOL Spring versions, long-term support is the pragmatic middle path.

OpenLogic Spring LTS provides backported security patches for EOL Spring Boot and Spring Framework, allowing teams to stay secure without a disruptive, time-consuming migration. 

Benefits:

  • Coverage: Spring Boot 2.7, 3.2, 3.3, 3.4; Spring Framework 5.3, 6.0, 6.1, 6.2; Spring Security 5.7, 5.8, 6.1
  • Security: Patches for critical CVEs (CVSS score 9.0 or higher) within 14 days and high-severity CVEs within 30 days (CVSS 7.0 or higher).
  • Supply Chain Assurance: Builds that pass security scans, addressing the same supply-chain integrity concerns driving the broader industry response.
  • Support: 1-hour response times, 24x7 break/fix support, and production deployment assistance available at the premium level. 

Ultimately, LTS is not about avoiding upgrades indefinitely. It is an insurance policy that buys planning time and keeps applications safe from vulnerabilities that, if exploited, could wreak operational, financial, and/or reputational havoc. Explore OpenLogic Spring Long-Term Support to avoid rushing an upgrade.

Additional Resources

Back to top