Tomcat 11.0.23 to 11.0.25: security constraint and rewrite valve bypasses

Between June and August 2026 Apache Tomcat shipped three releases on the 11.0 line (11.0.23 on 22 June, 11.0.24 on 8 July and 11.0.25 on 18 August) that fix a cluster of access control bugs. Several are rated Important: CVE-2026-65182 and CVE-2026-65927 (security constraint and RewriteValve bypasses) and CVE-2026-68569 (principal lookup that could fail open).

These bugs share a trait: they only matter if you use the feature they sit in. A static site on the default servlet is in a very different position from an app that routes through RewriteValve and protects paths with layered constraints.

What's affected

The tables below are from the Tomcat 11.x security page. The 10.1 and 9.0 lines have their own fix releases, and for CVE-2026-65637 the fixed versions are 11.0.25, 10.1.58 and 9.0.121. For 11.x the affected range is 11.0.0-M1 up to the release before the fix, except where noted.

Fixed in 11.0.25 (18 August 2026, made public 25 August)

Also in 11.0.25: a WebSocket session that survives an HTTP session ID change (CVE-2026-73180), a DIGEST replay at the nonceCount boundary (CVE-2026-65905), and a TOCTOU race when creating a Unix domain socket (CVE-2026-65183).

Fixed in 11.0.24 (8 July 2026): CVE-2026-59083, RewriteValve decodes + in rewritten URIs as a space, which may allow security control bypass (Low), and a documentation fix for EncryptInterceptor (CVE-2026-59084).

Fixed in 11.0.23 (22 June 2026, made public 29 June): CVE-2026-55956 (Moderate), security constraints on the default servlet ignored the configured HTTP method. Also CVE-2026-53404, a RewriteValve OR chain that skipped later conditions, and CVE-2026-53434, where an invalid CRL configuration on the FFM connector did not cause failure so invalid certificates may be accepted.

How to check if you're exposed

# version
$CATALINA_HOME/bin/version.sh | grep "Server number"
# RewriteValve in use?
grep -rn "RewriteValve" $CATALINA_BASE/conf
ls $CATALINA_BASE/conf/Catalina/*/rewrite.config $CATALINA_BASE/webapps/*/WEB-INF/rewrite.config 2>/dev/null
# security constraints, overlapping paths, method specific rules
grep -rn "security-constraint\|url-pattern\|http-method\|security-role-ref" $CATALINA_BASE/webapps/*/WEB-INF/web.xml
# realms
grep -rn "DataSourceRealm\|JNDIRealm\|CLIENT-CERT\|SPNEGO" $CATALINA_BASE/conf $CATALINA_BASE/webapps/*/WEB-INF/web.xml
# HTTP/2 on the connector
grep -rn "UpgradeProtocol\|h2" $CATALINA_BASE/conf/server.xml

Reading it:

• No RewriteValve: CVE-2026-65927, CVE-2026-59083 and CVE-2026-53404 are out of reach.
• Overlapping url-pattern constraints in web.xml, for example /admin/* and /admin/reports/*, with different roles: review CVE-2026-65182.
• HTTP/2 on a connector that is internet facing: CVE-2026-68763 applies.
• Realm combinations like CLIENT-CERT with DataSourceRealm: CVE-2026-68569.

What to do now

1. Upgrade to 11.0.25, 10.1.58 or 9.0.121, or the latest on your line. Check your distribution's package notes for the CVE IDs.
2. After upgrading, retest access control. For each protected path, call it unauthenticated and with the wrong role.
3. If you use RewriteValve to guard paths, move the guard into web.xml constraints or a filter, or review each rule against the fixed behavior.
4. If HTTP/2 is on and public, upgrade that tier first.
5. Remove the examples webapp from production. CVE-2026-66299 only affects deployments that still have it.

How this could have been avoided

• Do not use URL rewriting as the access control layer. Three CVEs live in RewriteValve handling. Authorization belongs in constraints or the app, where it does not depend on how a URL is rewritten.
• Put an authenticating reverse proxy in front for sensitive paths. A second check at the edge turns a constraint bypass into a request that still fails.
• Keep security constraints simple and non overlapping. CVE-2026-65182 needs a longer path constraint to precede a more restrictive shorter one. A flat layout leaves nothing to reorder.
• Strip the examples and default webapps. One of the DoS bugs is in the WebSocket chat example, which a production host should not have.
• Test authorization in CI. A test that requests each protected path as an anonymous and as a low role user would catch a bypass after an upgrade changes behavior.

Why it matters

Access control bugs in a servlet container are quiet. There is no crash and no log line. A constraint that does not apply simply lets the request through.

The takeaway from three releases in a row is to treat Tomcat updates as a regular rhythm rather than an event, and to know which features your app uses. Reachability analysis starts from that: does your configuration route through the code that is vulnerable.

Try it yourself

Pick one Tomcat app, run the grep block above, and for each CVE in the tables mark it reachable, not reachable or unknown. Then follow up on the unknowns first.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Apache Tomcat 11 security page