CVE-2026-77762

HTTP Request Smuggling
Affects
Apache Tomcat
in
Apache Tomcat
No items found.
Versions
>=8.5.59 <=8.5.100, >=9.0.39 <9.0.122, >=10.1.0-M1 <10.1.60, >=11.0.0-M1 <11.0.26

Patch Available.

Exclamation circle icon
Patch Available

This Vulnerability has been fixed in the Never-Ending Support (NES) version offered by HeroDevs.

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 HTTP request smuggling vulnerability (CVE-2026-77762) has been identified in the HTTP/2 HPACK decoder of Apache Tomcat, which allows attackers to inject trailer fields into another HTTP/2 request. The connection-scoped HPACK decoder kept a plain, non-atomic reference to the stream that was receiving the current header block, and that reference was not cleared when the stream was reset and swapped out for a lightweight placeholder, so header fields arriving afterwards could still be delivered to a stream whose pooled Request object had already been recycled for reuse.

This issue is caused by a race condition. Per OWASP: A race condition is a server-side vulnerability that occurs when two or more threads or requests access shared state concurrently without proper coordination.

This issue affects the HTTP/2 implementation in multiple versions of Apache Tomcat below 11.0.26.

Details

Module Info

  • Product: Apache Tomcat
  • Affected packages: tomcat-coyote, tomcat-embed-core
  • Affected versions: >=8.5.59 <=8.5.100, >=9.0.39 <9.0.122, >=10.1.0-M1 <10.1.60, >=11.0.0-M1 <11.0.26
  • GitHub repository: https://github.com/apache/tomcat
  • Package manager: Maven
  • Fixed in:

Vulnerability Info

This Low-severity vulnerability is found in the org.apache.tomcat:tomcat-coyote package in the 8.5.x line of Apache Tomcat, in the org.apache.coyote.http2 HTTP/2 implementation.

HPACK decoding is scoped to the connection, not to the stream. A single HpackDecoder instance decodes every header block that arrives on an HTTP/2 connection, and it routes each decoded field to whichever HeaderEmitter is currently installed, normally the Stream that owns the header block being read. That reference was held in a plain, non-volatile field and dereferenced on every field emitted:

private HeaderEmitter headerEmitter;
headerEmitter.emitHeader(name, value);

A header block does not have to be delivered in one frame. It can continue across CONTINUATION frames, and a request can carry a second, trailing header block after its data, so the emitter can stay installed while other frames on the connection are processed. Meanwhile, once a stream is reset or otherwise finished, Stream.recycle() asks the connection handler to swap the full stream implementation for a lightweight RecycledStream, at which point the stream's pooled Request object goes back to the processor pool and can be handed to an unrelated request. The swap updated only the stream map and left the decoder still pointing at the stream it had just retired:

void replaceStream(AbstractNonZeroStream original, AbstractNonZeroStream replacement) {
    AbstractNonZeroStream current = streams.get(original.getIdentifier());
    // Only replace the stream if it currently uses the full implementation.
    if (current instanceof Stream) {
        streams.put(original.getIdentifier(), replacement);
    }
}

An attacker who opens an HTTP/2 stream, leaves a continuation or trailer header block outstanding, and then resets that stream can win the race between recycling and decoding. The remaining header fields are still emitted into the retired stream object, and from there into a Request that another request may already own, so attacker-chosen trailer fields appear in a request that was never meant to carry them. Exploitation depends entirely on timing and the attacker cannot choose which request receives the injected fields, which is why the impact is rated low.

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.
Vulnerability Details
Severity
Level
CVSS Assessment
Low
>=0 <4
Medium
>=4 <6
High
>=6 <8
Critical
>=8 <10
Low
ID
CVE-2026-77762
PROJECT Affected
Apache Tomcat
Versions Affected
>=8.5.59 <=8.5.100, >=9.0.39 <9.0.122, >=10.1.0-M1 <10.1.60, >=11.0.0-M1 <11.0.26
NES Versions Affected
Published date
September 23, 2026
≈ Fix date
September 25, 2026
Category
HTTP Request Smuggling
Vex Document
Download VEXHow do I use it?
Sign up for the latest vulnerability alerts fixed in
NES for Apache Tomcat
Rss feed icon
Subscribe via RSS
or

By submitting the form I acknowledge receipt of our Privacy Policy.

Thanks for signing up for our Newsletter! We look forward to connecting with you.
Oops! Something went wrong while submitting the form.