Listen to this Post
How the mentioned CVE works:
Netty fails to reject HTTP requests where Transfer-Encoding header contains a malformed value like “chunked, identity”. According to RFC 9112, if chunked is not the final encoding, server must return 400 Bad Request and close connection. Netty incorrectly marks such request as chunked, ignoring the identity suffix. When Netty sits behind a proxy that forwards the request (e.g., a proxy that prefers Content-Length and does not validate Transfer-Encoding), the proxy may compute message body length using Content-Length header while Netty uses chunked decoding. This discrepancy allows an attacker to craft a request where the proxy sees one message boundary but Netty sees another. The PoC sends a POST request with both Transfer-Encoding: chunked, identity and Content-Length: 48. The body contains a fake “0\r\n\r\n” to prematurely end chunked stream, followed by a smuggled GET request. Netty reads the first request, processes the chunked body until the “0\r\n\r\n”, then interprets remaining bytes as a second independent HTTP request. This causes request smuggling – the smuggled request is processed by Netty as if it arrived in a separate connection, bypassing authentication or frontend security.
DailyCVE form:
Platform: Netty
Version: <4.1.94.Final
Vulnerability : Request smuggling
Severity: Critical
date: 2023-06-06
Prediction: 2023-06-20
What Undercode Say:
Verify vulnerable Netty version grep -A 1 '<artifactId>netty-all</artifactId>' pom.xml | grep version Test with curl using malformed header curl -i -H "Transfer-Encoding: chunked, identity" -H "Content-Length: 48" -d $'0\r\n\r\nGET /admin HTTP/1.1\r\nHost: victim.com\r\n\r\n' http://target:8080/post
// EmbeddedChannel test from PoC EmbeddedChannel channel = new EmbeddedChannel(new HttpRequestDecoder()); String exploit = "POST / HTTP/1.1\r\nHost: localhost\r\nTransfer-Encoding: chunked, identity\r\nContent-Length: 48\r\n\r\n0\r\n\r\nGET /smuggled HTTP/1.1\r\nHost: localhost\r\n\r\n"; channel.writeInbound(Unpooled.copiedBuffer(exploit, CharsetUtil.US_ASCII));
Exploit:
Attacker sends a single HTTP request with conflicting Transfer-Encoding and Content-Length. Frontend proxy uses Content-Length (48 bytes), forwarding exactly 48 bytes. Netty processes chunked encoding, stops at “0\r\n\r\n”, treats remaining “GET /smuggled …” as subsequent request. Attacker can inject arbitrary HTTP methods, paths, and headers, potentially hijacking sessions, accessing internal endpoints, or performing cache poisoning.
Protection from this CVE:
Upgrade Netty to version 4.1.94.Final or later. If upgrade impossible, deploy a reverse proxy that strictly validates Transfer-Encoding: reject any value where chunked is not the final encoding (e.g., using ModSecurity or HAProxy with rule rejecting “chunked, identity” or multiple encodings). Alternatively, configure frontend proxy to normalize or remove conflicting headers per RFC compliance.
Impact:
HTTP request smuggling – attacker can bypass frontend security controls, poison caches, steal sensitive data from other users’ requests, and perform cross-user attacks. Server may misinterpret request boundaries, leading to unauthorized access, credential theft, or full compromise of backend application logic.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
