Tomcat CVE-2026-77762: HTTP/2 race leaks trailers into recycled requests

A recycled request and a stale emitter

Apache Tomcat 11.0.26, dated 15 September 2026 on the project's 11.x vulnerability page, ships fixes for a batch of flaws reported privately to the Tomcat security team. Among them is CVE-2026-77762: a race condition in which a stale HPACK emitter injects trailer fields into a request object that has already been recycled back into the pool. According to a write-up on dev.to, the flaw was reported on 21 August 2026, went public on 23 September 2026, and was patched in commit fd309997.

The severity assessments attached to the CVE diverge sharply. Apache rates the issue Low, while the third-party release roundup the dev.to post draws on maps it to CWE-362, race condition, and scores it CVSS 8.1. Teams triaging this internally will need to decide which scale to trust.

How the leak happens

HTTP/2 compresses header blocks with HPACK, and the scheme is stateful: each endpoint keeps a compression context alive across the messages on a connection. In Tomcat, that context sits with the emitter responsible for writing HTTP/2 traffic on a pooled connection. When a request object returns to the pool for reuse by a different user, that emitter is supposed to be reset so the next message begins from clean state.

CVE-2026-77762 is a race in precisely that handover. With the right timing, a stale emitter persists long enough to write trailer fields belonging to one exchange into a request that has since been recycled and reassigned. Because the window is a server-side timing problem, an attacker would need to be able to issue concurrent HTTP/2 requests and land on the recycled connection at the right moment.

One detail shapes both detection and real-world severity: trailers arrive after a message's body. Code that reads headers and payload but never looks at trailers will never see the injected fields.

Impact and affected versions

In effect, requests contaminate each other. Trailer fields influenced by one client can turn up in a request another client believes it sent cleanly, and what follows depends entirely on the application. A service that consumes trailers for signatures, metadata or routing hints could act on values it never meant to accept, while a service that ignores trailers is unlikely to notice a thing, which fits the Low rating from the Apache team.

Tomcat 11.0.0-M1 through 11.0.25 on the 11.0.x line are listed as affected, and 11.0.26 carries the fix.

Measuring exposure is awkward. The dev.to post points to a ZoomEye search for Apache Tomcat that returns 580,597 instances worldwide, but that figure captures the overall Tomcat footprint rather than the number of vulnerable deployments. A search keyed to the CVE identifier itself returns nothing, because a server-side race advertises nothing in an HTTP response, so identifying affected builds falls to asset inventory.

Remediation

The fix is an upgrade to Tomcat 11.0.26 or later. The advisory offers no stand-alone configuration workaround for this specific issue; the documented remedy is the code change itself.

The same release also closes an HTTP/2 request header mix-up (CVE-2026-86350), an AJP denial of service (CVE-2026-78383), WebSocket message smuggling (CVE-2026-87022) and a WebSocket close busy-wait denial of service (CVE-2026-77791). As the dev.to post notes, rolling out 11.0.26 in one pass is more efficient than tracking each identifier separately.

Why it matters

Cross-request leakage undermines a basic assumption behind server-side code: that a request object reflects exactly what one client sent. Where trailers carry signatures, trace metadata or routing decisions, this is a data-integrity failure rather than a crash, and it can surface as baffling wrong behaviour with no obvious local cause.

Two operational points stand out. First, the race leaves nothing in responses for scanners to fingerprint, so organisations need accurate inventories of their Tomcat 11.0.x deployments to know what must be patched. Second, the gulf between Apache's Low rating and the third-party CVSS 8.1 is a reminder that vendor and aggregate scores can disagree by a wide margin; here, the practical severity hinges on whether an application reads trailers at all.