Spring Boot 3.5 Is Officially End-of-Life. Here Is What That Means for Teams Still Running It.

It is official

Spring Boot 3.5 and Spring Framework 6.2 are end of life as of today. The Spring team has closed these release lines. There will be no security patches, no CVE remediations, and no updates of any kind for these versions going forward. The upstream security intelligence pipeline for Spring Boot 3.5 is off.

For the enterprise Spring ecosystem — where Spring Boot 3.5 is the last supported 3.x release and the current production baseline for teams that have not yet migrated to Boot 4.0 — the security implications are significant and the timeline for action is now.

‍

What changed this morning — exactly

Spring Boot 3.5 applications running in production at 6:00 AM today are running the same code they were running at 6:00 PM yesterday. No performance change, no functionality change, no deployment change. What changed is the security infrastructure supporting that code.

The Spring Security team has closed its intake for Spring Boot 3.5 vulnerability reports. Security researchers who discover vulnerabilities in Spring Boot 3.5 will be directed to report them against Spring Boot 4.x or another supported version. Spring Boot 3.5 entries in the CVE database will receive no new remediation assignments from the project.

This matters in a specific way that is easy to underestimate: the security research community will continue finding vulnerabilities in Spring Boot 3.5. The framework code does not become less exploitable because it reached an EOL date. What becomes less exploitable is the patch path. Vulnerabilities will be discovered. They will be documented. They will not be remediated in Spring Boot 3.5.

For teams without NES coverage: the CVE queue for Spring Boot 3.5 opened permanently this morning. Every vulnerability discovered from today forward in the Spring 3.5 stack is an addition to that queue with no official subtraction mechanism.

‍

The Spring Boot 4.0 destination is worth reaching

There is a genuine reason to be excited about where Spring Boot 4.0 and Spring AI 2.0 are going. The Spring team has made significant investments in the Boot 4.0 architecture — cleaner auto-configuration, improved observability integration, a foundation for the next decade of Spring applications. Spring AI 2.0, which requires Boot 4.0, represents the most mature framework for enterprise AI application development in the Java ecosystem.

The teams that will get the most out of that investment are the ones who arrive at Boot 4.0 through a deliberate migration — with proper dependency assessment, adequate test coverage, and a production rollout plan that does not create availability risk. Those teams are building something. The teams rushing under security pressure are trying not to break something.

NES for Spring is the mechanism that separates those two outcomes. It provides the security foundation from which a deliberate migration can happen — eliminating the urgency pressure that leads to corner-cutting, and giving teams the time to execute the migration properly.

The Spring Boot 3.x to 4.0 migration is not a weekend project for large enterprise systems. It involves dependency graph assessment, API compatibility review, auto-configuration changes, Jackson 3 migration, observability integration updates, test coverage expansion, staged deployment, and a change management process that does not compress to fit an arbitrary deadline. Organizations doing it properly are doing it over months. Today's EOL date does not change the scope of that work.

‍

What teams still on Spring Boot 3.5 should do today

If you have NES for Spring already in place: you entered July 1 patched. Continue the Boot 4.0 migration on your planned timeline. NES is doing what it is supposed to do.

If you do not have NES in place and your Boot 4.0 migration extends past today: the priority is getting NES coverage activated. Every day of delay from this point is a day running unpatched Spring Boot 3.5 in production. Contact HeroDevs today to discuss activation.

If you are in the final stages of the Boot 4.0 migration and expect to complete it in the next few weeks: assess your specific CVE exposure for the Spring components in your application, your deployment timeline, and whether the security gap during the completion window is acceptable. For most teams, it is not — NES for even a few weeks of the migration completion window is worthwhile.

If your organization has Spring Boot 3.5 in production and is not yet planning a Boot 4.0 migration: this is the moment to change that. Running on permanently unpatched Spring Boot 3.5 is not a stable long-term posture. It creates security exposure that accumulates, compliance gaps that compound, and technical debt that only gets harder to unwind.

The longer view

EOL dates create acute attention to decisions that should have been made earlier. That attention is useful — it brings urgency to conversations that were previously easy to defer. But the decisions themselves — what to run, what to patch, what to migrate, and on what timeline — are not made better by urgency. They are made better by clear information, realistic scope assessment, and a security foundation that allows deliberate execution.

The Spring Boot 3.5 EOL is not the end of anything important. It is the beginning of the Spring Boot 4.0 era for enterprise Java. The organizations that navigate this transition well are the ones that are clear-eyed about the scope of the work, honest about their timelines, and disciplined about maintaining a secure posture during the migration.

‍

FAQ

What Spring versions are end of life as of June 30, 2026? Spring Boot 3.5 and Spring Framework 6.2 reached end of life on June 30, 2026. The Spring project will no longer issue security patches, CVE remediations, or any updates for these versions. Note that Spring Boot 3.3 and Framework 6.1 went EOL in June 2025, and Spring Boot 3.4 in December 2025.

Will Spring Boot 3.5 applications stop working after June 30? No. Spring Boot 3.5 applications continue running after June 30 — the framework does not cease to function. End of life means the upstream project stops patching and maintaining the version. The operational risk is the accumulation of unpatched vulnerabilities in a permanently frozen release.

What should teams running Spring Boot 3.5 without coverage do today? Contact HeroDevs to discuss NES activation. Every day of delay is a day running unpatched Spring Boot 3.5 in production. NES provides continued CVE monitoring and security patching from today forward.

How quickly can NES for Spring be activated? HeroDevs can discuss activation timelines directly. For teams in an active security exposure situation after the June 30 EOL, expedited activation options are available. Contact HeroDevs today.

What is the migration path from Spring Boot 3.5? The migration path is Spring Boot 4.0. Spring Boot 4.0 is the current actively supported major version and the foundation for Spring AI 2.0 adoption.

Does Spring Boot 4.0 support Spring AI 2.0? Yes. Spring AI 2.0 requires Spring Boot 4.0 and is built on the Boot 4.0 dependency model. Teams migrating to Boot 4.0 gain access to Spring AI 2.0's mature model abstraction layer, standardized vector store integration, and first-class RAG pattern support.

How does June 30 affect CRA compliance for EU market products? CRA Article 14 manufacturer reporting obligations begin September 11, 2026. Spring Boot 3.5 components after June 30 without NES coverage have no upstream remediation mechanism for new CVEs — creating a documented compliance gap for organizations placing Spring-based products on the EU market with 72 days until reporting obligations go live.