Netty CVE-2026-100663

Exploitation requires the target to be a Netty-based HTTP/1-to-HTTP/3 proxy or gateway using io.netty:netty-codec-http3 versions 4.2.2.Final through 4.2.17.Final, where HttpConversionUtil.toHttp3Headers translates inbound HTTP/1 CONNECT requests to HTTP/3, AND where security controls (tunnel allow-lists, egress policy, backend selection, or audit) validate the HTTP/1 CONNECT authority-form request-target before forwarding. The attacker must send a CONNECT request whose authority-form target differs from the Host header (the Host value becomes the forwarded :authority). No authentication or user interaction is required (PR:N/UI:N). Limiting factors: the deployment must actually be doing HTTP/1-to-HTTP/3 tunnel translation and enforcing target-based policy - plain Netty applications not acting as such a proxy are not exposed; if no Host header is present the CONNECT target is dropped rather than redirected.

The vendor CVSS 4.0 vector (8.7) rates this AV:N/AC:L/AT:N/PR:N/UI:N with integrity-only impact (VI:H, VC:N/VA:N), consistent with the description: a remote, unauthenticated client can desynchronize the CONNECT authority between the HTTP/1 request-target and the HTTP/3 :authority to bypass allow-lists and egress/audit controls. There is no confidentiality or availability impact and no code execution - this is a request-translation/smuggling-style policy bypass, so the 8.7 is driven almost entirely by the unauthenticated network reach plus high integrity impact. EPSS, KEV, and public POC signals are all ABSENT from the input: no active exploitation is confirmed (not in CISA KEV) and no public exploit code is referenced, so this is not a drop-everything item despite the high base score. Crucially, exploitability is gated by a specific deployment: the vulnerable code only matters when Netty's netty-codec-http3 is used to build an HTTP/1-to-HTTP/3 proxy/gateway that also enforces security decisions on the CONNECT target - a narrow subset of Netty deployments. Net: a real, credible integrity/authorization-bypass bug worth patching promptly in affected proxy/gateway builds, but not evidenced as widely or automatically exploited.

An organization runs a Netty-based HTTP/1-to-HTTP/3 forward proxy that validates CONNECT request-targets against a tunnel allow-list before forwarding. A remote client sends 'CONNECT trusted.example:443' with a 'Host: blocked.internal:443' header; HttpConversionUtil.toHttp3Headers parses the authority-form target as a URI and emits the attacker's Host value as the HTTP/3 :authority, so the tunnel is established to blocked.internal despite the allow-listed request-target. No public exploit code is identified at time of analysis, and the network/unauthenticated, low-complexity vector makes crafting the request trivial.