Netty CVE-2026-93568

Requires a target running an affected Netty-based service that accepts HTTP/2 or HTTP/3 traffic and processes Extended CONNECT (RFC 8441) requests - i.e., a listener with HTTP/2/3 and CONNECT/WebSocket-over-stream support reachable by the attacker. Per the vendor vector (AV:N/AC:L/PR:N/UI:N) no authentication or user interaction is needed against such an endpoint, but the practical impact is LIMITED to deployments where a fronting proxy or gateway and a backend interpret the downgraded request differently (a request-smuggling/desync topology); a standalone server that simply mishandles the method has far less exploitable consequence. Exposure is further limited to products/versions bundling the vulnerable Netty codec and to endpoints where HTTP/2 or HTTP/3 Extended CONNECT is actually enabled.

Signals are mixed and lean toward a moderate, conditional priority rather than an urgent one. The vendor (Red Hat) CVSS 3.1 vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N yields 7.5 driven purely by integrity impact (I:H), with no confidentiality or availability effect - consistent with a protocol/method-confusion class flaw (CWE-20) in the Netty codec where HTTP/2 and HTTP/3 Extended CONNECT (RFC 8441, the mechanism carrying WebSockets/other protocols inside a stream) is decoded as a plain CONNECT tunnel request. No EPSS score, no CISA KEV listing, and no public exploit code are provided in the input, so this is 'no public exploit identified at time of analysis' - not confirmed active exploitation. No SSVC decision data was supplied. The realistic ceiling on risk is that method/protocol downgrade only becomes dangerous in a multi-hop deployment (e.g., a fronting proxy or gateway plus a backend that disagree on how the request is interpreted), which argues the effective attack complexity is higher than the AC:L in the vector suggests, and a scope change (S:C) across the proxy/backend boundary is defensible. The 'Information Disclosure' tag conflicts with the vendor's own C:N/I:H scoring - this is an integrity/request-smuggling issue, not a data-disclosure one. Bottom line: a legitimate 'high' by score, but real-world exploitability depends on a specific proxy/backend topology, so treat it as patch-in-normal-cycle for exposed Netty-fronted HTTP/2/3 endpoints rather than an emergency.

An attacker sends an HTTP/2 or HTTP/3 Extended CONNECT request (e.g., an :protocol WebSocket upgrade) to a Netty-based server or gateway that mishandles it as a regular CONNECT, causing the front-end and back-end to disagree on the request's meaning and enabling request smuggling or unintended tunnel/method confusion. No authentication or user interaction is required per the CVSS vector, but meaningful impact generally requires a proxy-plus-backend topology where the parsing disagreement can be leveraged. No public proof-of-concept is included in the provided intelligence.