Summary
Netty's HTTP/3 codec can derive the HTTP/3 :authority pseudo-header from a conflicting HTTP/1 Host header instead of the authority in an absolute-form request-target. In HTTP/1-to-HTTP/3 gateways or protocol bridges, this may cause authorization, routing, virtual-host, or cache decisions to differ between components.
Affected context
The issue can occur in Netty-based HTTP/1-to-HTTP/3 gateways, proxies, or protocol bridges using the affected HTTP/3 codec and conversion path. Risk is higher when one component evaluates the RFC-defined request-target authority while a downstream HTTP/3 peer uses an authority derived from the conflicting Host header.
Exploit preconditions
- Attack surface: Network-accessible HTTP/1 endpoint connected to an HTTP/3 conversion path
- Required access: Ability to send crafted HTTP/1 requests to the gateway, proxy, or bridge
- Trigger point: Conversion of an HTTP/1 message into HTTP/3 headers
- Why exploitation is possible: The conversion logic may prioritize a non-empty
Hostheader over the authority carried by an absolute-form request-target, allowing security and routing decisions to use inconsistent authorities
Why this happens
The underlying bug is inconsistent authority selection during protocol translation. For an absolute-form HTTP/1 request-target, HTTP/1.1 semantics require the request-target authority to take precedence over the Host header, but the conversion logic can select the non-empty Host value when constructing HTTP/3 :authority.
This maps to CWE-20: Improper Input Validation, because conflicting authority fields are not normalized and validated according to the protocol's precedence rules before being forwarded. The resulting parser and interpretation mismatch can create different security decisions across adjacent components.
Potential impact
- Virtual-host routing may reach an unintended service
- Allow-list or authorization checks may evaluate the wrong authority
- Backend selection may be altered
- Cache keys may be generated for an unintended host
- Redirects, links, or other URL generation may use inconsistent authority data
- Request integrity across protocol boundaries could be weakened
General mitigation guidance
Mitigation generally focuses on enforcing one canonical authority value throughout protocol conversion.
Common defensive patterns include:
- Apply the HTTP/1.1 authority precedence rules before constructing HTTP/3 headers
- Reject or safely handle requests containing conflicting authority sources
- Normalize and validate authority values at the protocol boundary
- Ensure authorization, routing, caching, and URL generation consume the same canonical authority
- Avoid relying on independently parsed host fields across proxy layers
- Apply least-privilege and explicit backend allow-list controls so routing discrepancies have limited effect
How teams detect issues like this
Organizations can detect authority-confusion risks through:
- Static analysis and code review of HTTP/1-to-HTTP/3 conversion routines
- Tests containing conflicting
Hostheaders and absolute-form request-target authorities - Proxy and gateway integration tests that compare authorization, routing, and upstream
:authorityvalues - Runtime logging that records the canonical authority selected at each protocol boundary
- Policy checks requiring rejection or explicit normalization of conflicting authority fields
- Automated security review tools that flag inconsistent parsing and validation of duplicate or semantically equivalent request fields
