Spring Boot 3.5 shipped in May 2025 with roughly 13 months of open-source support. On June 30, 2026, that support ends - no more security patches reach Maven Central. Every CVE disclosed after that, in Spring Boot or anywhere in its dependency tree, stays open in 3.5 unless you upgrade to 4.0 or pay for commercial extended support. Your apps keep running. The attackers keep reading the advisories.
End of life isn't a kill switch. Spring Boot 3.5 keeps running exactly as it did the day before. What stops is the steady stream of patches that quietly kept it safe - and that absence only becomes visible the next time a CVE lands.
After June 30, no new 3.5.x releases ship to Maven Central. The last patched version is the last one upstream will publish - while your builds keep pulling it indefinitely.
When a new CVE hits, it gets fixed in 4.0.x. To consume that fix you have to be on 4.0. Staying on 3.5 means watching the patch ship to a version you're not running.
A Spring Boot app pulls in hundreds of transitive dependencies. EOL freezes the curated, tested versions Spring managed for you - so a CVE deep in the tree no longer gets a coordinated bump.
Spring Boot ships a new minor roughly every six months, and each one gets about a year of open-source support. The 3.x line is being retired version by version - 3.5 is the last 3.x release, and its OSS clock runs out in days.
The last 3.x release loses OSS support before most teams finish migrating off it. The official answer is "upgrade to 4.0 or buy extended support." Seal gives you a third answer: stay on 3.5 and stay patched.
When OSS support ends, the Spring ecosystem points you at exactly three paths. Two of them are expensive in time or money. The third is a security gamble.
Seal backports security fixes to the version you actually run. When a CVE hits Spring Boot 3.5 or anything in its dependency tree, we ship a verified, tested patch as a drop-in build - same version coordinates, same API, no upgrade to 4.0 required. As we showed in our previous research, waiting on the upstream timeline is no longer safe in the age of agentic exploitation - and an EOL version has no upstream timeline at all.
No framework upgrade, no Jackson migration, no breaking changes. Your code and your build stay exactly as they are.
When a CVE lands in Spring Boot 3.5 or a transitive dependency, Seal produces a verified, tested patch against your version - not just the latest one.
The patched artifact ships with version-compatible coordinates through Seal's CLI. Your dependency tree resolves to a fixed build with no code changes.
Open-source support ends June 30, 2026 - no new 3.5.x patches reach Maven Central after that. Commercial extended support from Broadcom (VMware Tanzu) is available, for a fee, through June 30, 2032.
Nothing breaks on day one - the app runs as before. What stops is security patching. Any CVE disclosed after June 30, 2026 in Spring Boot 3.5 or its dependency tree gets no free fix for the 3.5 line, so exposure builds up over time.
4.0 is the OSS-supported path, but it's a major migration: Spring Framework 7, a Jackson 2→3 migration, a higher Java baseline, and removed deprecations. You can also pay for commercial extended support, or use Seal to keep getting backported patches for 3.5 without upgrading.
Seal backports security fixes to the version you run. When a CVE affects 3.5 or a transitive dependency, Seal ships a verified, tested patch as a drop-in build with version-compatible coordinates, installed through Seal's CLI. No code changes, no framework upgrade.
Don't rush a 4.0 migration or sign an extended-support contract just to keep the patches flowing. Seal already covers Spring Boot and its dependency ecosystem - scan your stack and see exactly what stays patched past end of life.