The Apache Software Foundation has pushed out Tomcat 11.0.26, a security release that patches a dozen separate vulnerabilities in one of the most widely deployed Java application servers on the internet. The update, disclosed on September 23, touches core networking components including WebSocket handling, HTTP/2 processing, the AJP connector, authentication realms, and TLS certificate validation — a spread that gives administrators a genuinely broad patching task rather than a single narrow fix.

Apache does not ship standalone patches for individual bugs of this kind; the only supported remediation path is to move affected installations to 11.0.26. That matters because the exposure window is large: several of the more serious issues affect every release from 11.0.0-M1 through 11.0.25, meaning the vast majority of Tomcat 11 deployments currently in production are technically vulnerable to at least one of the flaws in this batch.

The Headline Bugs

Of the twelve issues, four are rated Important, three Moderate, and five Low. The most notable is a WebSocket flaw tracked as CVE-2026-87022, caused by improper handling of a length parameter when per-message-deflate compression is active. In practice, this discrepancy could let an attacker smuggle additional WebSocket messages past the server’s intended framing, a class of bug that has historically been used to slip malicious payloads past security controls sitting in front of an application.

A second high-priority issue, CVE-2026-86350, is a regression: it was accidentally introduced while Apache was fixing an earlier HTTP/2 vulnerability. The bug causes inconsistent interpretation of incoming requests, which can result in HTTP headers being associated with the wrong request — a request-smuggling-adjacent scenario that only affects the narrower 11.0.22 through 11.0.25 range.

Related HTTP/2 defects round out the networking fixes: one flaw lets a malformed request cause an unrelated user’s request to fail outright, while a race condition can inject trailer fields into a pooled request object that gets recycled for a different client.

Denial-of-Service and Availability Risks

Several of the patched bugs are availability issues rather than direct compromise vectors, but they are no less disruptive for a production server:

• A flaw in AJP request processing can pin a worker thread indefinitely when a request arrives without a body.
• A busy-wait condition while sending a WebSocket close message can be abused to exhaust server resources.
• A concurrency bug can cause asynchronous WebSocket write timeouts to be silently lost, letting a connection consume resources far longer than intended.

Because several of these bugs involve race conditions and shared connection state, Apache and outside researchers both note that exploitation may be intermittent rather than consistently reproducible — which makes them easy to miss during a quick post-patch smoke test and argues for sustained monitoring rather than a one-time check.

Authorization and Certificate Handling

The release also closes an Important-rated WebSocket authorization bypass caused by the server parsing request paths as endpoint templates rather than literal paths, which could let a request reach an endpoint it should have been blocked from. A separate bug could cause the security realm associated with the first application on a shared host to be incorrectly reused by other applications relying on Jakarta Authentication’s default configuration provider.

On the certificate side, Tomcat 11.0.26 fixes an incomplete earlier OCSP correction that could allow client-certificate authentication to succeed even when soft-fail behavior was supposed to be disabled, and a second bug that caused OpenSSL-backed configurations to ignore certificate revocation lists when certificates were stored in a keystore — both scenarios that could let a revoked or otherwise invalid client certificate slip through.

What Administrators Should Do

Security teams running Tomcat 11 should treat this as an emergency patching cycle for internet-facing instances, particularly anything exposing WebSocket, HTTP/2, or AJP connectors directly to untrusted networks. Recommended steps include:

• Inventory every Tomcat 11 instance across the environment and confirm the exact version in use.
• Prioritize upgrades for externally reachable services before internal-only deployments.
• Verify downloaded release artifacts against Apache’s OpenPGP signatures or SHA-512 checksums before deployment.
• Review reverse-proxy and authentication configurations that interact with the affected connectors.
• Restart affected services after the upgrade and explicitly confirm the running version, since configuration-only workarounds do not provide equivalent protection for this release.

Given the number of race conditions and shared-state bugs in this batch, ongoing telemetry for unusual connection exhaustion, cross-request header anomalies, or unexpected authorization failures is worth maintaining well after the initial rollout, since some of these issues may not manifest reliably in standard regression testing.