CVE-2026-100663: Netty HTTP/3 Codec Auth Bypass Vulnerability

CVE-2026-100663 Overview

CVE-2026-100663 is an input validation flaw [CWE-20] in Netty's HTTP/3 codec (io.netty:netty-codec-http3), affecting versions 4.2.2.Final through 4.2.17.Final. The vulnerability resides in HttpConversionUtil.toHttp3Headers, which fails to special-case HTTP/1 CONNECT authority-form request-targets when translating HTTP/1 messages into HTTP/3. In Netty-based HTTP/1-to-HTTP/3 proxies or gateways, a remote client can craft a CONNECT request where the Host header differs from the authority in the request-target. The resulting malformed HTTP/3 CONNECT carries an attacker-controlled :authority, enabling bypass of tunnel allow-lists, egress policy, and audit controls.

Critical Impact
Remote unauthenticated attackers can bypass CONNECT allow-lists and egress controls in Netty-based HTTP/1-to-HTTP/3 proxies, redirecting tunnels to arbitrary attacker-chosen backends.

Affected Products

Netty HTTP/3 codec (io.netty:netty-codec-http3) 4.2.2.Final
Netty HTTP/3 codec versions through 4.2.17.Final
Applications using Netty as an HTTP/1-to-HTTP/3 proxy or gateway

Discovery Timeline

2026-09-26 - CVE-2026-100663 published to NVD
2026-09-28 - Last updated in NVD database

Technical Details for CVE-2026-100663

Vulnerability Analysis

The flaw lives in HttpConversionUtil.toHttp3Headers, Netty's helper that maps HTTP/1 request lines and headers into HTTP/3 pseudo-headers. HTTP/1 CONNECT uses an authority-form request-target such as CONNECT trusted.example:443 HTTP/1.1, which carries only the authority — no scheme, no path. Netty parses this target as a generic URI instead of handling the CONNECT case explicitly.

As a result, the parser emits the authority host as :scheme, hard-codes :path to /, and takes :authority from the HTTP/1 Host header. When no Host header is present, the original CONNECT target is dropped entirely. Downstream HTTP/3 peers then see a tunnel request whose destination is governed by the client-supplied Host header rather than the vetted request-target.

Root Cause

The translation routine does not distinguish CONNECT requests from other methods. HTTP/1 CONNECT request-targets must map directly to the HTTP/3 :authority pseudo-header per RFC 9114. By routing the target through generic URI parsing and sourcing :authority from Host, Netty violates this requirement and introduces a classic input validation defect [CWE-20].

Attack Vector

An unauthenticated remote client sends an HTTP/1 CONNECT to a Netty-fronted proxy. The request-target names an allowed destination such as trusted.example:443, satisfying any upstream allow-list check performed on the HTTP/1 request line. The Host header, however, names an attacker-chosen destination such as attacker.example:443.

After translation, the HTTP/3 CONNECT forwarded to the backend carries :authority: attacker.example:443. Tunnel enforcement, egress filtering, backend routing, and audit logging that trusted the HTTP/1 request-target are now bypassed, and the tunnel terminates at the attacker-chosen authority.

The vulnerability is described in prose only; see the GitHub Security Advisory GHSA-jgph-cgq3-c627 and the Vulncheck Advisory for additional technical context.

Detection Methods for CVE-2026-100663

Indicators of Compromise

HTTP/1 CONNECT requests where the Host header authority does not match the authority in the request-target.
HTTP/3 CONNECT frames where :scheme contains a hostname and :path is /, indicating malformed translation.
Outbound tunnel sessions to destinations absent from configured allow-lists or egress policy.
Proxy audit records that log an allowed CONNECT target but establish a tunnel to a different authority.

Detection Strategies

Inventory Java services and identify dependencies on io.netty:netty-codec-http3 at versions 4.2.2.Final through 4.2.17.Final.
Instrument HTTP/1-to-HTTP/3 proxy code paths to compare the HTTP/1 request-target authority with the resulting HTTP/3 :authority and alert on mismatch.
Use software composition analysis (SCA) tooling to flag vulnerable Netty versions in build pipelines and artifact registries.

Monitoring Recommendations

Forward proxy and gateway access logs to a central analytics platform and correlate CONNECT request-target, Host header, and tunnel destination fields.
Alert on unexpected outbound connections from proxy hosts to destinations outside the sanctioned egress allow-list.
Monitor dependency manifests (pom.xml, build.gradle) for Netty version downgrades or pinning to affected releases.

How to Mitigate CVE-2026-100663

Immediate Actions Required

Upgrade io.netty:netty-codec-http3 to 4.2.18.Final or later across all affected services.
Audit HTTP/1-to-HTTP/3 proxy deployments for CONNECT tunnel traffic to unauthorized authorities since the vulnerable versions were deployed.
Enforce CONNECT allow-lists at the HTTP/3 layer rather than relying on HTTP/1 request-target validation alone.

Patch Information

The issue is fixed in netty-codec-http34.2.18.Final. The patch introduces explicit handling of the CONNECT method in HttpConversionUtil.toHttp3Headers so the authority-form request-target maps directly to the HTTP/3 :authority pseudo-header. Refer to the GitHub Security Advisory GHSA-jgph-cgq3-c627 for release details.

Workarounds

Reject HTTP/1 CONNECT requests at an upstream reverse proxy where the Host header authority does not match the request-target.
Disable HTTP/1-to-HTTP/3 translation on affected gateways until the upgrade is applied.
Apply strict egress firewall rules so unauthorized tunnel destinations are blocked at the network layer.

bash

# Maven dependency pin to the fixed version
# pom.xml
# <dependency>
#   <groupId>io.netty</groupId>
#   <artifactId>netty-codec-http3</artifactId>
#   <version>4.2.18.Final</version>
# </dependency>

# Gradle dependency pin
# implementation 'io.netty:netty-codec-http3:4.2.18.Final'

# Verify installed version
mvn dependency:tree | grep netty-codec-http3