REDHAT-BUG-2536951: Medium severity Netty netty-codec-http vulnerability
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
Affected Software
Event History
Frequently Asked Questions
Which deployments are most exposed to exploitation?
Deployments using Netty's HTTP/1 decoder in a parser-differential request path are exposed. This includes paths where another HTTP component interprets Transfer-Encoding differently from Netty.
What does an attacker need to send to trigger the parsing issue?
The attacker needs to submit an HTTP/1 request with malformed Transfer-Encoding values in which chunked is present but is not the final transfer coding. Multi-line Transfer-Encoding fields and pseudo-suffix forms may be accepted and decoded as chunked.