Spring Boot End of Life: EOL Dates for 2.7, 3.x and 4.x

Spring Boot end of life comes in two stages: free open source (OSS) support ends first, and commercial support from Broadcom's Tanzu Spring ends later. As of October 2026, only Spring Boot 4.0 and 4.1 still receive OSS fixes. Spring Boot 3.5 left OSS support on 30 June 2026 and Spring Boot 2.7 on 30 June 2023; their commercial support runs to 30 June 2032 and 30 June 2029. Spring Boot 3.4 commercial support ends 31 December 2026, and every older 2.x and 3.x line is fully past end of life. The dates below come from the support table on spring.io, checked on 9 October 2026.

Spring Boot EOL dates by version

Two lines stand out. Spring Boot 2.7, the last 2.x release, and Spring Boot 3.5, the last 3.x release, both carry an extended commercial window. The final public 2.7 build was 2.7.18 in November 2023, while commercial customers have since received releases up to 2.7.35. Spring first extended 2.7 commercial support in September 2024 to the end of 2026; the table now shows June 2029.

How the Spring Boot support policy works

Spring Boot publishes a new major or minor version every six months, in May and November. The support policy promises at least 12 months of OSS support for each minor version and at least three years for each major version, provided you stay on a supported minor. There is no LTS release in the open source project. Longer support is a commercial product: Broadcom sells it through Tanzu Spring, which bundles Spring, OpenJDK and Apache Tomcat binaries. On Spring security advisories, fixes for lines past OSS support are labeled "Enterprise Support Only".

Spring Framework and Spring Security dates behind each Boot line

Spring Boot pins the Spring Framework and Spring Security versions it manages, so their end of life dates matter just as much.

What end of life means: no public CVE fixes

An EOL Spring Boot application keeps running. What stops is the supply of public security patches, and the advisories on spring.io/security show it clearly:

• CVE-2025-41242 (August 2025), a Spring Framework path traversal issue: fixed in open source 6.2.10, but the 5.3.44 fix for Spring Boot 2.7 users is Enterprise Support Only.
• CVE-2026-22732 (March 2026, rated critical), where Spring Security could skip writing HTTP response headers: the 5.7.22 and 5.8.24 fixes are Enterprise Support Only.
• CVE-2026-41707 (August 2026, rated high), a DPoP replay issue in Spring Security: the fix for 6.5, the line Spring Boot 3.5 uses, shipped as 6.5.12 for commercial customers only, seven weeks after 3.5 left OSS support.

The embedded server is part of the exposure. Spring Boot 2.7.18 manages Tomcat 9.0.83, while the partial PUT flaw CVE-2025-24813, listed in CISA's Known Exploited Vulnerabilities catalog, was fixed in Tomcat 9.0.99. See Apache Tomcat end of life for the server side.

Why Spring Boot upgrades take so long

• Java 17 baseline. Spring Boot 3.0 and 4.0 both require Java 17 or later. Spring Boot 2.7 runs on Java 8, so many upgrades are a JDK project first.
• javax to jakarta. Spring Boot 3 moved to Jakarta EE 10, so every javax.servlet, javax.persistence and javax.validation import becomes jakarta.*, and every library in the build must have a Jakarta release. Spring Boot 4 moves again to Jakarta EE 11 with a Servlet 6.1 baseline, embeds Tomcat 11 and drops Undertow.
• Spring Security 6 configuration. WebSecurityConfigurerAdapter was deprecated in 5.7 and removed in 6.0. Security moves to SecurityFilterChain beans, antMatchers gives way to requestMatchers, and authorization now applies to every dispatch type. Spring's guidance is to move a 2.7 application to Spring Security 5.8 before going to Spring Boot 3.
• Dependencies you do not control. Spring Cloud, shared internal starters and vendor libraries each need a compatible release before the application can move.

Your options for an end-of-life Spring Boot version

Start with an inventory: run mvn dependency:tree or gradle dependencies on each service and record the spring-boot, spring-core, spring-security-core and tomcat-embed-core versions. Then choose a route.

• Keep your version and keep it patched with OSSeva. OSSeva, AceMQ's extended support platform, ships patched Spring Boot builds for 2.6.x through 3.5.x after OSS support ends, with backported CVE fixes for Spring Framework 5.3 and Spring Security 5.7 and 5.8. Artifacts are signed and delivered through your Maven or Gradle repository, with no Java 17 requirement and no forced Spring Boot 3 migration. This is usually the first option to look at, because it closes the CVE gap without making the upgrade the emergency.
• Buy Tanzu Spring commercial support. AceMQ brokers Tanzu Spring support and licensing for teams that want Broadcom's commercial builds alongside senior engineers who can run the migration.
• Upgrade. Spring Boot 4.1 has OSS support to 31 July 2027. Plan the Java 17, Jakarta and Spring Security work as separate steps rather than one release.

For a side-by-side look at how the patching routes compare on cost, evidence and timing, read patching options for end-of-life Spring Boot. Most teams end up combining two: patched builds now, and a staged upgrade on their own schedule.

Sources

• Spring Boot support table, with data from api.spring.io (Spring Boot, Spring Framework and Spring Security generations)
• Spring Boot supported versions policy and the Spring Boot 3.0 and 4.0 migration guides on the Spring Boot wiki
• Spring Boot 2.7 support period extended, spring.io blog, 27 September 2024
• Spring advisories CVE-2025-41242, CVE-2026-22732 and CVE-2026-41707
• Spring Security without the WebSecurityConfigurerAdapter, spring.io blog
• Apache Tomcat 9 security vulnerabilities and the CISA KEV catalog