CVE-2026-93566 in Netty
Summary
by MITRE • 09/18/2026
### Summary Netty skips strict chunk size line validation when the line has no chunk extension (`;`), so a chunk size line containing an embedded bare CR (e.g. `0\rX`) is accepted instead of rejected, enabling HTTP request smuggling.
### Details `io.netty.handler.codec.http.HttpObjectDecoder#checkChunkExtensions` only runs the strict validator `HttpChunkLineValidatingByteProcessor` when a `;` is present:
```java int extensionsStart = line.bytesBefore((byte) ';'); if (extensionsStart == -1) {
return; } ```
According to RFC 9112 https://datatracker.ietf.org/doc/html/rfc9112#appendix-A
`chunk-size = 1*HEXDIG`
### PoC
```java @Test public void test() {
String requestStr = "POST / HTTP/1.1\r\n" + "Host: localhost\r\n" + "Transfer-Encoding: chunked\r\n\r\n" + "0\rX\r\n" + "\r\n" + "GET /smuggled HTTP/1.1\r\n" + "Host: localhost\r\n" + "Content-Length: 0\r\n" + "\r\n";
EmbeddedChannel channel = new EmbeddedChannel(new HttpRequestDecoder()); assertTrue(channel.writeInbound(Unpooled.copiedBuffer(requestStr, Ch
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/18/2026
The vulnerability identified in Netty involves a critical flaw in the HTTP/1.1 chunked transfer encoding parser within the HttpObjectDecoder component. Specifically, the checkChunkExtensions method fails to enforce strict validation of the chunk size line when no chunk extensions are present. According to RFC 9112, which obsoletes earlier specifications like RFC 7230 and RFC 2616, a valid chunk-size must consist solely of hexadecimal digits followed by optional CRLF or semicolon-delimited extensions. The parser incorrectly assumes that if the line does not contain a semicolon character, it is automatically valid without verifying that the entire line consists exclusively of hex characters. This oversight allows an attacker to inject arbitrary bytes into the stream by embedding a bare carriage return within what appears to be a chunk size declaration.
In practice, this flaw enables HTTP request smuggling attacks when Netty-based servers are placed behind reverse proxies or load balancers that do not perform identical validation checks. An attacker can craft a malicious POST request with Transfer-Encoding: chunked and set the first chunk size line to something like 0\rX instead of the standard 0\r\n. Because the parser sees no semicolon, it skips the strict hex-only validation logic and accepts this malformed input as valid. The embedded carriage return effectively terminates the header section prematurely or shifts parsing boundaries in a way that confuses downstream infrastructure. This discrepancy between how Netty parses incoming requests versus how other systems interpret them creates an opportunity for request smuggling, where subsequent parts of the HTTP message are misinterpreted by backend servers.
The operational impact of this vulnerability is severe, particularly in environments utilizing multiple hops or proxy layers with inconsistent parsing behaviors. Successful exploitation can lead to unauthorized access to internal resources, session hijacking through cookie manipulation, cross-site scripting if user input is reflected improperly after smuggling, and denial of service conditions due to malformed state tracking within the application server. Attackers may also bypass security controls such as Web Application Firewalls that rely on standard HTTP parsing rules but fail to detect these edge-case deviations in chunked encoding syntax. The ability to smuggle requests means an attacker can potentially send commands directly to backend services, circumventing frontend protections entirely.
Mitigation strategies should focus on immediate patching of the Netty library to versions where this validation logic has been corrected to enforce strict hexadecimal-only checks regardless of extension presence. Until patches are applied, administrators should configure reverse proxies and load balancers to reject any chunked requests that do not strictly adhere to RFC 9112 specifications, including rejecting lines with embedded control characters outside the expected CRLF sequence. Additionally, implementing input validation at the application layer to detect anomalous HTTP structures can provide an additional defense-in-depth measure. Security teams should also monitor for unusual traffic patterns indicative of request smuggling attempts, such as repeated failures in chunk parsing or unexpected backend responses that suggest boundary confusion. Regular audits of proxy configurations against current RFC standards are essential to prevent exploitation via this vector across distributed architectures.