CVE-2026-59900 in Netty
Summary
by MITRE • 07/29/2026
Netty is an asynchronous, event-driven network application framework. Prior to versions 4.1.136.Final and 4.2.16.Final, Netty's HTTP/2-to-HTTP/1.x translation layer (`Http2StreamFrameToHttpObjectCodec` and `InboundHttp2ToHttpAdapter`) fails to deduplicate or validate `Host` headers when an HTTP/2 client supplies both the `:authority` pseudo-header and a literal `host` header in a single HEADERS frame. The translator maps `:authority` to `Host` and separately copies the literal `host` header, producing an `HttpRequest` object containing two `Host` headers with attacker-controlled differing values. This issue has been fixed in versions 4.1.136.Final and 4.2.16.Final.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 07/29/2026
The vulnerability described affects Netty's HTTP/2 to HTTP/1.x translation layer, specifically within the `Http2StreamFrameToHttpObjectCodec` and `InboundHttp2ToHttpAdapter` components that handle protocol conversion between HTTP/2 and HTTP/1.x. This flaw represents a critical security issue in network application frameworks that process HTTP/2 traffic and translate it to HTTP/1.x for downstream processing. The vulnerability stems from inadequate header validation and deduplication mechanisms within the translation layer, creating a scenario where attacker-controlled values can be injected into HTTP requests through malformed header combinations.
The technical implementation flaw occurs when an HTTP/2 client sends both the `:authority` pseudo-header and a literal `host` header within the same HEADERS frame. The Netty framework's translation logic processes these headers by mapping the `:authority` pseudo-header to a `Host` header in the resulting HTTP/1.x request while simultaneously copying the literal `host` header as a separate `Host` header field. This results in an HTTP request object containing two `Host` headers with potentially different values controlled by the attacker, bypassing normal header validation mechanisms that would typically prevent such duplication.
This vulnerability creates significant operational impact across various network applications and services that rely on Netty for HTTP/2 handling. The presence of duplicate `Host` headers can cause downstream processing systems to behave unpredictably or incorrectly interpret the request, potentially leading to security misconfigurations, access control bypasses, or application logic errors. Many web servers and reverse proxies parse HTTP headers differently when duplicate fields exist, with some systems selecting the first header value while others might use the last value or combine them in unexpected ways.
From a cybersecurity perspective, this vulnerability aligns with CWE-1004 which addresses insecure default configurations and CWE-776 which covers improper handling of duplicate headers. The issue also relates to ATT&CK technique T1071.004 for application layer protocol manipulation and T1566 for credential access through network manipulation. The vulnerability represents a classic case of improper input validation in protocol translation layers, where the framework fails to properly sanitize or consolidate header values during the conversion process.
The fix implemented in versions 4.1.136.Final and 4.2.16.Final addresses this by ensuring that duplicate `Host` headers are properly handled during HTTP/2 to HTTP/1.x translation, either through deduplication of headers or validation that prevents conflicting values from being introduced into the translated request object. Organizations should prioritize upgrading affected Netty versions as this vulnerability could enable attackers to manipulate HTTP request processing, potentially bypassing security controls or causing unexpected application behavior. System administrators and developers should also review their applications for potential reliance on specific `Host` header behavior, as the fix may alter how duplicate headers are processed in their downstream systems.
The broader implications of this vulnerability extend to any system architecture that relies on HTTP/2 to HTTP/1.x translation layers, particularly in microservices environments where protocol translation is common. Security teams should monitor for potential exploitation attempts through malformed HTTP/2 requests and ensure their monitoring tools can detect unusual patterns in header processing that might indicate attempted exploitation of this or similar vulnerabilities. The issue demonstrates the importance of proper input validation in protocol conversion libraries and highlights the need for comprehensive testing of edge cases involving header manipulation in network application frameworks.