Description

Netty's HTTP/3 codec (io.netty:netty-codec-http3) from 4.2.2.Final through 4.2.17.Final does not special-case HTTP/1 CONNECT authority-form request-targets when converting HTTP/1 messages to HTTP/3 in HttpConversionUtil.toHttp3Headers. The authority-form target (e.g., "CONNECT trusted.example:443") is parsed as a URI, so its host is emitted as :scheme, :path is set to "/", and the HTTP/1 Host header is used as :authority; if no Host header is present the CONNECT target is dropped. In a Netty-based HTTP/1-to-HTTP/3 proxy or gateway, a remote client can send a CONNECT request whose Host header names a different authority than the request-target, producing a malformed HTTP/3 CONNECT whose tunnel :authority is attacker-controlled. This can bypass tunnel allow-lists, egress policy, backend selection, or audit controls that validate the HTTP/1 CONNECT request-target before forwarding over HTTP/3. The issue is fixed in 4.2.18.Final.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-09-26T14:16:49.400Z",
  "pubdate": "2026-09-26T14:16:49.400Z",
  "executiveSummary": "Netty's io.netty:netty-codec-http3 component is vulnerable to an HTTP/1-to-HTTP/3 translation flaw when processing CONNECT requests. The vulnerability resides in HttpConversionUtil.toHttp3Headers, which fails to correctly sanitize request-target authority-form values during the protocol translation process.\nThe issue permits a remote attacker to manipulate the :authority pseudo-header transmitted over HTTP/3 by injecting a conflicting Host header in the original HTTP/1 CONNECT request. This discrepancy allows for the bypass of security controls, including egress filtering, tunnel allow-lists, and backend access control policies.\nImpacted systems include Netty-based HTTP/1-to-HTTP/3 proxies or gateways. An attacker capable of sending HTTP/1 requests to such a gateway can exploit this to route traffic to unauthorized destinations, effectively circumventing network-level access restrictions. The risk is significant as it undermines the integrity of the proxy's routing logic and security audit trails. Exploitation requires no special authentication, relying purely on the ability to send malformed HTTP requests to the target proxy.\nThis vulnerability affects Netty versions 4.2.2.Final through 4.2.17.Final. It is remediated in version 4.2.18.Final.",
  "technicalDetails": "The root cause of the vulnerability lies in the improper handling of CONNECT request-targets in the HttpConversionUtil.toHttp3Headers method. When converting HTTP/1 messages to HTTP/3, the library treats the CONNECT request-target (e.g., 'CONNECT trusted.example:443') as a URI during the parsing phase. Consequently, the utility incorrectly assigns the parsed host value to the :scheme pseudo-header, sets the :path to '/', and relies on the HTTP/1 'Host' header to define the HTTP/3 ':authority' pseudo-header.\nIn a proxy scenario, an attacker can intentionally provide an HTTP/1 CONNECT request where the request-target authority and the 'Host' header are mismatched. Because the proxy logic prioritizes the 'Host' header to populate the HTTP/3 ':authority' field, the resulting HTTP/3 request is dispatched to the host specified by the attacker-controlled 'Host' header rather than the intended target specified in the URI path.\nThe attack flow follows these steps: 1) The attacker initiates an HTTP/1 CONNECT request toward the Netty-based proxy, specifying a benign or authorized endpoint in the request-target URI. 2) The attacker inserts a 'Host' header in the HTTP/1 request that points to a malicious or restricted target server. 3) The HttpConversionUtil.toHttp3Headers method processes the request, incorrectly parsing the URI but subsequently adopting the attacker-supplied 'Host' header as the authoritative destination for the HTTP/3 tunnel. 4) The Netty proxy then opens an HTTP/3 tunnel to the attacker's chosen backend, effectively bypassing any validation logic that only inspected the original HTTP/1 request-target.\nThis vulnerability is particularly dangerous in environments where egress policy is enforced based on the initial request-target validation. By decoupling the target identified in the request-target from the target utilized in the HTTP/3 tunnel header, an attacker can tunnel traffic to arbitrary network destinations that the proxy was intended to protect or block.\nThe component affected is 'io.netty:netty-codec-http3', specifically the 'HttpConversionUtil' utility class. Versions ranging from 4.2.2.Final to 4.2.17.Final are susceptible. Exploitation does not require authentication and can be performed from any location capable of reaching the proxy's HTTP/1 interface.\nThe post-exploitation impact includes unauthorized data exfiltration, bypassing perimeter security, and potential compromise of internal services that assume the proxy's egress policy is enforced correctly."
}