Netty’s HTTP parser historically removed a conflicting Content‑Length header when both Transfer‑Encoding: chunked and Content‑Length appeared together in HTTP/1.1 requests. However, for HTTP/1.0 incoming requests the sanitization guard was omitted. An attacker can send an HTTP/1.0 message containing both headers, causing Netty to parse the body as chunked while retaining the Content‑Length value in the forwarded message. Downstream proxies or handlers that rely on Content‑Length instead of Transfer‑Encoding will see misaligned boundaries, enabling classic request smuggling. This can lead to message injection, credential leakage, or denial of service, depending on how the downstream component processes the body.

The vulnerability affects any application that uses Netty versions prior to 4.2.13.Final or 4.1.133.Final. The affected vendor is Netty, and the impacted product is the Netty networking framework. The fix is available in the referenced releases.

The CVSS score of 5.8 indicates moderate severity. EPSS data is not available, and the flaw is not listed in CISA KEV, so the likelihood of widespread exploitation is uncertain. Nevertheless, the attack vector is straightforward: an attacker simply sends a crafted HTTP/1.0 request to any service that uses an affected Netty version, and the mis‑parsed message boundaries create an exploitable smuggling condition. The mitigations rely on version upgrade or runtime checks, so without these the risk remains moderate to high for exposed services.