Apache Tomcat 9 reached end of life on December 31, 2025. No more security patches. No more CVE fixes. Every vulnerability disclosed from January 1, 2026 onward is permanently unpatched on Tomcat 9.

And yet — tens of thousands of production servers are still running it today.

This isn't negligence. There's a specific technical reason teams stay stuck, and it's worth understanding before you plan your migration.

Complete Tomcat EOL Schedule

Why Tomcat 9 is the Stickiest EOL Version

Tomcat 9 was the last version to use the javax.* namespace. Tomcat 10 and later use the jakarta.* namespace — a breaking change introduced with Jakarta EE 9.

This means migrating from Tomcat 9 to Tomcat 10+ is not a drop-in upgrade. Every class in your application that imports from javax.servlet needs to be updated to jakarta.servlet. For a large application, that's potentially hundreds of files.

The Apache Tomcat project publishes an official migration tool that automates most of this — but the effort is real, and that's why Tomcat 9 outlives its EOL date in so many environments.

The CVE Risk of Running EOL Tomcat

Tomcat has a well-documented CVE history: HTTP/2 request smuggling, path traversal vulnerabilities, deserialization issues, session fixation bugs. These are high-severity, real-world exploits — not theoretical risks.

When Tomcat 9 reached EOL, the Apache project stopped backporting fixes. Any CVE disclosed after December 31, 2025 that affects Tomcat 9 will never receive an official patch.

EOL Risk Score for Tomcat 9: 82 Critical
View full score → endoflife.ai/score/tomcat/9

Should You Go to Tomcat 10.1 or Tomcat 11?

If you're migrating from Tomcat 9, migrate directly to Tomcat 11 rather than 10.1.

Here's why: the namespace change (javax.* → jakarta.*) is the same effort whether you're targeting 10.1 or 11. Tomcat 10.1 reaches EOL December 31, 2026 — less than 18 months away. Tomcat 11 has no defined EOL date. Doing the migration once to reach the longest-supported version is more efficient.

Migration Guide: Tomcat 9 → Tomcat 11

Step 1 — Run the Jakarta EE migration tool

java -jar jakartaee-migration-1.0.6-shaded.jar source.war migrated.war

This rewrites javax.* imports to jakarta.* automatically across your WAR or exploded application.

Step 2 — Update your dependencies

Spring Framework 6+, Hibernate 6+, and Jakarta EE 10-compatible libraries are required. Check each dependency's Jakarta EE compatibility before upgrading.

Step 3 — Review your web.xml

Update the XML namespace declarations in web.xml:

<!-- Old (Tomcat 9) -->
<web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee" version="4.0">

<!-- New (Tomcat 10/11) -->
<web-app xmlns="https://jakarta.ee/xml/ns/jakartaee" version="6.0">

Step 4 — Deploy to staging on Tomcat 11 first

Run your full integration test suite on Tomcat 11 before touching production. Pay attention to servlet filters, session listeners, and any code that directly touches HttpServletRequest or HttpServletResponse.

Step 5 — Update configuration files

Review context.xml and server.xml for deprecated settings. Tomcat 11 removed some legacy configuration options that were deprecated in earlier versions.

Check Your Full Stack

Tomcat runtime EOL is one layer. If you're running Tomcat on:

• Java 8 or 11 → both are past their free-tier OpenJDK support windows
• RHEL 7 or CentOS 7 → both are EOL as of June 2024
• Spring Boot 2.x → EOL since November 2023

Multiple EOL layers compound the CVE exposure. Check your full stack at endoflife.ai/checker.

Full article with EOL Risk Scores for every Tomcat version: endoflife.ai/article-tomcat-eol