11 CVEs in One Shot: Apache Tomcat's Biggest Security Release of 2026

Apache Tomcat rarely makes dramatic security headlines, but the August 25 disclosure of eleven CVEs — patched a week earlier in Tomcat 9.0.121, 10.1.58/10.1.59, and 11.0.25 — is worth treating as a genuine fire drill. Two vulnerabilities score above 9.0 on the CVSS v3.1 scale, a third causes authentication to fail open rather than deny, and eight of the eleven are confirmed to also affect Tomcat 8.5, which reached end of life on March 31, 2024, and will receive no official patch at all.

None of the eleven appear in CISA's Known Exploited Vulnerabilities catalog as of the disclosure date, so you're ahead of active attackers right now — but experience says that gap narrows quickly once researchers start diffing patched vs. unpatched JARs.

The Two Vulnerabilities You Must Patch First

CVE-2026-65182 (CVSS 9.1 — security constraint bypass). This is the one that should keep sysadmins up at night. Tomcat's security constraint processing has an ordering rule: if a constraint for a longer path was declared before a more restrictive constraint for a shorter sub-path, the longer rule won and the tighter rule was silently skipped. An unauthenticated attacker who knows — or guesses — the ordering quirk in a target app's web.xml can reach resources that were supposed to be gated behind a login or role check. No credentials. No token. Just a crafted request. Fixed in 9.0.121, 10.1.59, and 11.0.25. Affects all versions back to 9.0.0.M1, 10.1.0-M1, and 11.0.0-M1, as well as EOL 8.5.

CVE-2026-65905 (CVSS 9.8 — DIGEST authentication replay). DIGEST auth is uncommon in modern web apps, but it's still used in legacy management consoles, CI/CD tooling, and embedded device interfaces that sit on Tomcat. The flaw: if a client sent a DIGEST request with a nonceCount sitting exactly at the upper boundary of Tomcat's replay-detection window, that request could be replayed once while the nonce remained in the window. The practical effect is session hijacking for any service still relying on DIGEST. Affects 9.0.0.M1 through 9.0.120, 10.1.0-M1 through 10.1.57, 11.0.0-M1 through 11.0.24, and — notably — EOL 7.0.30 through 7.0.109 and EOL 8.5.0 through 8.5.100.

Three More Worth Understanding

CVE-2026-68569 (auth fails open — DataSourceRealm and JDBCRealm). When CLIENT-CERT or SPNEGO authentication is in use, Tomcat's DataSourceRealm and JDBCRealm could authenticate a user even if that user did not exist in the underlying database or directory. A missing principal lookup was silently treated as success. Authentication that fails open — rather than closed — is arguably the worst direction to fail. Affects the same version ranges and EOL 8.5.

CVE-2026-65927 (RewriteValve access-control bypass). An off-by-one error in the [N] flag on Tomcat's RewriteValve caused rule processing to restart at rule two instead of rule one. Any site that uses rewrite rules to enforce access control — not uncommon in apps that front-load authorization logic in URL rewrites — has a potential bypass path. Affects all supported branches and EOL 8.5.

CVE-2026-68763 (HTTP/2 allocation-leak DoS). A memory allocation issue in the HTTP/2 implementation can be triggered remotely to exhaust resources and crash or degrade the server. Lower severity than the auth flaws but a useful tool for an attacker softening a target before a follow-on attempt.

The EOL Tomcat 8.5 Problem

Eight of the eleven CVEs confirmed in this batch also affect Tomcat 8.5. Apache deprecated it in March 2024. There is no patch coming — not from Apache, not as a backport, not as an exception. If you're running 8.5, you are running software that carries every flaw disclosed since March 2024, including at least eight from this round alone, with no remediation path other than migration.

This matters more than it might seem. Tomcat 8.5 was the long-term stable workhorse for the Java world through most of the 2010s and into the 2020s. A huge number of Java-based business apps — older Jenkins deployments, legacy e-commerce backends, custom HR and ERP systems, some versions of Atlassian tools — were built against and packaged with 8.5. If your company hasn't done a Java infrastructure audit in a few years, there's a real chance 8.5 is still running somewhere, possibly with a public-facing port.

The upgrade path to 9.0.121 or 10.1.58+ is not always trivial. Tomcat 10+ moved to the jakarta.* namespace (from javax.*), which means older Java EE applications need code changes, not just a binary swap. Tomcat 9 stays on javax.* and is the easier migration for legacy apps that can't be updated to Jakarta EE. It has a current support lifecycle and fixes all eleven of these CVEs.

For organizations genuinely stuck on 8.5 — contractual constraints, unsupported third-party apps, vendor lock-in — commercial extended support exists from providers like HeroDevs, which publishes its own backported patches for EOL Tomcat versions. That's not an endorsement, just an option worth knowing about if migration isn't possible this quarter.

Who Should Act Immediately

If any of the following describes your environment, this patch cycle is not optional:

• Any Tomcat version below 9.0.121 / 10.1.58 / 11.0.25 — update now, before exploitation goes active.
• Apps using DIGEST authentication — CVE-2026-65905 is a 9.8. If you can switch to BASIC over TLS or token-based auth, this is a good time to do it and eliminate the attack class entirely.
• Apps with URL-based access control in web.xml or RewriteValve rules — CVE-2026-65182 and CVE-2026-65927 can silently bypass those rules as they stand.
• Apps using DataSourceRealm or JDBCRealm with CLIENT-CERT or SPNEGO — CVE-2026-68569 means your realm may be waving people through.
• Any Tomcat 8.5 installation — start the migration clock. Every month on 8.5 after today is a month with an unpatched CVSS 9.1 and CVSS 9.8 on your attack surface.

How to Check What You're Running

From the Tomcat installation directory:

bin/version.sh

Or on Windows:

bin\version.bat

The output includes the full version string. If you're on a managed platform or container orchestration layer, check the base image tag in your Dockerfile or your vendor's release notes — a lot of Java container images bundle a specific Tomcat version and don't auto-update.

The Apache security advisories for Tomcat 9, Tomcat 10, and Tomcat 11 are the authoritative reference for the full CVE list and affected version ranges.

At Falcon Internet, server audits and patch cycles are part of the routine — not a scramble that happens after a CVE drops. This is exactly the kind of batch disclosure where having a current inventory of what's running on your infrastructure pays for itself.