CVE-2026-77756

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.

An HTTP Request Smuggling vulnerability (CVE-2026-77756) has been identified in the Coyote HTTP/1.1 processor, which allows attackers to send an HTTP/1.0 request carrying a transfer-encoding header that Tomcat parses with chunked input filters while a front-end reverse proxy reads the same bytes differently, causing another user's request on the reused connection to fail.

Per OWASP: HTTP Request Smuggling is a class of vulnerabilities caused by inconsistencies in how HTTP requests are parsed by frontend and backend components.

This issue affects the HTTP/1.1 connector of Apache Tomcat in the 8.5.x, 9.0.x, 10.1.x, and 11.0.x lines, including the End-of-Life 8.5.100 release.

Details

Module Info

• Product: Apache Tomcat
• Affected packages: tomcat-coyote, tomcat-embed-core
• Affected versions: >=8.5.67 <=8.5.100, >=9.0.47 <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: https://central.sonatype.com/artifact/org.apache.tomcat/tomcat-coyote, https://central.sonatype.com/artifact/org.apache.tomcat.embed/tomcat-embed-core

• 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.http11.Http11Processor request processor. After the request line and headers are parsed, prepareInputFilters() decides how the request body is delimited: a transfer-encoding header selects the chunked input filter, while a content-length header selects the identity filter. The transfer-encoding header is defined by HTTP/1.1; HTTP/1.0 and earlier have no notion of chunked transfer coding, so an HTTP/1.0 message that carries one has no agreed body framing.

The gate around that parsing excluded only HTTP/0.9, so every HTTP/1.0 request was treated like an HTTP/1.1 request for the purposes of body framing:

private void prepareInputFilters(MimeHeaders headers) throws IOException {

    contentDelimitation = false;

    InputFilter[] inputFilters = inputBuffer.getFilters();

    // Parse transfer-encoding header
    // HTTP specs say an HTTP 1.1 server should accept any recognised
    // HTTP 1.x header from a 1.x client unless the specs says otherwise.
    if (!http09) {
        MessageBytes transferEncodingValueMB = headers.getValue("transfer-encoding");
        if (transferEncodingValueMB != null) {
            List<String> encodingNames = new ArrayList<>();
            if (TokenList.parseTokenList(headers.values("transfer-encoding"), encodingNames)) {
                for (String encodingName : encodingNames) {
                    addInputFilter(inputFilters, encodingName);
                }
            } else {
                // Invalid transfer encoding
                badRequest("http11processor.request.invalidTransferEncoding");
            }
        }
    }
}

Because http09 is false for an HTTP/1.0 request, a request such as POST /app/target HTTP/1.0 with Transfer-encoding: chunked reaches addInputFilter() and is body-parsed as a chunked request instead of being rejected, and Tomcat's own test suite for the affected line asserts that exactly this request shape returns 200 with the decoded body. The attacker-controlled input is therefore the request line version token together with the transfer-encoding header, both read straight off the connection before any application code runs.

The exposure appears when Tomcat sits behind a reverse proxy. A proxy that correctly refuses to apply chunked semantics to an HTTP/1.0 message, or that frames the body using content-length instead, disagrees with Tomcat about where the request ends. The leftover or truncated bytes stay in the stream, so the next request carried over that connection, which can belong to a different user, is parsed from the wrong offset and fails. Because the divergence only lets an attacker break a neighbouring request rather than control its contents or reach protected resources, the impact is limited to that request failing, which is why the issue 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.