CVE-2026-100663: Netty HTTP/1 CONNECT authority-form mistranslated to malformed HTTP/3
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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
io.netty:netty-codec-http3to a version that resolves this vulnerability.Fixed in 4.2.18.Final
Event History
Frequently Asked Questions
Which deployments are exposed to exploitation?
Exposure is limited to Netty-based HTTP/1-to-HTTP/3 proxies or gateways that use netty-codec-http3 versions 4.2.2.Final through 4.2.17.Final and forward client CONNECT requests. The practical risk is greatest where controls validate the HTTP/1 CONNECT request-target but rely on the converted HTTP/3 request for tunneling or routing.
What does an attacker need to do?
A remote, unauthenticated client needs to be able to send an HTTP/1 CONNECT request through the affected conversion path. They can provide a Host header naming a different authority from the CONNECT authority-form request-target, causing the Host value to become the HTTP/3 :authority used for the tunnel.
Are default configurations affected?
The issue requires an HTTP/1-to-HTTP/3 conversion path for CONNECT requests; the data does not establish that every Netty deployment or default configuration provides such a path. Deployments that do not proxy or gateway HTTP/1 CONNECT traffic into HTTP/3 are not described as exposed.
What can be done before upgrading?
Do not forward HTTP/1 CONNECT requests through the affected HTTP/1-to-HTTP/3 conversion path, or reject requests where the Host header differs from the CONNECT authority-form target. Ensure tunnel authorization, egress policy, backend selection, and auditing validate the authority ultimately used for forwarding rather than only the original request-target.
How can operators determine whether they are affected?
Check whether netty-codec-http3 is present at versions 4.2.2.Final through 4.2.17.Final and whether the application converts HTTP/1 CONNECT messages to HTTP/3 using HttpConversionUtil.toHttp3Headers. Review whether CONNECT handling accepts a Host header that can differ from the authority-form target and whether downstream controls use the resulting HTTP/3 :authority.