CVE-2026-76183

Overview

Apache Tomcat is an open-source implementation of the Jakarta Servlet, Jakarta Pages, Jakarta Expression Language, Jakarta WebSocket, Jakarta Annotations, and Jakarta Authentication specifications. It serves Java web applications either as a standalone servlet container and HTTP server or embedded inside an application through the tomcat-embed-core artifact. Its Catalina servlet container (org.apache.tomcat:tomcat-catalina) supplies the request-processing pipeline, including Valves such as RewriteValve, along with connectors, realms, and session management.

An Authorization Bypass vulnerability (CVE-2026-76183) has been identified in the WebSocket server container's URI template matching, which allows attackers to reach a template-mapped WebSocket endpoint through a request URI that the web application's security constraints do not cover, defeating the authentication and authorization rules declared for that endpoint.

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 the WebSocket endpoint mapping of Apache Tomcat.

Details

Module Info

• Product: Apache Tomcat
• Affected packages: org.apache.tomcat:tomcat-websocket, org.apache.tomcat.embed:tomcat-embed-websocket
• Affected versions:
• org.apache.tomcat:tomcat-websocket: >=7.0.43 <=7.0.109, >=8.5.0 <=8.5.100, >=9.0.0.M1 <9.0.122, >=10.1.0-M1 <10.1.60, >=11.0.0-M1 <11.0.26
• org.apache.tomcat.embed:tomcat-embed-websocket: >=7.0.43 <=7.0.109, >=8.5.0 <=8.5.100, >=9.0.0.M1 <9.0.122, >=10.1.0-M1 <10.1.60, >=11.0.0-M1 <11.0.26
• GitHub repository: https://github.com/apache/tomcat
• Published packages: https://central.sonatype.com/artifact/org.apache.tomcat/tomcat-websocket, https://central.sonatype.com/artifact/org.apache.tomcat.embed/tomcat-embed-websocket
• Package manager: Maven
• Fixed in:
• NES for Apache Tomcat 8.5.100-tomcat-8.5.112
• Apache Tomcat 11.0.26, 10.1.60, 9.0.122 (OSS)

Vulnerability Info

This High-severity vulnerability is found in the org.apache.tomcat:tomcat-websocket package in the WebSocket endpoint mapping of Apache Tomcat.

When an upgrade request arrives, WsServerContainer.findMapping() first tries an exact match against the deployed endpoint paths. If there is no exact match, it wraps the incoming request path in a UriTemplate and compares that object against every deployed endpoint template with the same segment count:

// No exact match. Need to look for template matches.
UriTemplate pathUriTemplate = null;
try {
    pathUriTemplate = new UriTemplate(path);
} catch (DeploymentException e) {
    // Path is not valid so can't be matched to a WebSocketEndpoint
    return null;
}
...
for (TemplatePathMatch templateMatch : templateMatches.values()) {
    pathParams = templateMatch.getUriTemplate().match(pathUriTemplate);
    if (pathParams != null) {
        sec = templateMatch.getConfig();
        break;
    }
}

The problem is that UriTemplate has a single constructor, and that constructor always interprets a path segment as a template parameter declaration. There is no way to ask it to treat the string as a literal request path, so the attacker-controlled request URI is parsed with the same rules as a developer-authored endpoint template:

public UriTemplate(String path) throws DeploymentException {
    ...
    normalized.append('/');
    int index = -1;
    if (segment.startsWith("{") && segment.endsWith("}")) {
        index = segmentCount;
        segment = segment.substring(1, segment.length() - 1);
        normalized.append('{');
        normalized.append(paramCount++);
        normalized.append('}');
        if (!paramNames.add(segment)) {
            throw new DeploymentException(sm.getString("uriTemplate.duplicateParameter", segment));
        }
    } else {
        ...
    }
    this.segments.add(new Segment(index, segment));
    segmentCount++;
}

A request segment written as {admin} is therefore stripped of its braces and stored with the value admin. UriTemplate.match() then compares the stored segment values, and it accepts the candidate without ever checking whether the candidate itself carries parameters:

public Map<String, String> match(UriTemplate candidate) {

    Map<String, String> result = new HashMap<>();

    // Should not happen but for safety
    if (candidate.getSegmentCount() != getSegmentCount()) {
        return null;
    }

    Iterator<Segment> targetSegments = segments.iterator();

    for (Segment candidateSegment : candidate.getSegments()) {
        Segment targetSegment = targetSegments.next();

        if (targetSegment.getParameterIndex() == -1) {
            // Not a parameter - values must match
            if (!targetSegment.getValue().equals(candidateSegment.getValue())) {
                // Not a match. Stop here
                return null;
            }
        } else {
            // Parameter
            result.put(targetSegment.getValue(), candidateSegment.getValue());
        }
    }

    return result;
}

The two representations of the request therefore disagree. Catalina applies the web application's security constraints to the decoded request path, so a constraint whose url-pattern is /admin/* does not match a request sent as /%7Badmin%7D/42, which decodes to the path /{admin}/42. The WebSocket layer, however, unwraps the braces before matching, so that same path still resolves to the endpoint declared at /admin/{id} and the upgrade is completed. An unauthenticated remote attacker can reach any template-mapped WebSocket endpoint whose protection depends on a declarative security constraint, simply by brace-wrapping the literal segments of the endpoint path. Endpoints mapped without template parameters are unaffected, because they are resolved by the exact-match lookup that runs before the template pass.

Mitigation

Only recent versions of Apache Tomcat are community-supported. The community support version will not receive any updates to address this issue. For more information, see here.

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

• Upgrade to a patched version of Apache Tomcat.
• Leverage a commercial support partner like HeroDevs for post-EOL security support.

Credits

• This issue was reported privately to the Apache Tomcat security team on 17 August 2026. The advisory does not name a finder publicly.