Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-09-26T14:16:48.830Z",
  "pubdate": "2026-09-26T14:16:48.830Z",
  "executiveSummary": "The vulnerability in io.netty:netty-codec-http3 constitutes an HTTP request smuggling and request header inconsistency flaw. It stems from the failure to enforce RFC 9114 requirements regarding the synchronization of :authority pseudo-header fields and literal host header fields.\nThe flaw allows remote, unauthenticated attackers to supply conflicting values for these fields within a single HEADERS frame. By inducing a state where different application components interpret conflicting authorities, an attacker can bypass critical security boundaries, including virtual-host routing, request filtering, and access control policies.\nThe vulnerability affects Netty versions 4.2.0.Final through 4.2.17.Final. Successful exploitation permits an attacker to perform request smuggling, potentially escalating to unauthorized resource access or security policy evasion. The risk is considered high, as it requires no prior authentication and can be triggered via standard HTTP/3 traffic directed at the vulnerable codec.",
  "technicalDetails": "The root cause of this vulnerability is a non-compliance with RFC 9114 in the io.netty:netty-codec-http3 component. RFC 9114 mandates that for HTTP/3 requests, the :authority pseudo-header and the host header field must contain identical values if both are present in the HEADERS frame. The affected Netty versions fail to validate the consistency between these two fields, allowing the codec to pass both to the downstream application layer despite the inherent conflict.\nThe exploitation flow begins when an unauthenticated remote attacker constructs a malicious HTTP/3 HEADERS frame. In this frame, the attacker embeds both an :authority pseudo-header and a literal host header, each assigned a different, attacker-controlled value. Because the codec performs no verification to ensure these values match, it processes the request and injects both conflicting headers into the internal request object, which is then passed to the application.\nThis creates an ambiguity that downstream components—such as load balancers, reverse proxies, Web Application Firewalls (WAFs), or specific application logic—are forced to resolve. If these components have disparate logic for selecting which header takes precedence (e.g., one component trusts the :authority pseudo-header while another relies on the host header), an attacker can achieve de-synchronization. This inconsistency can be leveraged to bypass virtual-host isolation, circumvent access control list (ACL) checks, or perform server-side request smuggling.\nThe payload behavior involves the successful delivery of a request that contains conflicting origin information. When the internal application components process this request, the discrepancy leads to inconsistent routing decisions. For example, an attacker could route a request to a private virtual host that would otherwise be inaccessible, or trick a security filter into applying a policy meant for a different domain. The impact is significant as it undermines the integrity of request-based security controls within the request processing pipeline. The vulnerability is present in versions 4.2.0.Final through 4.2.17.Final of the Netty HTTP/3 codec, and it remains exploitable as long as the application relies on the underlying codec to validate HTTP/3 header compliance without implementing secondary, application-level checks."
}