Netty CVE-2026-100666

Requires a server built on Netty's HttpServerCodec (io.netty:netty-codec-http) in the affected ranges 4.2.0.Final-4.2.16.Final or ≤4.1.136.Final, handling HTTP/1.1 with request pipelining and Expect/100-continue support (the default codec behavior). The concrete trigger is a single pipelined stream: an HTTP/1.1 GET carrying 'Expect: 100-continue' immediately followed by a HEAD request on the same keep-alive connection. Exploitation is unauthenticated and needs no user interaction (PR:N/UI:N). Limiting factors: real-world impact is amplified when the vulnerable Netty server sits behind a shared/pooled connection (front-end proxy, load balancer, or CDN) so that a desynchronized connection is reused across clients; deployments that disable HTTP/1.1 pipelining or terminate/normalize responses at an upstream that does not reuse the connection reduce the practical risk.

This is a genuine but moderate-priority integrity flaw rather than a high-urgency crisis. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N, VC:L/VI:L/VA:L, score 6.9) indicates fully remote, unauthenticated, low-complexity exploitation against affected default configurations - no user interaction, no privileges, no special attack requirement. That accessibility is offset by low technical impact per metric (each of C/I/A rated Low, no scope change), consistent with a response-desynchronization/smuggling issue (CWE-444) whose consequence is response splitting and unsafe connection reuse rather than direct code execution or data theft. No EPSS score, no CISA KEV listing, and no public POC were provided, so exploitation status is 'no public exploit identified at time of analysis' - this is not confirmed exploited and not known automatable in the wild. Signals are broadly consistent (network vector matches an HTTP-parser bug), with one nuance: the input Tags label this 'Information Disclosure' while CWE-444 and the description point to request/response smuggling (an integrity problem), where any confidentiality impact is a secondary effect of one client receiving another's response. Net: real, patchable, worth remediating in JVM HTTP stacks, but low real-world urgency absent exploitation evidence.

An unauthenticated attacker (or a malicious client behind a shared proxy/load balancer that reuses the connection) sends a single pipelined HTTP/1.1 stream to a Netty-backed server: a GET carrying 'Expect: 100-continue' immediately followed by a HEAD request. The server's 100 Continue response wrongly consumes the queued GET method, so the GET's 200 OK is paired with HEAD (its body dropped) and the HEAD response is written with a body, desynchronizing the connection so the HEAD response body is interpreted as the GET body - enabling response splitting and poisoned connection reuse. No public exploit code was identified in the provided data.