Netty's HttpServerCodec mispairs each outbound response with an inbound request by polling only once per response, even for 1xx informational responses. When a client pipelines a GET request with "Expect: 100‑continue" followed by a HEAD request, the 100‑continue response consumes the queued GET method. The subsequent 200 OK for the GET is paired with the HEAD response, causing the GET body to be dropped and the HEAD body to be interpreted as the GET body. This desynchronization results in response splitting, data loss, and unsafe reuse of the connection. The flaw is a classic instance of improper handling of HTTP semantics (CWE‑444).

The vulnerability exists in Netty’s Netty project, specifically the io.netty:netty-codec-http component. It affects versions 4.2.0.Final through 4.2.16.Final and all earlier releases up to 4.1.136.Final. Both the 4.2 and 4.1 lines are affected; the fix begins with 4.2.17.Final and 4.1.137.Final.

The vulnerability carries a CVSS score of 6.9, indicating a moderate to high risk. No EPSS score is currently available, so the likelihood of automated exploitation cannot be quantified. It is not listed in the CISA KEV catalog, suggesting no confirmed large-scale attacks. Exploitation requires an attacker-controlled client to send pipelined HTTP/1.1 requests with an "Expect: 100‑continue" header followed by a HEAD request. The attack vector is therefore over the network on any exposed HTTP endpoint that uses the affected Netty codec. While the impact is contained to the connection and downstream response handling, it can lead to data leakage, incorrect application logic, or denial of correct request processing.