CVE-2026-100663 in Netty
Summary
by MITRE • 09/26/2026
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.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/26/2026
The vulnerability identified in Netty's HTTP/3 codec module affects versions ranging from 4.2.2.Final through 4.2.17.Final, specifically within the HttpConversionUtil.toHttp3Headers method responsible for translating HTTP/1 messages into HTTP/3 format. This flaw stems from an incorrect handling of HTTP/1 CONNECT requests that utilize the authority-form request-target. In standard HTTP/1 operations, a CONNECT request targets a specific host and port to establish a tunnel through a proxy, typically formatted as target-host:target-port. However, when these messages are converted for transmission over HTTP/3, which utilizes HPACK headers such as :scheme, :path, and :authority instead of the traditional URI structure, the conversion logic fails to properly isolate the authority-form target. Instead of preserving the intended tunnel destination within the correct header fields, the implementation parses the CONNECT request-target as a generic Uniform Resource Identifier. This misinterpretation leads to the host component being incorrectly assigned to the :scheme pseudo-header and the path defaulting to "/", while the actual HTTP/1 Host header is mapped to the :authority pseudo-header in the resulting HTTP/3 frame.
This technical defect creates a significant security gap for organizations utilizing Netty-based proxies or gateways that translate between HTTP/1 and HTTP/3 protocols. The core operational impact arises when a remote client sends a CONNECT request where the authority-form target differs from the value provided in the Host header. Because the conversion logic prioritizes the Host header for the :authority field, an attacker can manipulate this discrepancy to control which destination is actually tunneled through the proxy. For instance, if a client requests a connection to evil.com but sets the Host header to trusted.example.com, the resulting HTTP/3 message will indicate that the tunnel is intended for trusted.example.com. This allows the malicious request to bypass security controls that rely on validating the original CONNECT target against an allow-list or egress policy. The vulnerability effectively decouples the logical destination of the connection from its authenticated identity in the proxy's internal representation, undermining trust boundaries established by network administrators.
The implications of this flaw extend beyond simple tunneling misdirection. In environments where backend selection is determined by the :authority header, an attacker could potentially route traffic to unintended backends or bypass audit controls that log and monitor specific domains. If no Host header is present in the original HTTP/1 request, the vulnerability manifests differently as the CONNECT target may be entirely dropped during conversion, leading to potential denial of service for legitimate tunneling operations or unpredictable behavior depending on how the downstream server handles malformed headers. This inconsistency can complicate troubleshooting and obscure malicious activity from security monitoring tools that depend on accurate header mapping. The issue is classified under CWE-20 Improper Input Validation as it involves a failure to correctly validate and process input data during protocol translation, leading to unauthorized access or policy evasion. Furthermore, this behavior aligns with ATT&CK technique T1572 Protocol Tunneling, where attackers establish encrypted channels to bypass network defenses, although in this case the tunnel itself is manipulated rather than just established.
To mitigate this risk, organizations running affected versions of Netty must upgrade immediately to version 4.2.18.Final or later, which contains a patch that correctly special-cases HTTP/1 CONNECT authority-form request-targets during conversion. Until an upgrade is feasible, administrators should consider implementing strict validation at the application layer before any translation occurs, ensuring that the Host header matches the requested target exactly. Additionally, deploying web application firewalls or reverse proxies with deep packet inspection capabilities can help detect and block anomalous CONNECT requests where header discrepancies suggest exploitation attempts. Regular audits of proxy configurations and monitoring for unusual tunneling patterns are also recommended to maintain visibility into potential abuse vectors while technical remediation is applied.