Apache Tomcat Versions and EOL Dates: Tomcat 5.5 to Tomcat 11

Apache Tomcat is the most widely deployed Java servlet container in the world. It runs standalone in enterprise data centers, ships embedded as the default servlet container in Spring Boot, and sits behind countless internal tools and public APIs. In October 2025, threat intelligence firm Criminal IP identified more than 540,000 Tomcat instances exposed to the public internet, many with HTTP PUT enabled. Tomcat is everywhere, and because Tomcat deployments tend to be stable infrastructure that nobody touches, end-of-life versions accumulate quietly in production.

The lifecycle stakes are higher for Tomcat than for most frameworks. Tomcat 9 is the last version built on the Java EE (javax.*) namespace. Everything from Tomcat 10 onward uses Jakarta EE (jakarta.*), which means moving off Tomcat 9 is an application migration, not a server upgrade. With Tomcat 9.0.x support ending March 31, 2027 and Tomcat 8.5 already three years past EOL, this guide provides the definitive reference for every Tomcat release, its support timeline, the CVEs hitting unsupported versions, and what to do about it.

‍

How Apache Tomcat's Support Policy Works

The Apache Tomcat project does not publish fixed support windows the way Angular or Node.js do. Instead, its lifecycle follows a consistent pattern:

• Roughly 10-year branches. Major Tomcat versions have historically been supported for approximately 10 years from first release.
• Three concurrent branches. Generally, three major versions are supported at any time. When a new major version reaches stable, the oldest supported branch is typically retired.
• About one year of EOL notice. When the team decides to sunset a branch, an end-of-support announcement is published roughly a year in advance.
• Specification alignment. Each major version implements a specific Servlet / JSP / EL / WebSocket specification level. Tomcat 9 and earlier implement Java EE specifications; Tomcat 10 and later implement Jakarta EE.

There is one major addition to this policy. In February 2026, the Tomcat team announced a formal long-term support plan for Tomcat 9, the last Java EE version:

• Tomcat 9.0.x support continues until March 31, 2027.
• Shortly before that date, a new Tomcat 9.1.x branch will begin shipping, supported until December 31, 2030, aligned with the end-of-support dates for many Java 8 distributions.
• The differences between 9.0.x and 9.1.x are minimal: the APR/native connectors for HTTP, HTTPS, and AJP are removed, and Tomcat Native 1.3.x is no longer supported (Tomcat Native 2.0.x continues).

This is the first time the project has split a branch into a constrained LTS line, and it reflects how much production Java EE workload still sits on Tomcat 9.

‍

Complete Apache Tomcat Version Timeline

The latest releases in each supported branch as of this writing are 11.0.22, 10.1.55, and 9.0.118, all shipped in early May 2026. The final Tomcat 8.5 release was 8.5.100 in March 2024.

Tomcat 12 is in early development. It will target the Jakarta EE 12 specifications and require a minimum of Java 21. No milestone releases or dates have been announced. Jakarta EE 12 itself is currently planned for GA in mid-2026 per the published release plan, though Jakarta EE releases have historically slipped, and Tomcat's stable releases follow specification finalization.

‍

Apache Tomcat 9 End of Life: March 31, 2027

Tomcat 9.0.x reaches end of support on March 31, 2027. This is the date that matters most to the largest population of Tomcat users, because Tomcat 9 is the last version that implements Java EE. Every application written against javax.servlet APIs tops out at Tomcat 9.

The February 2026 LTS announcement softens the cliff but does not remove it:

• The final 9.0.x release is anticipated shortly before March 31, 2027.
• The 9.1.x branch picks up from there and runs until December 31, 2030, but it drops the APR/native connectors and Tomcat Native 1.3.x. Deployments using the APR/native AJP connector need to migrate to the NIO AJP connector before moving to 9.1.x.
• End of support for 9.1.x itself has not been determined, with at least 12 months of notice promised.

What the 9.1.x plan does not change: the javax.* to jakarta.* namespace migration is still ahead of every Tomcat 9 application. The 9.1 branch buys time; it does not buy a destination. Teams should treat the window between now and December 2030 as the migration runway to Tomcat 10.1 or 11, not as a reason to defer the decision indefinitely.

Tomcat 9 also continues to absorb a steady stream of CVEs. The May 2026 security release alone fixed seven vulnerabilities in 9.0.118 (covered in detail in our May 2026 Tomcat security release breakdown), following ten CVEs patched across Tomcat 9, 10, and 11 in the April 2026 round-up. The cadence is roughly monthly. Every one of those advisories stops covering your deployment the day your branch goes EOL.

‍

Apache Tomcat 8.5 End of Life: March 31, 2024

Tomcat 8.5 reached end of life on March 31, 2024, with 8.5.100 as its final release. It began life in March 2016 as a fork of the Tomcat 9.0.0.M4 milestone, created to bring Tomcat 9 features to users who could not yet move off Java 7, and it became one of the longest-lived and most widely deployed branches in Tomcat history. That is exactly why it is still in production at so many organizations: certified middleware stacks, vendor appliances, and applications built against Servlet 3.1 that have never been retargeted.

The problem with running Tomcat 8.5 today is not abstract. CVEs disclosed against the supported branches routinely affect the 8.5 codebase, and Apache's policy is to not update the per-branch security page for EOL versions, even when the underlying NVD filings list 8.5 in the affected range. A security engineer reading tomcat.apache.org/security-8.html sees nothing after 8.5.99 and might reasonably conclude their deployment is fine. The NVD entries tell a different story:

• CVE-2025-24813 (CVSS 9.8, Critical): Path equivalence flaw in partial PUT handling allowing remote code execution, information disclosure, or content injection when the default servlet has writes enabled. Public exploit code appeared roughly 30 hours after disclosure in March 2025, and CISA added it to the Known Exploited Vulnerabilities catalog. Fixed in 9.0.99, 10.1.35, and 11.0.3. Tomcat 8.5 never received a fix.
• CVE-2024-50379 and CVE-2024-56337 (CVSS 9.8, Critical): A TOCTOU race condition during JSP compilation on case-insensitive filesystems with default servlet writes enabled, leading to remote code execution. Disclosed in December 2024, nine months after 8.5's final release.
• CVE-2025-55752 (Important): A path traversal regression in rewrite handling that could bypass protections for /WEB-INF/ and /META-INF/, escalating to RCE where PUT is enabled. Disclosed October 2025 alongside CVE-2025-55754 (ANSI escape sequence injection into console logs, affecting 8.5.60 through 8.5.100 per NVD) and CVE-2025-61795 (multipart upload temp file DoS).
• The May 2026 batch of seven CVEs, including CVE-2026-43512, a digest authentication bypass where any unknown user authenticates with the literal password null, plus CVE-2026-43515 (security constraints not correctly applied), CVE-2026-43514, CVE-2026-43513, CVE-2026-42498, CVE-2026-41293, and CVE-2026-41284. NVD product status confirms 8.5 exposure for the majority of these; component analysis confirms the rest.

Organizations running Tomcat 8.5 are accumulating unpatched CVEs at the same rate the supported branches are patching them. HeroDevs Never-Ending Support (NES) for Apache Tomcat provides a secure drop-in replacement for Tomcat 8.5 with remediations for all of the vulnerabilities above.

‍

Apache Tomcat 10.0 End of Life: October 31, 2022

Tomcat 10.0 had the shortest life of any modern branch: released December 2020, EOL October 31, 2022, less than two years later. It was effectively a transitional release, the first to implement the jakarta.* namespace (Jakarta EE 9), and it was superseded quickly by Tomcat 10.1. Its final release was 10.0.27.

Teams still on Tomcat 10.0 have the easiest path on this page: the move to Tomcat 10.1 stays within the Jakarta namespace and is a comparatively routine upgrade. There is no good reason to remain on 10.0.

‍

Apache Tomcat 10.1: Supported

Tomcat 10.1 (first released September 2022) implements the Jakarta EE 10 specifications (Servlet 6.0, JSP 3.1) and requires Java 11 or later. It is actively maintained, with 10.1.55 shipping in May 2026. No end-of-life date has been announced, and under the project's practice of roughly one year of notice, teams on 10.1 have at least a year of runway from whenever an announcement lands. Based on the historical pattern of three concurrent branches, a 10.1 sunset announcement becomes more likely as Tomcat 12 approaches stable.

‍

Apache Tomcat 11.0: Current

Tomcat 11.0 (first released October 2024) is the newest stable branch, implementing the Jakarta EE 11 specifications (Servlet 6.1, JSP 4.0, WebSocket 2.2) on a Java 17 minimum. It is the recommended target for new deployments and for migrations off Tomcat 9, since the javax.* to jakarta.* namespace change is identical whether you land on 10.1 or 11, and 11 gives you the longest runway for doing the migration once.

‍

Older Versions: Tomcat 8.0, 7.0, 6.0, and 5.5

Everything below Tomcat 8.5 has been EOL for five years or more:

• Tomcat 8.0 reached EOL June 30, 2018 (final release 8.0.53). It was superseded by 8.5, which implemented the same specifications.
• Tomcat 7.0 reached EOL March 31, 2021 (final release 7.0.109). The 7.x line dates to 2010 and remains embedded in legacy vendor products.
• Tomcat 6.0 reached EOL December 31, 2016 and Tomcat 5.5 on September 30, 2012.

Any of these versions in production today represents nearly a decade or more of unpatched vulnerabilities, including the entire CVE history that has accumulated against shared components since their final releases.

‍

What Happens After Tomcat End of Life

When a Tomcat branch reaches EOL, three things happen, and one of them is specific to how the Apache Tomcat project operates:

1. Security patches stop, and so does the paper trail. Apache does not update the per-branch security pages for EOL versions. The 8.x security page has not been touched since 8.5.99, despite NVD filings that list 8.5 in the affected range for CVEs disclosed since. "No entry on the Apache security page" does not mean "not affected." It means the project has stopped tracking your version. Vulnerability scanners, however, have not, and they will flag the EOL version itself in addition to individual CVEs.
2. The platform drifts out from under you. New Java versions, updated TLS requirements, and evolving HTTP/2 behavior are validated only against supported branches. EOL Tomcat versions gradually lose compatibility with the JDKs, load balancers, and clients around them.
3. Compliance audits flag it. PCI DSS, SOC 2, HIPAA, and FedRAMP all require supported software. The regulatory floor is also rising: EU Cyber Resilience Act Article 14 vulnerability reporting obligations begin enforcement in September 2026, and DORA Article 6 ICT risk management obligations have been in force since January 2025. Running a known-EOL servlet container with documented unpatched CVEs is increasingly a reportable exposure, not an internal risk discussion.

There is one more Tomcat-specific blast radius to account for: embedded Tomcat. Spring Boot embeds Tomcat as its default servlet container, so Tomcat CVEs cascade into Spring Boot applications that have never deployed a standalone Tomcat. Teams on EOL Spring Boot 2.7 inherit EOL Tomcat 9-line exposure through tomcat-embed-core, a pattern we documented when two Tomcat vulnerabilities, CVE-2025-66614 and CVE-2026-24733, also hit Spring Boot 2.7.

‍

Options for EOL Tomcat Versions

1. Upgrade to Tomcat 10.1 or 11. The right long-term answer for most teams, but be clear-eyed about scope. From Tomcat 9 or earlier, this is the javax.* to jakarta.* namespace migration: application code, third-party dependencies, and build configuration all change. Apache provides the Tomcat Migration Tool for Jakarta EE, which can convert deployed WARs automatically (drop Java EE applications into $CATALINA_BASE/webapps-javaee and Tomcat converts them), but bytecode conversion of dependencies is a stopgap, not a strategy. For large enterprise applications this is a multi-quarter project. Upgrading from 8.5 to 9 first closes the immediate EOL gap but lands you on a branch with its own March 2027 (9.0.x) horizon and the namespace migration still ahead: two migrations in sequence instead of one.

2. Migrate off Tomcat entirely. Some organizations use a Tomcat EOL event as the catalyst to move to Jetty, Undertow, or a fully managed platform. This is the most expensive option and rarely justified by the EOL event alone, but it can make sense where a broader platform consolidation is already underway.

3. Adopt commercial extended support. HeroDevs NES for Apache Tomcat is a secure drop-in replacement for Tomcat 8.5 that begins where open-source support ends, with no gap in patching. NES has shipped remediations for the post-EOL CVE batches Apache no longer patches on the 8.x line, including CVE-2025-24813, the December 2024 TOCTOU pair, the October 2025 trio, and all seven CVEs from the May 2026 release. NES will also extend support for Tomcat 9.0 past its March 2027 end-of-life date, giving teams a patched runway to complete the Jakarta migration on a planned timeline rather than under audit pressure.

‍

Is My Tomcat Version Supported? Quick Reference

‍

Frequently Asked Questions

When does Tomcat 9 reach end of life?

Tomcat 9.0.x support ends on March 31, 2027. The Tomcat team has announced a follow-on 9.1.x branch, supported until December 31, 2030, with minimal differences from 9.0.x (the APR/native connectors and Tomcat Native 1.3.x are removed). Tomcat 9 is the last version that supports the Java EE javax.* namespace.

Is Tomcat 8.5 still supported?

No. Tomcat 8.5 reached end of life on March 31, 2024, and its final release was 8.5.100. CVEs disclosed since then, including critical issues like CVE-2025-24813, affect the 8.5 codebase but will never receive an official Apache patch. HeroDevs NES for Apache Tomcat provides patched, drop-in replacement builds of Tomcat 8.5.

What is the difference between Tomcat 9 and Tomcat 10?

Tomcat 9 implements Java EE 8 specifications using the javax.* package namespace. Tomcat 10 and later implement Jakarta EE specifications using the jakarta.* namespace. Applications built for Tomcat 9 will not run on Tomcat 10 or later without code changes, although Apache provides a migration tool that can automatically convert deployed web applications.

What is Tomcat 9.1?

Tomcat 9.1.x is a planned long-term support branch announced in February 2026. It will begin shipping shortly before Tomcat 9.0.x support ends in March 2027 and will be supported until December 31, 2030. It is nearly identical to 9.0.x but removes the APR/native connectors and support for Tomcat Native 1.3.x.

Which Tomcat version should I use for new projects?

Tomcat 11 is the recommended version for new deployments. It implements the Jakarta EE 11 specifications, requires Java 17 or later, and has the longest support runway of any current branch. Tomcat 10.1 remains a solid choice where Java 11 compatibility is required.

Does an EOL Tomcat version stop working?

No. EOL Tomcat versions continue to run, which is exactly the problem: they keep serving traffic while accumulating unpatched vulnerabilities, failing compliance audits, and drifting out of compatibility with newer JDKs and infrastructure. The risk is silent until a scanner finding, an audit, or an exploit makes it loud.

‍

Taking Action

Tomcat's roughly 10-year branches create a false sense of permanence. The dates that matter now are concrete: Tomcat 8.5 has been unpatched since March 2024 and is exposed to every CVE batch Apache ships for the supported branches, and Tomcat 9.0.x, the last Java EE Tomcat, ends March 31, 2027 with a namespace migration standing between every 9.x application and the supported branches. Whether you upgrade, migrate, or adopt extended support, the worst option is assuming the absence of an Apache security advisory means the absence of risk.

If your organization is running Tomcat 8.5, Tomcat 9, or anything older, learn more about NES for Apache Tomcat or contact HeroDevs to talk through your options.