Spring Boot 3.5 EOL: Scanner Findings, Audit Risk, and Remediation Options

A scanner flags your Spring Boot 3.5 application... Maybe it shows up as multiple Critical vulnerabilities. Maybe InfoSec finds it first and drops it into an audit report.

Either way, the conversation changes quickly. You are no longer debating whether this needs attention. You are deciding which path actually fits the situation.

Most teams end up considering the same options: migrate, patch it themselves, get covered while the migration continues, or accept the risk for now. Each option can be the right answer in the right situation. 

Each one also breaks if the timeline, team capacity, or audit pressure does not match the plan.

‍

Initial Strategies: Migrate, Patch Ourselves, or Seek a Third-Party Solution

Migrate to Spring Boot 4.0. This is the cleanest path for teams with a small application footprint, strong test coverage, clear ownership of each service, realistic release windows, and low dependency complexity. 

The work itself is a platform shift, not a version bump: 83 documented breaking changes across Jakarta EE 11, Servlet 6.1, Jackson 3, Spring Security 7, and the new modular auto-configuration model, with effort ranging from 200 to 500 hours per application. 

Where this path breaks is portfolio scale and audit timing: large application counts, shared internal libraries, weak test coverage on the Security or Jackson layer, and audit deadlines that arrive before the migration can finish. Steve Poole's Spring Boot 4.0 Migration Guide walks the full change surface and the tiered effort estimates behind it.

Patch the legacy version in-house. A reasonable instinct at low CVE volume. The operating model: monitor upstream advisories, determine applicability to the pinned Boot BOM, override affected dependency versions, validate compatibility with the rest of the dependency graph, regression-test, deploy through existing CI/CD, and produce audit evidence for every fix. AI tools accelerate the mechanical edits. 

This path stops working when CVEs arrive faster than the team can absorb them, when ownership spans multiple Boot lines or multiple application teams, when ownership of the patching workflow itself is unclear, or when security and audit need proof of remediation faster than engineering can validate it. 

Bob McNees' Spring CVEs Surge in 2026 documents 37 Spring CVEs across March and April 2026 alone, more than all of 2025 combined. That pace is now the baseline for the future

Seek a third-party solution. HeroDevs Never-Ending Support fits when migration is the right answer but the team cannot finish before the EOL window closes, or when self-patching is creating recurring engineering and evidence burden the team needs to shed. 

The coverage removes the ad hoc BOM overrides, the unmanaged dependency decisions, the per-CVE documentation cycle, and the scanner-and-audit uncertainty that comes with running an unsupported version. 

What it adds: CVE coverage at the original Maven coordinates, signed artifacts, advisory analysis suitable for audit evidence, and continuous coverage of the managed dependency graph while migration proceeds at the team's pace. 

The cost question is not "how much does this cost?" but "how much do the other options cost in engineer-hours, elapsed weeks, and evidence work?" The HeroDevs Spring Boot 3 to 4 Migration Calculator prices the migration side, so the comparison is real.

Accept the risk, briefly. Documenting the exposure, filing a compensating-control exception, and revisiting in six months is a real option that might work for  low-risk internal applications, systems already on the decommissioning calendar, or short-lived exceptions while a known remediation path completes. 

It stops working when the application is customer-facing, regulated, revenue-relevant, or repeatedly flagged by scanners. 

The option does not remediate the finding; it documents around it. Every new CVE adds another exception to track, another signature to chase, and another conversation with internal audit that gets progressively harder to win.

The right choice depends on the math most teams have not done yet: application count, dependency surface, engineering capacity, CVE pace tolerance, and audit timing. Run the calculator. Read the migration guide. Look at the CVE pace data. If the numbers say you can migrate before the finding becomes a compliance issue, migrate. If they do not, talk to HeroDevs about NES for Spring.

‍

Related Reading

• Mark Szymanski, Spring Boot 3.5 EOL: What the Migration Really Takes. The foundational analytical piece on what the migration costs.
• Bob McNees, Spring CVEs Surge in 2026: 37 Vulnerabilities in Two Months. The CVE velocity story behind the urgency.
• Erik Weibust, Spring Boot Managed Dependencies Still Get CVEs After EOL: May 2026 Patch Round-Up. What the dependency graph actually looks like under EOL.
• Steve Poole, Crossing the River Styx: Spring Boot 3.5 and the Zombie Dependency Problem
• HeroDevs Never-Ending Support for Spring.