Apache Tomcat, the open-source Java web container used to run Java and Jakarta EE web applications and services, has a WebSocket authentication bypass in CVE-2026-76183. It matters most to organisations that operate internet-facing Java applications themselves, but Tomcat can also be embedded or redistributed in another product—so platform teams should check both direct installations and packaged dependencies.
Apache disclosed the issue on September 23, 2026, after Zhang Yilin privately reported it in August. The vendor calls it Important; the CVE record’s CISA enrichment assigns CVSS 3.1 9.8. That difference in labels shouldn’t distract from the practical exposure: an unauthenticated network client can reach a protected WebSocket endpoint by supplying a path that Tomcat interprets incorrectly.
Request paths were parsed like endpoint templates
WebSocket endpoints are application URLs that keep a two-way connection open, commonly for live dashboards, messaging, notifications, and interactive APIs. Administrators can place security constraints on them so the container requires authentication before an application handler sees a connection.
The bug is an alternate-name path confusion. Tomcat used the same URI-template parser for an incoming request path as for an endpoint definition. Curly-braced path segments have special meaning in a template: they stand for variables. As a result, a crafted candidate path could be interpreted as a template rather than literal request text and evade the configured constraint for a WebSocket endpoint.
The Tomcat 9 correction is small, but it shows the key distinction: request paths must not be parsed as templates.
@@ -365,7 +365,7 @@ public WsMappingResult findMapping(String path) {
// No exact match. Need to look for template matches.
UriTemplate pathUriTemplate;
try {
- pathUriTemplate = new UriTemplate(path);
+ pathUriTemplate = new UriTemplate(path, false);
} catch (DeploymentException e) {
// Path is not valid so can't be matched to a WebSocketEndpointAn attacker needs no account, prior foothold, or user interaction according to the published vector. What they gain is the ability to bypass Tomcat’s configured WebSocket access control; the resulting data access or actions depend on what the endpoint itself permits after connection. Teams should not assume application-level checks will compensate without testing the affected routes.
Fixed supported branches are available now
Apache provides fixed releases: 11.0.26, 10.1.60, and 9.0.122. Affected supported ranges run through 11.0.25, 10.1.59, and 9.0.121 respectively. Branches 8.5 and 7 are end of life and known affected; move those deployments to a supported branch rather than waiting for a backport. Apache’s advisory mentions removing the examples web application as an alternative mitigation, but the available material does not establish that this protects custom WebSocket endpoints.
Prioritise upgrades on public-facing systems, then inventory WebSocket routes and retest authentication and authorization with unusual brace-containing paths. No exploitation in the wild, incident, or campaign had been confirmed as of September 24, and it was not in CISA’s Known Exploited Vulnerabilities catalogue. No public proof of concept or exploit code had surfaced either.
This is a container-level control failure, so a single upgrade can protect many applications—but only if teams know where Tomcat is actually deployed. SecAlerts monitors an organisation’s actual software stack and alerts on new vulnerabilities affecting the products it runs, helping turn that inventory question into a patching queue.
