Summary
A request-target parsing flaw in Netty's HTTP/3 codec can mishandle HTTP/1 CONNECT authority-form requests during HTTP/1-to-HTTP/3 conversion. In affected proxy or gateway deployments, a remote client may cause the forwarded tunnel authority to differ from the authority validated in the original request, potentially bypassing routing, egress, allow-list, or audit controls.
Affected context
The issue occurs in Netty applications that convert HTTP/1 messages to HTTP/3, particularly proxy and gateway components that process CONNECT requests. Risk is higher when policy decisions are made from the HTTP/1 CONNECT request-target but the resulting HTTP/3 tunnel authority is derived from a different header or conversion interpretation.
Exploit preconditions
- Attack surface: An HTTP/1-facing Netty proxy, gateway, or protocol translation service
- Required access: Ability to send HTTP/1 CONNECT requests to the affected service
- Trigger point: Conversion of the CONNECT request by
HttpConversionUtil.toHttp3Headers - Why exploitation is possible: Authority-form request-targets are treated as URIs rather than being handled as CONNECT-specific authority values, allowing the forwarded HTTP/3
:authorityto differ from the value used by earlier policy checks
Why this happens
The underlying bug is improper input validation and protocol-specific parsing. HTTP/1 CONNECT uses an authority-form request-target, but the conversion logic interprets that target through general URI handling and may instead use the HTTP/1 Host header when constructing HTTP/3 pseudo-headers. This inconsistent representation can separate the value inspected by security controls from the authority used for tunnel establishment, mapping to CWE-20: Improper Input Validation.
Potential impact
- Tunnel allow-lists may be bypassed
- Egress restrictions may be weakened
- Traffic may be routed to an unintended backend
- Audit records may not accurately represent the established tunnel authority
- Network segmentation or gateway policy enforcement may be circumvented
General mitigation guidance
Mitigation generally focuses on preserving CONNECT semantics and maintaining a single, consistently validated authority across protocol translation boundaries.
Common defensive patterns include:
- Treating CONNECT authority-form request-targets as a dedicated protocol case rather than generic URIs
- Validating that the request-target,
Host, and generated HTTP/3:authorityare consistent before forwarding - Rejecting ambiguous, missing, or conflicting authority representations
- Applying allow-lists and egress policy to the final authority used to establish the tunnel
- Keeping protocol translation components on supported secure dependency baselines
- Running gateway processes with only the network privileges they require
How teams detect issues like this
Organizations can look for this issue through:
- Static analysis and dependency review focused on HTTP/1-to-HTTP/3 conversion paths
- Code review checks for generic URI parsing of protocol-specific CONNECT targets
- Tests that compare policy decisions with the final HTTP/3 pseudo-headers
- Integration tests covering conflicting CONNECT request-target and
Hostvalues - Gateway telemetry that records the validated authority and the authority used for tunnel establishment
- Policy enforcement that rejects mismatched authority fields before protocol conversion
