Netty’s HTTP/3 codec mishandles HTTP/1 CONNECT requests that use the authority-form target. When a client sends a CONNECT instruction such as "CONNECT trusted.example:443" with a Host header that names a different authority than the request‑target, the codec converts the target to a malformed HTTP/3 CONNECT. The resulting :authority field in the HTTP/3 message is derived from the attacker‑controlled Host header, allowing an unauthorized tunnel to be established and bypassing tunnel allow‑lists, egress policies, backend selection checks, or audit controls that rely on the original HTTP/1 CONNECT target. This flaw arises from improper input validation (CWE-20) and misinterpretation of the request target as a flow‑based locator (CWE-444). If the Host header is omitted entirely, the CONNECT target is dropped by Netty, which does not create a usable tunnel. The issue is fixed in Netty 4.2.18.Final.

Netty library (netty-codec-http3) versions 4.2.2.Final through 4.2.17.Final are affected. Any application or gateway that uses these Netty versions for HTTP/1 to HTTP/3 conversion is at risk.

The high CVSS score reflects the potential for attackers to bypass policy controls and establish unauthorized tunnels. Although no EPSS score is published, the vulnerability can be exploited by anyone who can reach a Netty‑based proxy and send a CONNECT request with an attacker‑controlled Host header that differs from the requested target. A request lacking a Host header will have its CONNECT target dropped, which does not create a usable tunnel. No privileged access or additional conditions are required beyond the ability to issue the request. The issue remains unlisted in KEV, but its severity and the straightforward attack vector warrant prompt remediation.