Apache Tomcat Vulnerabilities by Version: 8.5, 9.0, 10.1, 11

The short answer

Three Apache Tomcat lines get security fixes today: 11.0, 10.1 and 9.0. Their current releases are 11.0.26, 10.1.60 and 9.0.122, which carry the fixes for 15 CVEs made public on 23 September 2026. Tomcat 8.5 reached end of life on 31 March 2024 with 8.5.100 as its final release, 10.0 on 31 October 2022 and 7.0 on 31 March 2021. Tomcat advisories have kept naming 8.5.0 to 8.5.100 as affected since then, and there is no 8.5 release to move to. Tomcat 9.0 is next: the project expects its end of support "no earlier than 31 March 2027", after which a 9.1.x branch carries on.

Supported and end-of-life lines

Dates and versions are from the Tomcat project's "Which version do I want?" page.

Tomcat 9.0 and the 9.1.x branch

Tomcat 9 is the last major version that supports Java EE, so it is the last one on the javax.* namespace. The Tomcat project says it will support Tomcat 9 beyond the usual ten years through a new 9.1.x branch, started when 9.0.x reaches end of support. Security fixes, bug fixes and features will keep being backported to 9.1.x as they are to 9.0.x. No end date has been set for 9.1.x, and the project has committed to at least 12 months' notice before one.

One change matters for planning: the APR/Native connector will not be available in 9.1.x. OpenSSL support continues through the NIO and NIO2 connectors with Tomcat Native 2.x. A 9.0 estate that still uses the APR connector has a connector change to make before it can move to 9.1, even though no javax to jakarta migration is involved. The Tomcat 9 end of life page tracks the dates.

September 2026: 15 CVEs in one release

On 23 September 2026 the Tomcat security team made 15 CVEs public. Twelve are in Tomcat itself, fixed in 11.0.26, 10.1.60 and 9.0.122, and three are in Tomcat Native, fixed in 2.0.16 and 1.3.9. The table gives Tomcat's own severity rating and the CVSS score in each NVD record. As of 4 October 2026 NVD had not analysed any of them, so those scores come from CISA's enrichment of the records.

Start with CVE-2026-76183. Tomcat parsed request paths as WebSocket endpoint templates, so the security constraints protecting any WebSocket endpoint could be bypassed. The advisory lists every 9.0, 10.1 and 11.0 release before the fix, and states that 8.5.0 to 8.5.100 and 7.0.43 to 7.0.109 are affected as well. Both of those lines are end of support, so no upstream release will fix them. Of the 12 Tomcat CVEs in this batch, nine name 8.5 releases as affected and four name 7.0 releases.

The two sources disagree on severity. The Tomcat team rated none of the 15 Critical, while the CVSS scores in the NVD records put four of them at 9.1 or higher. Your exposure decides which ones matter: WebSocket endpoints, HTTP/2, AJP, Tomcat Native and CLIENT_CERT authentication are the features to check.

Two of the four highest-scored CVEs came from earlier fixes. CVE-2026-86350 exists only in 9.0.118 to 9.0.121, the releases carrying the fix for CVE-2026-41293, and CVE-2026-86248 completes the fix for CVE-2026-34500. Being on a recent 9.0 release is not the same as being on a clean one.

August 2026: security constraint bypass and realm fail-open

Tomcat 11.0.25, 10.1.59 and 9.0.121, with the issues made public on 25 August 2026, fixed four CVEs that the Tomcat team rated Important. The release vote for 10.1.58 did not pass, so 10.1.59 is the first 10.1 release with these fixes, although some NVD records name 10.1.58.

All four name 8.5 releases as affected. CVE-2026-65182 and CVE-2026-68569 are access control failures, not denial of service, and both reach back to 7.0.0.

Earlier in 2026: the EncryptInterceptor pair

CVE-2026-29146 (7.5) is a padding oracle in the cluster EncryptInterceptor with its default configuration. It was fixed in 11.0.20, 10.1.53 and 9.0.116, and its NVD record lists 8.5.38 to 8.5.100 and 7.0.100 to 7.0.109 as affected. That fix introduced CVE-2026-34486 (7.5), which let the EncryptInterceptor be bypassed in exactly 11.0.20, 10.1.53 and 9.0.116. It was fixed in 11.0.21, 10.1.54 and 9.0.117, and CISA added it to its Known Exploited Vulnerabilities catalog on 4 August 2026.

2024 and 2025: the write-enabled default servlet

Writes to the default servlet are disabled by default, which limits the first three and the remote code execution path of the fourth. CVE-2025-24813 is the one with a known exploitation record: CISA added it to the Known Exploited Vulnerabilities catalog on 1 April 2025. Remote code execution needs writes enabled for the default servlet, partial PUT (enabled by default), Tomcat's file-based session persistence in its default location, and a library on the classpath that can be used in a deserialization attack.

CVE-2024-56337 is a reminder that some fixes need configuration as well as an upgrade. On Java 8 or 11, the system property sun.io.useCanonCaches must be set to false; on Java 17 it must be false if it is set; on Java 21 and later nothing extra is needed. From 11.0.3, 10.1.35 and 9.0.99, Tomcat checks the property before it allows the default servlet to be write-enabled on a case-insensitive file system.

Ghostcat: CVE-2020-1938

Ghostcat is the best-known Tomcat CVE. NVD scores it 9.8, and CISA added it to the Known Exploited Vulnerabilities catalog on 3 March 2022. Tomcat treats AJP connections as more trusted than HTTP ones, and before 9.0.31, 8.5.51 and 7.0.100 Tomcat shipped with an AJP connector enabled by default, listening on all configured IP addresses. Anyone who could reach that port could read any file in the web application, including under WEB-INF and META-INF, and have any file in the application processed as a JSP. If the application stored uploaded files inside the web application, that became remote code execution.

The fixed releases also hardened the default AJP connector configuration, and the Tomcat team says users upgrading will likely need small configuration changes. The exposure only exists where untrusted users can reach the AJP port, usually 8009. If nothing in front of Tomcat speaks AJP, remove the AJP connector from server.xml. If Apache httpd uses mod_jk or mod_proxy_ajp, bind the connector to the address the proxy connects from and set a shared secret.

Older remote code execution CVEs still found in audits

• CVE-2017-12617 (8.1). With HTTP PUT enabled on the default servlet, a crafted request could upload a JSP that the server would then execute. Fixed in 9.0.1, 8.5.23, 8.0.47 and 7.0.82. CISA added it to the Known Exploited Vulnerabilities catalog on 25 March 2022.
• CVE-2019-0232 (8.1). On Windows, with enableCmdLineArguments enabled, the CGI servlet allowed remote code execution because of how the JRE passes command line arguments to Windows. The CGI servlet is disabled by default. Fixed in 9.0.19, 8.5.40 and 7.0.94.
• CVE-2020-9484 (7.0). Remote code execution through deserialization when sessions are persisted with FileStore and the attacker controls the name and contents of a file on the server, among other conditions. Fixed in 9.0.35, 8.5.55 and 7.0.104. A follow-up, CVE-2021-25329, closed an edge case in 9.0.43, 8.5.63 and 7.0.108.

Tomcat vulnerabilities by version

Tomcat 11.0

Supported, on Java 17 and later. Every CVE above that affects 11.0 is fixed in 11.0.26.

Tomcat 10.1

Supported, on Java 11 and later. Every CVE above that affects 10.1 is fixed in 10.1.60.

Tomcat 9.0

Supported until at least 31 March 2027, and 9.0.122 fixes everything above. If you are pinned to an older 9.0 release, these are the minimums: 9.0.31 for Ghostcat, 9.0.99 for CVE-2025-24813, 9.0.117 for CVE-2026-34486, 9.0.121 for the August 2026 batch and 9.0.122 for the September 2026 batch.

Tomcat 8.5

End of life since 31 March 2024, with 8.5.100 as the final release. Of the CVEs in this guide, 18 were made public after that date and name 8.5 releases as affected, including CVE-2024-50379, CVE-2025-24813, CVE-2026-65182 and CVE-2026-76183. None has an upstream 8.5 fix. The supported migration path is 9.0, which keeps the javax namespace. See Tomcat 8.5 end of life.

Tomcat 10.0 and 7.0

10.0 reached end of life on 31 October 2022 and 7.0 on 31 March 2021. Several 2026 advisories list 7.0 releases as affected. Users of 10.0 can move to 10.1, since both use the jakarta namespace.

Hardening that reduces exposure

• Remove the AJP connector if nothing uses it. If something does, bind it to a specific address and set a secret.
• Keep the default servlet read-only (the readonly initialisation parameter left at true) unless uploads through PUT are a requirement.
• Keep the manager and host-manager applications off the internet, and remove the examples application.
• Run Tomcat as a dedicated non-root user with the minimum file system permissions it needs.
• Check whether WebSocket endpoints, HTTP/2 and CLIENT_CERT authentication are in use, since many of the 2026 CVEs sit in those areas.

Hardening cuts exploitability. It does not remove the finding from a scanner report, and an auditor asking for patch evidence will want a fixed build.

Where OSSeva fits

OSSeva backports Tomcat security fixes to 8.5.x, 9.0.x and 10.0.x and ships them as signed builds that drop into the existing deployment, so an estate on 8.5.100 has a patched build to move to without a platform migration. They are available now on the Patch, Assure and Operate tiers: Assure adds a hardening review and compliance documentation, and Operate adds 24/7 monitoring with a 15-minute P1 response. See Apache Tomcat support, the Tomcat end of life tracker, Tomcat 8.5 end of life and Tomcat 9 end of life. For the framework running inside many of these containers, see Spring Framework vulnerabilities by version.