CVE-2026-93562: Io.netty/netty-codec-http: netty: incomplete validation of malformed transfer-encoding allows http request smuggling
A flaw was found in Netty's HTTP/1 decoder. Incomplete validation of malformed Transfer-Encoding headers allows a remote attacker to perform HTTP request smuggling. By sending specially crafted HTTP requests, an attacker can inject arbitrary HTTP requests, potentially bypassing security controls or accessing unauthorized resources.
Other sources
Incomplete validation of malformed Transfer-Encoding allows HTTP request smuggling
A public GitHub Security Advisory (GHSA-hcvj-94mj-jp5c) describes the following issue:
Summary
Netty's HTTP/1 decoder still accepts some malformed Transfer-Encoding values where chunked is present but is not the final transfer coding. This appears to be an incomplete fix / bypass of CVE-2026-42585 / GHSA-38f8-5428-x5cv. The canonical case Transfer-Encoding: chunked, gzip is rejected, but multi-line and pseudo-suffix variants are still accepted and decoded as chunked, which can lead to HTTP request smuggling in parser-differential deployments.
Details
The issue is in io.netty.handler.codec.http.HttpObjectDecoder#readHeaders.
Current behavior uses two different checks:
- HttpUtil.isTransferEncodingChunked(...) detects an exact chunked token anywhere in any Transfer-Encoding field. - readHeaders(...) then checks whether chunked is last by testing whether the last raw Transfer-Encoding field value ends with the string chunked.
This suffix check is not equivalent to parsing the final transfer-coding token.
Examples that are incorrectly accepted:
Transfer-Encoding: chunked Transfer-Encoding: gzip This is semantically equivalent to Transfer-Encoding: chunked, gzip, where chunked is not final.
Transfer-Encoding: chunked, xchunked
The final transfer coding is xchunked, not chunked, but the raw value ends with chunked.
RFC 9112 requires request messages where chunked is not the final transfer coding to be rejected with 400 and the connection closed.
PoC you can run this code TransferEncodingSmugglingReproducer.java
Impact HTTP Request Smuggling: Attacker injects arbitrary HTTP requests
This can be used as the fix patch netty-te-final-token.patch
Affected: - maven:io.netty:netty-codec-http affected >=4.2.0.Final, <=4.2.17.Final; fixed unknown - maven:io.netty:netty-codec-http affected <=4.1.137.Final; fixed unknown
Fixed versions: see advisory
Advisory: https://github.com/netty/netty/security/advisories/GHSA-hcvj-94mj-jp5c
— Red Hat
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.2.0.Final - Upgrade
Upgrade
maven:io.netty:netty-codec-httpto a version that resolves this vulnerability.Fixed in 4.1.137.Final - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Patch GHSA-hcvj-94mj-jp5c
Event History
Frequently Asked Questions
What deployment pattern is most exposed to exploitation?
Parser-differential deployments are most exposed, where Netty's HTTP/1 decoder and another HTTP component interpret Transfer-Encoding headers differently. This can allow a crafted request to be decoded as chunked by Netty while another component handles its boundaries differently.
Does exploitation require authentication or user interaction?
No. The reported vector is network-accessible with low attack complexity, no privileges required, and no user interaction required.
Are only standard malformed Transfer-Encoding values affected?
No. Although the canonical "Transfer-Encoding: chunked, gzip" case is rejected, multi-line and pseudo-suffix variants where chunked is not the final transfer coding may still be accepted and decoded as chunked.
Is this related to an earlier Netty request-smuggling issue?
Yes. The advisory describes this as an incomplete fix or bypass of CVE-2026-42585, involving remaining malformed Transfer-Encoding parsing cases.