Netty netty-codec-http CVE-2026-59898

Exploitation requires that the Netty application instantiates WebSocketServerHandshakerFactory with support for V07 or V08 protocol versions (i.e., the allowExtensions or version-range configuration includes version 7 or 8); applications that configure V13-only handshakers are not affected. A reverse proxy, load balancer, or CDN edge node must be positioned in front of the Netty instance for the protocol-confusion desynchronization to be leveraged for HTTP request smuggling - without an intermediary, the attacker only completes an unintended WebSocket upgrade rather than smuggling requests into other users' traffic. The attacker must be able to send arbitrary HTTP headers (including Sec-WebSocket-Version: 7) to the proxied endpoint, which is possible from any network-reachable HTTP client. Authentication requirements are not confirmed by a CVSS vector in the available data; however, the described attack path operates at the HTTP header level prior to any application-layer authentication. The V07/V08 handshakers are legacy and less commonly enabled than V13, so this condition meaningfully limits the exposed population.

No CVSS vector or EPSS score is provided in the available data, preventing quantitative scoring. From the description and CWE-444 classification, the attack is network-reachable and requires no authentication (header manipulation in a plain HTTP request), but the smuggling impact is only weaponizable when a proxy or load balancer sits in front of the Netty instance - without this intermediary, an attacker completes an unexpected WebSocket upgrade but cannot leverage the desync for cross-user impact. This topology dependency elevates attack complexity from a real-world standpoint even though the manipulation itself is trivially simple. There is no CISA KEV listing and no evidence of public exploit code, making active exploitation unconfirmed; however, HTTP desync techniques are well-understood in the security community, lowering the bar for skilled attackers. Deployments running Netty behind nginx, HAProxy, AWS ALB, or similar proxies with V07/V08 WebSocket support enabled represent the highest-risk tier. Deployments that expose Netty directly or enforce V13-only WebSocket are materially less exposed. The CWE-444 tag aligns with the HTTP request smuggling / protocol confusion impact, but actual data exfiltration severity depends on what is accessible over shared backend connections.

An attacker targeting a Netty-backed WebSocket service behind a reverse proxy crafts an HTTP request containing Sec-WebSocket-Version: 7 while deliberately omitting Connection: Upgrade and Upgrade: websocket headers; the proxy, seeing no upgrade signal, treats this as a normal HTTP request and forwards it without establishing a dedicated WebSocket tunnel, while Netty's V07 handshaker silently completes the protocol switch. The attacker then exploits the resulting connection desynchronization to prepend a smuggled HTTP request to the next legitimate user's traffic flowing over the shared backend connection, potentially reading that user's session token, request body, or response, or injecting a response that poisons a shared cache. No public proof-of-concept code has been identified at time of analysis, but the technique maps directly to well-documented HTTP request smuggling methodology.