CVE-2026-59898

What it actually does

Prior to Netty 4.1.136.Final and 4.2.16.Final, the legacy WebSocket V07/V08 handshaker can accept a WebSocket protocol switch when a request includes `Sec-WebSocket-Version: 7` or `Sec-WebSocket-Version: 8` but omits the normal `Connection: Upgrade` and `Upgrade: websocket` headers. This creates a protocol-state mismatch between Netty and upstream HTTP intermediaries such as reverse proxies, load balancers, gateways, or WAFs. The proxy may continue treating the connection as ordinary HTTP while the backend Netty application has switched to WebSocket framing, enabling HTTP request smuggling or protocol-confusion behavior under specific deployment conditions.

Why it matters to the business

Applications using vulnerable Netty versions behind HTTP intermediaries may be exposed to request-routing confusion, security-control bypass, or unauthorized interaction with backend services. The issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has low EPSS, and has no public exploit maturity reported, but it affects a widely used Java networking framework and should be prioritized for internet-facing services, API gateways, WebSocket endpoints, and systems where reverse proxies sit in front of Netty-based applications.

How an attack unfolds

An attacker sends a crafted HTTP request to a Netty-based WebSocket endpoint using an old WebSocket version header such as `Sec-WebSocket-Version: 7` or `Sec-WebSocket-Version: 8` while intentionally omitting the standard upgrade headers. A front-end proxy or gateway does not recognize the request as a WebSocket upgrade and continues to process the connection as HTTP. The vulnerable Netty backend, however, accepts the lax V07/V08 handshaker path and transitions the connection into WebSocket mode. This disagreement lets the attacker create protocol confusion between the proxy and backend. Depending on proxy behavior, connection reuse, routing rules, and application logic, the attacker may be able to smuggle subsequent traffic, bypass proxy-layer assumptions, or interact with backend request handling in unintended ways.

How to fix it

Upgrade Netty to a fixed release: 4.1.136.Final or later on the 4.1.x line, or 4.2.16.Final or later on the 4.2.x line. Because Netty is frequently included transitively through frameworks, application servers, RPC libraries, and gateway components, inspect dependency trees and rebuild applications to ensure the effective runtime version is fixed. If immediate upgrade is not possible, restrict or disable legacy WebSocket V07/V08 support where feasible, require strict validation that WebSocket upgrades include both `Connection: Upgrade` and `Upgrade: websocket`, and configure proxies/WAFs to reject requests containing `Sec-WebSocket-Version: 7` or `Sec-WebSocket-Version: 8` when the required upgrade headers are absent. Apply mitigations consistently at all HTTP ingress points, not only at the application layer.

How to confirm the fix worked

Confirm that all deployed artifacts resolve Netty to version 4.1.136.Final, 4.2.16.Final, or newer by checking build dependency output, software composition analysis results, container image contents, and runtime classpath where possible. Test exposed WebSocket endpoints with malformed upgrade attempts containing `Sec-WebSocket-Version: 7` or `Sec-WebSocket-Version: 8` but missing `Connection: Upgrade` and `Upgrade: websocket`; fixed systems should reject the request and must not switch protocols. Validate that reverse proxies and application logs agree on request handling, and confirm that gateway/WAF rules block malformed legacy WebSocket upgrade attempts before they reach backend services.

Typical attack path

1. Identify a public or reachable service that uses Netty for WebSocket handling and is positioned behind a reverse proxy, load balancer, API gateway, or WAF.
2. Send a WebSocket-like HTTP request using `Sec-WebSocket-Version: 7` or `Sec-WebSocket-Version: 8` while omitting `Connection: Upgrade` and `Upgrade: websocket`.
3. Cause the backend Netty server to switch protocols while the front-end intermediary continues to treat the connection as normal HTTP.
4. Abuse the protocol-state mismatch to attempt HTTP request smuggling, connection desynchronization, routing confusion, or bypass of intermediary controls.
5. Use any resulting backend reachability or request interpretation gap to access unintended application functionality or influence downstream request processing.

How to detect it

Review HTTP access logs, reverse proxy logs, WAF logs, load balancer logs, and application logs for requests containing `Sec-WebSocket-Version: 7` or `Sec-WebSocket-Version: 8` that do not also include `Connection: Upgrade` and `Upgrade: websocket`. Pay particular attention to requests sent to WebSocket paths, API endpoints that normally support persistent connections, or endpoints followed by unusual 101 Switching Protocols responses, connection reuse anomalies, malformed request parsing errors, backend-only requests not visible at the proxy layer, or mismatched status codes between proxy and application logs. Investigate sessions where a front-end component logged an ordinary HTTP request but the backend logged a WebSocket handshake or protocol transition. There are no named threat actors reported for this issue in the provided data, so detection should focus on protocol anomalies rather than actor-specific tooling.

• Sec-WebSocket-Version: 7
• Sec-WebSocket-Version: 8
• Sec-WebSocket-Version: 7 without Connection: Upgrade
• Sec-WebSocket-Version: 8 without Connection: Upgrade
• Sec-WebSocket-Version: 7 without Upgrade: websocket
• Sec-WebSocket-Version: 8 without Upgrade: websocket
• HTTP 101 Switching Protocols with missing Connection: Upgrade
• HTTP 101 Switching Protocols with missing Upgrade: websocket
• io.netty.handler.codec.http.websocketx.WebSocketServerHandshaker07
• io.netty.handler.codec.http.websocketx.WebSocketServerHandshaker08

What your security team should do

• Inventory all applications, gateways, and services that include Netty, including transitive dependencies embedded through Java frameworks and vendor products.
• Prioritize upgrades for internet-facing services, WebSocket endpoints, API gateways, and systems behind reverse proxies or load balancers.
• Upgrade to Netty 4.1.136.Final or later, or 4.2.16.Final or later, then rebuild and redeploy affected applications.
• Add temporary proxy/WAF controls to reject requests with `Sec-WebSocket-Version: 7` or `Sec-WebSocket-Version: 8` when `Connection: Upgrade` or `Upgrade: websocket` is missing.
• Search HTTP access logs for malformed legacy WebSocket upgrade attempts and review any matching sessions for follow-on anomalous requests over the same connection.
• Monitor vendor advisories for frameworks or products that bundle Netty and apply their product-specific updates when direct dependency upgrades are not available.
• Because this issue is not currently KEV-listed and has low EPSS, treat it as a targeted hardening priority rather than an emergency mass-exploitation event, unless exposed WebSocket services are critical or high-risk.