Netty CVE-2026-42585

Netty must be deployed behind an HTTP proxy (reverse proxy, load balancer, or WAF) that does not strictly comply with RFC 9112 section 6.3 by rejecting malformed Transfer-Encoding headers. Specifically, the proxy must: (1) accept requests with 'Transfer-Encoding: chunked, identity' without responding with 400 Bad Request, (2) interpret the request using Content-Length instead of rejecting it, and (3) forward the malformed request to the Netty backend. Additionally, the chunked transfer encoding parsing path in Netty's HttpRequestDecoder must be reachable (standard configuration; not disabled). Request smuggling is NOT possible if: (a) the proxy validates and rejects RFC 9112 violations before forwarding to Netty, (b) Netty is exposed directly to client connections without an intermediate proxy, or (c) the proxy and Netty agree on message length interpretation (e.g., both default to Content-Length, ignoring Transfer-Encoding).

CVSS 6.5 (AV:N/AC:L/PR:N/UI:N) indicates network-accessible vulnerability with low attack complexity and no authentication required, suggesting significant real-world risk. However, the attack requires a specific deployment condition: Netty must be behind a proxy that (1) does not reject malformed Transfer-Encoding headers, and (2) prefers Content-Length interpretation, creating a parsing disagreement. This is not a default-configuration vulnerability but rather a proxy-layer parsing mismatch scenario. The publicly available proof-of-concept code (included in the advisory) confirms technical feasibility, though active exploitation status (CISA KEV confirmation) is not provided in the input. The low CVSS complexity and unauthenticated network vector, combined with real PoC, suggest this is a genuine priority for deployments with intermediate proxies; however, organizations using Netty without proxies or with RFC-compliant proxies face reduced real-world risk. The CVSS does not capture this conditional exploitation requirement, potentially inflating perceived risk.

An attacker sends a crafted HTTP request to a Netty-based service deployed behind a non-RFC-compliant proxy. The request includes 'Transfer-Encoding: chunked, identity' and 'Content-Length: 48' headers. The proxy, not rejecting this malformation, forwards it to Netty. Netty's HttpRequestDecoder incorrectly interprets the request as chunked and processes the body using chunked transfer encoding rules, allowing the attacker to inject a second GET request (e.g., 'GET /smuggled') inside the first request's body. Netty then parses and routes the smuggled request as a separate HTTP request, potentially bypassing authentication, Web Application Firewall rules, or rate limiting applied to the first request.