Spring Boot Extended Support for 2.7 and 3.x, Past Open Source Support

Which Spring Boot versions need extended support in October 2026

As of 15 October 2026, only Spring Boot 4.0 (open source support to 31 December 2026) and 4.1 (to 31 July 2027) still receive open source fixes. Every 2.x and 3.x line is past open source support, including 3.5, the last 3.x line, which left it on 30 June 2026. Only two older lines have a long commercial tail from Broadcom: 2.7 to 30 June 2029 and 3.5 to 30 June 2032.

The pattern matters more than any single date. Spring sells long commercial support for the two lines that end a generation, 2.7 and 3.5, and lets the lines between them lapse. A service on 3.1, 3.2 or 3.3 has therefore run out of both open source and Broadcom support, and has fewer choices than a service on 2.7.

Spring Boot is also only the top layer. Spring Boot 2.7 runs on Spring Framework 5.3, whose open source support ended on 31 August 2024, with commercial support to 30 June 2029. The earliest of the Boot, Framework, Security and Tomcat dates sets your real exposure.

Spring Boot extended support: three routes, and where AceMQ fits

There are three ways to stay covered on a line the open source project has dropped. They are not exclusive, and most estates use more than one.

Other vendors, including HeroDevs and TuxCare, also sell patched Spring builds for end-of-life lines. Whoever you choose, ask three questions. Does the coverage list name your exact Boot, Framework and Security versions? Does it include the third-party libraries Spring Boot manages, such as Jackson and Tomcat, which carry CVEs of their own? And what happens to support if you later upgrade?

How CVE patching works on an unsupported Spring Boot line

A backport takes a fix written for a supported release and applies it to the source of an older one, then tests that the older line still behaves the same way. It is not an upgrade and it adds no features. It exists so that a scanner finding can be closed without moving the whole application to a new Java and Jakarta baseline.

The first thing we establish is which layer carries the vulnerability. Spring Boot is largely packaging and auto-configuration: the vulnerable code usually sits in Spring Framework, Spring Security or a library that the Boot BOM pins for you. A patch route has to cover each layer, and the Boot version alone does not tell you which one a finding belongs to.

• Spring Boot itself — Fixed in the Boot release or its patched build. The version in your pom or Gradle file changes.
• Spring Framework and Spring Security — Boot 2.7 depends on Framework 5.3, whose open source support ended on 31 August 2024, and Security 5.7 and 5.8, which ended on 30 June and 31 December 2023. The patch route must name them explicitly.
• Managed third-party libraries — Tomcat, Jackson, Logback, Netty and Hibernate are among the libraries the Spring Boot dependency management pins. A CVE here is often closed by a version override, not by a Spring patch, if a compatible fixed version exists.
• The JDK — A separate support line with its own end dates. A patched Spring build does not make an unpatched Java 8 runtime safe.

For each finding we also ask whether your code reaches the vulnerable path. A Spring Expression Language issue matters differently when expressions come from user input than when they come from fixed configuration. That judgement is what turns a scanner export into a short, ordered list your team can act on, with compensating controls named for anything that has to wait.

The upgrade path from Spring Boot 2.7 and 3.x to 4.1

Extended support removes the deadline from an upgrade. It does not remove the upgrade. The Spring Boot team's own migration guides name the stepping stones, and we plan around them.

• Latest 2.7.x first — The Spring Boot 3.0 guide starts by upgrading to the latest 2.7.x and comparing 2.7 and 3.0 dependency management, so you can see what the move changes.
• Spring Security 5.8 — The Security team released 5.8 to ease the move to Security 6, and the Boot guide suggests taking it before Boot 3.0.
• Java 17 and Jakarta EE — Boot 3 needs Java 17 or later and Spring Framework 6. Jakarta EE 10 replaces javax with jakarta packages, and OpenRewrite recipes, the Spring Boot Migrator and IntelliJ IDEA can help move the imports.
• Properties and deprecations — Removed or renamed properties can be surfaced with the spring-boot-properties-migrator module, which is removed again after the migration. Anything deprecated in 2.x is gone in 3.0.
• Latest 3.5.x, then Boot 4 — The Boot 4.0 guide starts from the latest 3.5.x. Boot 4 is based on Jakarta EE 11 with a Servlet 6.1 baseline and Spring Framework 7, drops Undertow, and splits Boot into smaller modules, with classic starters as a shortcut for existing applications.

If the end state is Boot 4, there is little reason to settle on any 3.x line other than 3.5, the one the Boot 4 guide names as its starting point. Dependencies that Spring Boot does not manage, such as Spring Cloud, need a compatible version identified before each step.

Which Spring Boot upgrade path fits which service

The upgrade path is not the same for every service. Where a service starts decides its first step, and the first step is often the JDK, not Spring. Spring Boot 2.7.18 requires Java 8 and is compatible up to Java 21, while Spring Boot 3.0 and 4.0 both need Java 17 or later. A service on Java 8 or 11 can therefore move to Java 17 while it is still on 2.7, as a release of its own, before any Spring change.

Two rules keep the path short. First, a platform change and a version change never share a production window: the JDK, the Boot major and the dependency clean-up each ship separately, with the previous build kept until the new one proves out. Second, the destination fixes the middle: both migration guides name their starting line (the latest 2.7.x for Boot 3, the latest 3.5.x for Boot 4), so a service heading for Boot 4 settles on 3.5, not on whichever 3.x line it reaches first.

What Spring Boot extended support does not do

• It is not an upgrade — It buys time to do one properly. We say so at inventory and plan the upgrade alongside it.
• It adds no features — Support for new Java releases, new Jakarta specifications or new Spring features still arrives only on a supported line.
• It does not cover libraries outside the BOM — Your own starters and any unmanaged dependency need their own patch path, which the inventory flags.
• It does not replace the runtime's support — The JDK, the container image and the operating system each have their own end dates. We check them in the same pass.