CVE-2026-93573: Io.netty/netty-codec-http: netty split transfer-encoding fields bypass final-chunked validation and enable request smuggling
Netty split Transfer-Encoding fields bypass final-chunked validation and enable request smuggling
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
maven:io.netty:netty-codec-httpto a version that resolves this vulnerability.Fixed in 4.1.132.FinalPatch unknown - Upgrade
Upgrade
maven:io.netty:netty-codec-httpto a version that resolves this vulnerability.Fixed in 4.2.12.FinalPatch unknown - Compensating control
Add compensating validation in front of Netty (or at the network edge) to reject HTTP/1.1 requests where Transfer-Encoding is expressed as split header fields such that the last Transfer-Encoding token is not the final coding per RFC 9112 framing rules (e.g., reject cases like "Transfer-Encoding: chunked" followed by a second Transfer-Encoding field like "gzip" or "deflate").
Event History
Frequently Asked Questions
What request pattern is needed to trigger the issue?
An attacker can send an HTTP/1.1 request with Transfer-Encoding split across multiple header fields so that chunked is followed by a non-final coding in a later field, such as "Transfer-Encoding: chunked" followed by "Transfer-Encoding: gzip" or "deflate". Netty accepts the zero-size chunk terminator and can parse subsequent bytes as a second request on the same connection.
Does exploitation require authentication or user interaction?
No. The supplied severity vector indicates network-based exploitation with low attack complexity, no privileges required, and no user interaction.
What security impact can request smuggling have in this case?
The supplied severity vector indicates low confidentiality and low integrity impact, with no availability impact. The described behavior allows a following request to be parsed on the same connection after the malformed Transfer-Encoding sequence is accepted.
How can I check whether traffic is attempting to exploit this issue?
Inspect HTTP/1.1 requests for multiple Transfer-Encoding header fields where an earlier field contains chunked and a later field contains another transfer coding, such as gzip or deflate. These fields combine into an invalid ordering in which chunked is not the final transfer coding.