CVE-2026-59898

CVE-2026-59898 is a WebSocket handshake validation flaw in Netty affecting the legacy V07 and V08 draft protocol handshakers. The current V13 (RFC 6455) handshaker correctly validates certain HTTP headers that the older draft implementations do not validate — specifically, headers that distinguish legitimate upgrade requests from requests that could be interpreted as other protocols. This gap enables HTTP smuggling through proxies that rely on WebSocket upgrade detection to route traffic. The practical risk is concentrated in a specific configuration intersection: you need a deployment where V07 or V08 handshakers are actively handling traffic (not just present in the codebase), and a reverse proxy or API gateway that cannot distinguish upgrade requests from regular HTTP when those headers are absent. In single-tenant or homogeneous proxy setups, exploitation is difficult. In multi-tenant environments with generic proxy configurations — particularly those using the handshaker selection logic that defaults to the oldest compatible version — the attack surface is real. This explains the EPSS score hovering around 0.002 despite a 7.5 CVSS: exploitation is not opportunistic, it requires target-specific reconnaissance, which suppresses the automated scanning activity EPSS monitors. What makes this notable is the pattern, not just the bug. V07 and V08 were deprecated rather than removed, and deprecation in protocol handlers carries a specific epistemic risk: monitoring and fuzzing attention drops off, but code execution paths remain reachable. The validation gap in V13 was hardened years ago; V07 and V08 carried forward the original permissive assumptions because nobody was actively testing them. This is the same pattern seen in TLS fallback, SSH algorithm deprecation, and HTTP pipeline handling — deprecated protocol handlers become invisible attack surfaces that only surface when something else (in this case, proxy misconfiguration) creates the trigger condition. Check your Netty usage directly: if you're explicitly constructing a WebSocketServerHandshakerFactory or have dependencies that do, audit which protocol version is being negotiated. Look for any code path that could result in the V07 or V08 handshaker being selected, particularly if your deployment uses a proxy that performs protocol detection. The fix is available in 4.1.136.Final and 4.2.16.Final — update to these versions or later. If you cannot update, ensure your proxy configuration explicitly validates WebSocket upgrade requests and does not treat ambiguous requests as upgrades by default. Treat any V07/V08 code path in your dependency tree as actively insecure until verified otherwise.

Reviewed through automated stages and approved by a human before publication.