Netty CVE-2026-89044

The vulnerable code path is triggered by any HTTP/1.1 request carrying a Transfer-Encoding header where either (a) multiple comma-separated coding tokens are present and the final token is not exactly 'chunked' (e.g., 'chunked, xchunked'), or (b) the Transfer-Encoding header is split across multiple header lines so the decoder examines only a subset of codings. No authentication or account is required; an attacker needs only the ability to send raw HTTP/1.1 requests to a Netty server running 4.1.133-4.1.137.Final or 4.2.13-4.2.17.Final. The most severe exploitation outcomes require Netty to sit behind an HTTP proxy, load balancer, or CDN edge that parses TE headers under different rules, creating the framing disagreement characteristic of classic request smuggling. In direct client-to-Netty deployments with no intermediary, practical impact is substantially reduced since no proxy disagreement exists to exploit.

The CVSS 4.0 score of 6.9 (Medium) reflects limited per-request confidentiality and integrity impact with no availability component, but the operational significance of request smuggling exceeds its raw numerical score because it can chain into session hijacking, WAF bypass, cache poisoning, and unauthorized access to internal APIs. The attack vector is network (AV:N), requires no authentication (PR:N), and no user interaction (UI:N), making it remotely exploitable against any Netty-based HTTP server or reverse proxy in the affected version window. EPSS data is not supplied in the input and the vulnerability is absent from CISA KEV, suggesting no confirmed mass exploitation at time of analysis; even a mid-sized municipal IT team in ustka running a Netty-based shared API gateway should treat this as urgent given that smuggling primitives are most dangerous in multi-tenant or shared-connection deployments. The narrow affected version range - five patch releases in each branch - limits the total exposed population, but Netty's foundational role in the Java ecosystem means real-world exposure is plausible across many downstream products. No POC exploit code is referenced in the advisory or the VulnCheck report.

An attacker sends an HTTP request to a Netty-based server or reverse proxy containing a Transfer-Encoding header with the value 'chunked, xchunked' or split across continuation lines. Netty's decoder treats the message as chunked-encoded because 'chunked' appears somewhere in the TE fields and the final-coding check is bypassed, while an upstream load balancer or CDN edge node interprets the framing boundary differently. The discrepancy allows a hidden secondary HTTP request body to be injected into the TCP connection pipeline, where it is processed by the backend as the next client's legitimate request, potentially exposing session tokens or bypassing authentication middleware applied at the proxy layer.