CVE-2026-65182

Overview

Apache Tomcat is an open-source web server and servlet container, maintained by the Apache Software Foundation, that implements the Jakarta Servlet, Jakarta Pages (JSP), Jakarta Expression Language, and Jakarta WebSocket specifications and provides a pure-Java HTTP environment for running Java web applications.

An authorization bypass vulnerability (CVE-2026-65182) has been identified in Apache Tomcat, which allows attackers to reach resources that a security constraint was configured to protect. When a request path matches the URL patterns of more than one security constraint, Tomcat is required to apply the constraint whose matching pattern is longest. A defect in that selection logic lets a shorter prefix pattern listed after a longer one in the same <web-resource-collection> reduce the length the collection is credited with, so a different and less restrictive constraint wins the longest-match comparison and is applied in its place.

Per OWASP: Access control enforces policy such that users cannot act outside of their intended permissions. Failures typically lead to unauthorized information disclosure, modification, or destruction of all data or performing a business function outside the user's limits.

This issue affects multiple versions of Apache Tomcat in the 8.5.x line, up to and including the final community release 8.5.100.

Module Info

• Product: Apache Tomcat
• Affected packages: org.apache.tomcat:tomcat-catalina (embedded distribution: org.apache.tomcat.embed:tomcat-embed-core)
• Affected versions: >=8.5.0 <=8.5.100
• GitHub repository: https://github.com/apache/tomcat
• Published packages: https://central.sonatype.com/artifact/org.apache.tomcat/tomcat-catalina
• Package manager: Maven
• Fixed in: NES for Apache Tomcat 8.5.100-tomcat-8.5.110 (upstream fixed in Apache Tomcat 9.0.121, 10.1.59, and 11.0.25)

Vulnerability Info

This High-severity vulnerability is found in the org.apache.tomcat:tomcat-catalina package in the 8.5.x line of Apache Tomcat, in the org.apache.catalina.realm.RealmBase class. findSecurityConstraints() decides which of an application's <security-constraint> elements governs a request. It runs an exact-match pass first, and if no pattern equals the request path exactly it falls through to a prefix pass that walks every constraint's <web-resource-collection> elements and keeps the constraint whose matching /.../* pattern is longest. Two counters drive that comparison: longest, the best match length seen across all constraints so far, and length, which is reset for each collection and is meant to end up holding the length of that collection's best matching pattern.

boolean matched = false;
int length = -1;
for (String pattern : patterns) {
    if (pattern.startsWith("/") && pattern.endsWith("/*") && pattern.length() >= longest) {

        if (pattern.length() == 2) {
            matched = true;
            length = pattern.length();
        } else if (pattern.regionMatches(0, uri, 0, pattern.length() - 1) ||
                (pattern.length() - 2 == uri.length() &&
                        pattern.regionMatches(0, uri, 0, pattern.length() - 2))) {
            matched = true;
            length = pattern.length();
        }
    }
}

The guard compares each candidate pattern against longest only, never against length, and both assignment branches overwrite length unconditionally. Any later pattern in the same collection that also matches the request path therefore replaces length, including a shorter one, so the collection is credited with the length of the last matching pattern rather than its longest. A constraint that declares a long, specific prefix and a short, general prefix in one collection silently forfeits the long pattern's claim.

A configuration that meets the precondition looks like this:

<security-constraint>
  <web-resource-collection>
    <web-resource-name>protected</web-resource-name>
    <url-pattern>/level1/level2/level3/*</url-pattern>
    <url-pattern>/level1/*</url-pattern>
  </web-resource-collection>
  <auth-constraint/>
</security-constraint>

<security-constraint>
  <web-resource-collection>
    <web-resource-name>public</web-resource-name>
    <url-pattern>/level1/level2/*</url-pattern>
  </web-resource-collection>
</security-constraint>

A request for /level1/level2/level3/index.jsp matches /level1/level2/level3/*, which is 23 characters long, and the deny constraint should be selected. The collection's second pattern /level1/* also matches, and being processed later it overwrites length with 9. The permissive constraint's /level1/level2/*, at 16 characters, then beats the value the deny constraint was left holding, so it is returned as the longest match. Because it carries no <auth-constraint>, hasResourcePermission() grants the request. No authentication, special headers, timing, or user interaction is required: an unauthenticated remote attacker simply requests the protected URL.

The precondition is specific, and it bounds both the exposure and the impact of correcting the defect. At least one <web-resource-collection> must list two or more prefix patterns that match the same request path, with the longer pattern listed first. An exhaustive sweep of the affected and corrected selection logic, executed against compiled Tomcat classes from the 8.5 line, found zero differences across 256 single-pattern configurations, so a multi-pattern collection is genuinely necessary. Across 4096 multi-pattern configurations, 147 access decisions differ: 66 change from allow to deny, which is the bypass being closed, and 81 change from deny to allow, where restoring true longest-match selection lets a permissive longer pattern correctly take precedence over a shorter denying one. Correcting the defect therefore changes authorization outcomes in both directions, and the deny-to-allow direction is the larger half. The Apache Tomcat security team rates this issue Important and published no CVSS vector for it.

The public source history of Apache Tomcat begins with the 7.0 line, and the flawed guard is present verbatim in its first release and in the first release of every line since, including 8.5.0. Apache records versions before 7.0.0 as unknown.

Mitigation

Only recent major lines of Apache Tomcat are community-supported. The affected 8.5.x line reached End-of-Life on March 31, 2024 (final community release 8.5.100) and will not receive public updates to address this issue.

There is no configuration-level workaround: the selection logic is internal to the container and the only remedy is a corrected build. Applications that use a multi-pattern <web-resource-collection> should review the constraints they depend on before adopting one, because restoring longest-match selection can newly deny requests that were previously allowed and newly allow requests that were previously denied.

Users of the affected components should apply one of the following mitigations:

• Upgrade to a currently supported Apache Tomcat major line (9.0.x or later) that contains the fix.
• Leverage a commercial support partner like HeroDevs for post-EOL security support.

Credits

• 4ra1n (finder)
• pyn3rd (finder)
• unam4 (finder)