Apache Tomcat CVEs: What Enterprise Java Teams Need to Know in 2025

Tomcat's Place in the Enterprise Stack

Apache Tomcat is the most widely deployed Java web application container in the enterprise. It underpins Spring MVC applications, legacy Java EE 7 workloads, and countless internal tools built across two decades of enterprise Java development. Its ubiquity means that Tomcat CVEs have unusually broad potential impact — and that EOL Tomcat versions (primarily 8.5.x, which reached EOL in March 2024) are present in more production environments than most security teams realise.

The Tomcat EOL Timeline

• Tomcat 7: EOL April 2021
• Tomcat 8.5: EOL March 2024
• Tomcat 9.0: Supported through approximately late 2025 (monitor the Apache Tomcat mailing list for announcement)
• Tomcat 10.1: Current LTS, targets Jakarta EE 10
• Tomcat 11.0: Current, targets Jakarta EE 11

The migration from Tomcat 9.0 (Java EE 8) to Tomcat 10.1 (Jakarta EE 10) requires a namespace migration — the javax.* package namespace becomes jakarta.* — which is a non-trivial code change for applications with many dependencies on the old namespace.

High-Impact Tomcat CVE Patterns

Request Smuggling

HTTP request smuggling vulnerabilities in Tomcat's HTTP connector have appeared multiple times across major version lines. These vulnerabilities allow an attacker to interfere with how requests are processed by the server and a downstream proxy, enabling cache poisoning, session hijacking, or bypassing of access controls applied at the reverse proxy layer. Deployments using Tomcat behind nginx or Apache httpd are particularly susceptible because the request parsing disagreement between frontend proxy and backend Tomcat is the mechanism the attack exploits.

Partial PUT Remote Code Execution (CVE-2025-24813)

CVE-2025-24813, disclosed in early 2025, is one of the most serious recent Tomcat advisories. It affects Tomcat instances with the default servlet enabled for write operations (non-default but widely deployed for file upload scenarios). A partial PUT request can upload a serialized Java object to the session persistence location, which a subsequent request can then deserialize to achieve remote code execution. Tomcat 8.5, being EOL, received no upstream fix; the fix was delivered only in 9.0.99+, 10.1.35+, and 11.0.3+. This CVE is a concrete example of the risk that EOL versions accumulate.

AJP Connector Vulnerabilities (Ghostcat)

The AJP connector, used to proxy requests from Apache httpd to Tomcat, has historically carried significant vulnerability risk. CVE-2020-1938 (Ghostcat) allowed unauthenticated remote attackers to read files from the Tomcat webapp root and in some configurations achieve remote code execution. While this specific CVE was patched years ago, it established a pattern: AJP-based deployments face a different and more severe threat profile than HTTPS-only deployments, and the AJP connector should be disabled if not actively used.

Risk-Reducing Configuration Controls

While extended lifecycle patching addresses CVEs directly, several configuration controls meaningfully reduce the exploitability of Tomcat vulnerabilities in the interim:

• Disable the AJP connector entirely if not using Apache httpd as a reverse proxy (Connector port="8009" protocol="AJP/1.3" should be commented out).
• Disable the default servlet for write operations if file upload via partial PUT is not required (readonly init parameter should be true).
• Restrict access to the manager and host-manager applications to localhost or an admin network; these applications should never be internet-accessible.
• Run Tomcat as a dedicated non-root OS user with minimal filesystem permissions.

OSSeva Tomcat Extended Support

OSSeva provides backported CVE patches for Tomcat 8.5.x and 9.0.x, targeting the Java EE 7 and Java EE 8 application ecosystems respectively. This includes patches for critical vulnerabilities like CVE-2025-24813 that have no upstream fix on EOL version lines.

Conclusion

Tomcat 8.5's EOL status is not academic — CVE-2025-24813 alone demonstrates that significant unpatched vulnerabilities exist in production EOL Tomcat deployments. Configuration hardening reduces exploitability but does not eliminate it, and configuration controls are not a substitute for documented patch evidence in a compliance audit. Extended lifecycle support provides the only path to both.