CVE-2026-100659: Netty 4.2.0 through 4.2.18 HTTP/3 Request Routing Bypass
Netty's HTTP/3 codec (io.netty:netty-codec-http3) in versions 4.2.0.Final through 4.2.17.Final does not enforce the RFC 9114 requirement that the :authority pseudo-header field and a literal host header field, when both present, carry the same value. A remote unauthenticated peer can send a single HEADERS frame containing both fields with differing, attacker-controlled values; the request is accepted and delivered to the application with two conflicting authorities, allowing routing, virtual-host, and access-control decisions to be bypassed when different components in the request path consult different fields. This 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 at practical risk?
Deployments using Netty's HTTP/3 codec are at risk when different components along the request path make routing, virtual-host, or access-control decisions using different authority values. The bypass depends on those components interpreting the :authority pseudo-header and host header differently.
Does exploitation require authentication or user interaction?
No. A remote unauthenticated peer can exploit the issue by sending a single HTTP/3 HEADERS frame containing both fields with differing attacker-controlled values.
What version resolves the issue?
The issue is fixed in netty-codec-http3 version 4.2.18.Final. The affected range described is 4.2.0.Final through 4.2.17.Final.
How can teams look for attempted exploitation?
Inspect HTTP/3 requests for cases where both the :authority pseudo-header and literal host header are present but have different values. Such requests are the condition described as being accepted and passed to the application by affected versions.