CVE-2026-19203

Overview

Eclipse Jetty is an open-source Java web server and Jakarta Servlet container, widely deployed both standalone and embedded inside Java applications and frameworks. Its jetty-http module provides the HTTP/1.1 protocol implementation, including the parser that reads request lines, header fields and chunked message bodies.

An HTTP request smuggling vulnerability (CVE-2026-19203) has been identified in the jetty-http package, which allows attackers to desynchronize Jetty from an intermediary that sits in front of it. Jetty's HTTP/1.1 parser accepts a lone line feed as a line terminator inside chunked transfer coding, after the chunk-size line and its extensions, after the chunk data, and in the trailer section, where the HTTP specification requires a carriage return and line feed pair. A proxy, load balancer or web application firewall that parses chunk framing strictly sees a different request boundary than Jetty does, so bytes the intermediary treats as the tail of one request become a second, attacker-controlled request on the backend connection. Depending on the deployment this enables cache poisoning, bypass of access controls enforced by the intermediary, and hijacking of other users' in-flight requests.

PortSwigger defines the attack class as follows: "HTTP request smuggling is a technique for interfering with the way a web site processes sequences of HTTP requests that are received from one or more users. Request smuggling vulnerabilities are often critical in nature, allowing an attacker to bypass security controls, gain unauthorized access to sensitive data, and directly compromise other application users."

This issue affects Eclipse Jetty 9.4.0 through 9.4.63, 10.0.0 through 10.0.31.1, and 11.0.0 through 11.0.31 on the lines supported by NES for Jetty, as well as the maintained 12.0.x and 12.1.x lines before 12.0.38 and 12.1.12.

Details

Module Info

• Product: Eclipse Jetty
• Affected packages: org.eclipse.jetty:jetty-http
• Affected versions: >=9.4.0 <9.4.64, >=10.0.0 <10.0.32, >=11.0.0 <11.0.32, >=12.0.0 <12.0.38, >=12.1.0 <12.1.12
• GitHub repository: https://github.com/jetty/jetty.project
• Published packages: https://central.sonatype.com/artifact/org.eclipse.jetty/jetty-http
• Package manager: Maven
• Fixed in: NES for Jetty 9.4.64, 10.0.32 and 11.0.32 (upstream community-supported lines fixed in Eclipse Jetty 12.0.38 and 12.1.12)

Vulnerability Info

This High-severity vulnerability is found in the jetty-http package in all affected versions of Eclipse Jetty. Every HTTP/1.1 server connector uses HttpParser to read requests, so any deployment that accepts Transfer-Encoding: chunked request bodies through a strictly parsing intermediary is exposed, in the default RFC7230 compliance mode and without any authentication or user interaction.

The parser tokenizes input one byte at a time. Its next() method tracks whether the previous byte was a carriage return in a _cr flag, but when it meets a line feed it simply clears that flag and returns the same LF token whether or not a carriage return preceded it:

case LF:
    _cr = false;
    break;

Every state that consumes chunk framing then accepts that token as the end of the line. The chunk-size state, including its extension name and value sub-states, ends the chunk header on LF; the state that follows chunk data checks only for the token type:

case CHUNK_END:
    ...
    if (t.getType() != HttpTokens.Type.LF)
        throw new IllegalCharacterException(_state, t, buffer);
    setState(State.CHUNKED_CONTENT);

and the trailer section is read by the same field parser used for headers, which also treats a bare line feed as a line end. Nothing records or rejects the missing carriage return.

RFC 7230 permits a lone line feed as a robustness measure for header lines, but chunk framing is defined strictly in terms of CRLF. An attacker who controls the request body can therefore send a chunk header such as 3D;! terminated by a single \n. Jetty treats the line feed as the end of the header and reads the following 61 bytes as chunk data, while an intermediary that requires CRLF either rejects the header or places the chunk boundary elsewhere. The two hops disagree on where the first request ends, and the bytes that follow, for example a complete GET /smuggled HTTP/1.1 request, are handled by Jetty as a separate request on the same connection that the intermediary never inspected. The same divergence can be produced after the chunk data and in the trailer section.

Mitigation

Jetty 9.4.x, 10.0.x, and 11.0.x are past community End-of-Life and no longer receive open-source updates to address this issue.

The fixed releases reject a bare line feed in chunk framing with a 400 Bad Request response in the default RFC7230 compliance mode and the other non-legacy modes such as RFC2616. Deployments that explicitly configure the LEGACY, RFC7230_LEGACY or RFC2616_LEGACY mode continue to accept it after upgrading (the violation is reported on the request but not enforced), so such deployments should also move to a non-legacy compliance mode to close the issue.

Users of the affected components should apply one of the following mitigations:

• Upgrade Eclipse Jetty to a currently supported release line (12.0.x or 12.1.x) that contains the fix, first shipped in Eclipse Jetty 12.0.38 and 12.1.12.
• Leverage a commercial support partner like HeroDevs for post-EOL security support.

Credits

• yarocher (finder)