CVE-2026-77762
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
- Published packages:
- Package manager: Maven
- Fixed in:
- NES for Apache Tomcat 8.5.100-tomcat-8.5.112
- Apache Tomcat 11.0.26, 10.1.60, 9.0.122 (OSS)
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.