CVE-2026-100664: Netty HTTP/3 Codec Authority Confusion

CVE-2026-100664 Overview

CVE-2026-100664 is an authority confusion vulnerability in Netty's HTTP/3 codec (io.netty:netty-codec-http3). Affected versions 4.2.2.Final through 4.2.17.Final incorrectly prioritize the HTTP/1 Host header over the authority component of an absolute-form HTTP/1 request-target when constructing the HTTP/3 :authority pseudo-header. This conflicts with RFC 9112, which requires servers receiving an absolute-form request-target to ignore the Host header. In Netty-based HTTP/1-to-HTTP/3 gateways, proxies, or protocol bridges, this discrepancy enables request routing and authorization bypass. The issue is tracked under [CWE-20] Improper Input Validation.

Critical Impact
Remote attackers can desynchronize authority decisions between validation layers and upstream HTTP/3 peers, bypassing virtual-host routing, allow-list enforcement, and backend selection without authentication.

Affected Products

Netty netty-codec-http3 version 4.2.2.Final
Netty netty-codec-http3 versions through 4.2.17.Final
HTTP/1-to-HTTP/3 gateways, proxies, and protocol bridges built on affected Netty releases

Discovery Timeline

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

Technical Details for CVE-2026-100664

Vulnerability Analysis

The flaw resides in HttpConversionUtil.toHttp3Headers(HttpMessage, boolean), reached via Http3FrameToHttpObjectCodec(false). When Netty converts an inbound HTTP/1 request into HTTP/3 frames, it derives the :authority pseudo-header from the Host header whenever that header is non-empty. The HTTP/1.1 specification requires the opposite behavior: when a request-target uses absolute form such as GET https://trusted.example/admin HTTP/1.1, the server must ignore the Host header and use the authority embedded in the request-target.

The advisory reports integrity impact only. There is no reported code execution, memory corruption, or availability impact. However, the authority mismatch is sufficient to break trust boundaries that depend on consistent host identity across proxy hops.

Root Cause

The conversion routine evaluates the Host header first and treats a non-empty value as authoritative. It never checks whether the request-line contains an absolute-form URI whose authority should take precedence. This ordering inverts the RFC-defined precedence rule and produces an HTTP/3 :authority value that disagrees with the HTTP/1 request-target.

Attack Vector

A remote unauthenticated client sends an HTTP/1.1 request with mismatched authorities, for example a request-line of GET https://trusted.example/admin HTTP/1.1 paired with Host: attacker.example. Middleware that validates, authorizes, or routes on the RFC-defined request-target authority sees trusted.example. The upstream HTTP/3 peer receives :authority: attacker.example. The two components reach different decisions on the same request. Attackers can abuse this split to bypass virtual-host allow-lists, poison cache keys, redirect backend selection, or manipulate URL generation that reflects the authority.

No verified public exploit is available. See the GitHub Security Advisory GHSA-hfr2-x62w-v49h and the VulnCheck Advisory for Netty for the full technical write-up.

Detection Methods for CVE-2026-100664

Indicators of Compromise

HTTP/1 requests arriving at a Netty-based gateway where the request-line uses absolute-form URI and the Host header specifies a different authority.
Access logs showing successful requests to restricted virtual hosts that should have been rejected by allow-list policy.
Divergence between front-tier proxy logs and backend HTTP/3 server logs for the same request identifier, specifically on the authority field.

Detection Strategies

Inventory applications for io.netty:netty-codec-http3 versions 4.2.2.Final through 4.2.17.Final using software composition analysis.
Add gateway inspection rules that flag inbound HTTP/1 requests containing both an absolute-form request-target and a Host header whose value differs from the request-target authority.
Correlate request authority between ingress and egress logs to surface Host-versus-request-target mismatches.

Monitoring Recommendations

Enable verbose HTTP request logging at the Netty bridge, capturing both the raw request-line and the Host header for post-hoc analysis.
Alert on unexpected cache key collisions or 2xx responses to hostnames outside configured virtual-host allow-lists.
Monitor dependency manifests (pom.xml, build.gradle) in CI pipelines for vulnerable Netty versions.

How to Mitigate CVE-2026-100664

Immediate Actions Required

Upgrade io.netty:netty-codec-http3 to version 4.2.18.Final or later across all services that bridge HTTP/1 to HTTP/3.
Audit all deployments acting as HTTP/1-to-HTTP/3 gateways, proxies, or protocol bridges for exposure.
Review authorization and virtual-host routing logs for prior requests exhibiting Host-versus-request-target mismatches.

Patch Information

The vulnerability is fixed in Netty 4.2.18.Final. Update the dependency in Maven, Gradle, or SBT build definitions and redeploy affected services. Refer to the GitHub Security Advisory GHSA-hfr2-x62w-v49h for the authoritative patch reference.

Workarounds

Deploy a reverse proxy in front of the Netty bridge that normalizes requests by rewriting the Host header to match the authority of any absolute-form request-target before forwarding.
Reject inbound HTTP/1 requests that contain an absolute-form request-target when the authority disagrees with the Host header.
Disable HTTP/1-to-HTTP/3 bridging functionality until the upgrade to 4.2.18.Final can be deployed.

bash

# Maven dependency update
# Replace vulnerable Netty HTTP/3 codec with the fixed release
mvn versions:use-dep-version \
  -Dincludes=io.netty:netty-codec-http3 \
  -DdepVersion=4.2.18.Final \
  -DforceVersion=true