Apache Tomcat’s September security release is not a single-CVE upgrade. It closes a cluster of issues across HTTP/2, reverse-proxy handling, AJP, WebSocket, TLS revocation checks, and application security constraints. The affected surface depends on how Tomcat is deployed, but most production teams should move to the fixed release rather than trying to mitigate each path separately.
The target versions are Tomcat 9.0.122, 10.1.60, and 11.0.26 for their respective branches. Test the upgrade as an application change: connector behavior, proxy normalization, authentication, WebSocket traffic, and certificate validation can all affect production.
Why this release deserves priority
The Tomcat 11 security advisory lists several important issues made public on September 23. CVE-2026-86350 is a regression that can cause an HTTP/2 request-header mix-up. CVE-2026-78383 can pin AJP processing threads when a request body is missing. CVE-2026-77791 can trigger a busy wait during WebSocket close, while CVE-2026-76183 can bypass security constraints for WebSocket endpoints.
Additional moderate and low-severity fixes address lost asynchronous WebSocket timeouts, malformed HTTP/2 requests, stale HPACK trailers, HTTP/1.0 Transfer-Encoding behind a reverse proxy, cross-context authentication behavior, and certificate revocation checks. Low ratings should not be read in isolation: exposure, proxy architecture, and workload sensitivity determine operational risk.
Map connectors and traffic paths
Before the change, inventory every Tomcat runtime and record its branch, exact build, Java version, packaging source, and application owner. Then identify enabled connectors: HTTP/1.1, HTTP/2, AJP, WebSocket endpoints, native OpenSSL, and OpenSSL-FFM. Document reverse proxies, ingress controllers, WAFs, and load balancers in front of each instance.
Prioritize public services that use HTTP/2 or WebSockets, systems with AJP reachable beyond a tightly controlled local segment, and applications whose authorization depends on URL patterns. Review whether example applications, WebDAV, unused connectors, or default management interfaces remain enabled.
Upgrade safely
- Back up configuration and application artifacts, but do not copy old binaries into the new runtime.
- Deploy the fixed Tomcat release through the normal immutable image or package pipeline.
- Compare
server.xml, context files, realms, valves, and JVM options with the approved baseline. - Run regression tests through the same proxy and protocol path used in production.
- Roll out gradually, monitoring errors, thread pools, memory, connection resets, and authentication failures.
For Tomcat 9, consult the 9.x security page; for 10.1, use the 10.x page. The affected ranges differ, so branch-specific evidence matters.
Harden the surrounding architecture
Disable AJP if it is not required. If it is required, bind it to a private interface, enforce a secret, and restrict network access. Terminate only the protocols you need, and ensure reverse proxies reject ambiguous or malformed requests instead of forwarding them with altered semantics.
Review WebSocket endpoint authorization independently of the initial HTTP page. Test unauthenticated and low-privilege users against endpoint templates, not just literal paths. Where mutual TLS or client-certificate authentication is used, verify OCSP and CRL failure behavior with a controlled revoked certificate.
Test for proxy disagreements
Several fixes concern inconsistent interpretation between protocol layers. Reproduce the production path in pre-production: client, CDN or WAF, reverse proxy, ingress layer, and Tomcat. Send normal and deliberately malformed requests over HTTP/1.0, HTTP/1.1, and HTTP/2 where supported. Confirm that rejected requests fail at the edge and do not arrive at the application with different headers, paths, or body framing.
Pay particular attention to duplicated headers, trailers, Transfer-Encoding, encoded paths, and upgrades to WebSocket. Security controls at a proxy are only reliable when the backend assigns the same meaning to the request. Preserve representative test results so that later proxy or connector changes can be checked against the same cases.
Capacity tests matter too. Observe AJP threads, WebSocket connections, async timeouts, and HTTP/2 stream accounting under abusive but controlled load. The goal is not merely to see a 4xx response; it is to confirm that rejected traffic releases threads, buffers, and connections promptly.
Verify the fleet
After rollout, query runtime versions from the live process or container image digest. Do not rely on the package installed on the host if an older container is still running. Scan for stragglers in staging, scheduled jobs, developer environments, and disaster-recovery stacks.
Finally, retain evidence of the target version, connector review, proxy-path tests, and rollback outcome. This upgrade is a good forcing function to remove unused protocol surfaces and to make Tomcat version discovery continuous rather than a one-time spreadsheet exercise.
