CVE-2026-59900

What it actually does

In affected Netty versions before 4.1.136.Final and 4.2.16.Final, the HTTP/2-to-HTTP/1.x translation code does not correctly normalize the HTTP/2 `:authority` pseudo-header and a separately supplied `host` header. When both are present in the same HTTP/2 HEADERS frame, Netty maps `:authority` into an HTTP/1.x `Host` header while also preserving the literal `host` header, producing an internal request object with two attacker-controlled Host values. The direct flaw is improper input validation and header deduplication; downstream impact depends on how the application, gateway, framework, cache, or routing layer interprets duplicate Host headers. Possible consequences include host-header confusion, virtual-host routing inconsistencies, cache-key poisoning, incorrect absolute URL generation, bypass of Host-based allowlists, or security-control mismatch between components that select different Host header instances.

Why it matters to the business

The business risk is primarily application logic and routing confusion rather than direct code execution. Internet-facing services built on affected Netty HTTP/2 translation paths may process a request as if it were intended for one domain while another downstream component treats it as a different domain. This can lead to misrouted requests, poisoned caches, incorrect links in user-facing workflows, failed tenant or domain isolation assumptions, and bypasses of controls that rely on trusted Host header handling. The issue is not currently listed in CISA KEV, has low EPSS, and has no reported exploit maturity in the supplied data, so emergency response is typically not warranted; however, public-facing HTTP/2 endpoints and shared gateways should be prioritized because exploitation is unauthenticated and network-reachable.

How an attack unfolds

An attacker identifies a service that accepts HTTP/2 traffic and uses an affected Netty version in a path that translates HTTP/2 requests into HTTP/1.x-style request objects. The attacker opens an HTTP/2 connection and sends a HEADERS frame containing both a `:authority` pseudo-header and a literal `host` header, deliberately assigning different values to each. The affected Netty codec translates `:authority` into `Host` and also copies the literal `host`, causing the application to receive a request with duplicate Host headers. The attacker then observes which component trusts which Host value: for example, an edge component may route or authorize based on the first value while application code, redirects, cache keys, or link generation may use the second. If exploitable behavior is present, the attacker repeats the request to induce cache poisoning, incorrect routing, Host-based validation bypass, or generation of attacker-controlled absolute URLs. The practical impact is highly dependent on downstream Host header handling and whether duplicate Host headers are logged, rejected, normalized, or inconsistently interpreted.

How to fix it

Upgrade Netty to a fixed release: 4.1.136.Final or later on the 4.1.x line, or 4.2.16.Final or later on the 4.2.x line. Because Netty is commonly pulled in transitively by application frameworks and gateway products, review dependency trees and container images rather than only direct application dependencies. Where immediate upgrade is not possible, add compensating controls at the earliest HTTP/2 termination point: reject requests that contain both `:authority` and `host`; reject duplicate Host headers after translation; normalize to a single canonical Host value; and enforce a strict allowlist of expected hostnames. Avoid relying on downstream application code to resolve duplicate Host headers consistently. If using reverse proxies, load balancers, API gateways, or service meshes in front of Netty-based services, configure them to reject ambiguous Host/authority combinations before traffic reaches the application.

How to confirm the fix worked

Confirm that all deployed artifacts resolve Netty to 4.1.136.Final or later, or 4.2.16.Final or later, including transitive dependencies. For Java builds, inspect Maven or Gradle dependency output and software composition analysis results for `io.netty` modules. Validate runtime images and packaged applications, not only source repositories. Functionally test an HTTP/2 request containing both `:authority` and a literal `host` header with different values; a remediated or mitigated service should reject the request, normalize it to one unambiguous Host value, or otherwise prevent duplicate Host headers from reaching application logic. Review access logs, application debug logs, and gateway logs to ensure Host/authority values are captured well enough to detect ambiguous requests.

Typical attack path

1. Identify an HTTP/2-enabled service or gateway using vulnerable Netty versions before 4.1.136.Final or 4.2.16.Final.
2. Establish an HTTP/2 connection to the target endpoint.
3. Send a HEADERS frame containing both `:authority` and literal `host` headers with different domain values.
4. Cause Netty's HTTP/2-to-HTTP/1.x translator to create an internal request containing duplicate Host headers.
5. Test how downstream routing, authorization, cache, redirect, and application components choose between the duplicate Host values.
6. Exploit any inconsistency to poison cache entries, bypass Host allowlists, misroute requests, or influence generated absolute URLs.

How to detect it

Historical exploitation is difficult to confirm because many access logs record only the final normalized Host value and do not preserve HTTP/2 pseudo-headers. Focus on logs from components that terminate or inspect HTTP/2 traffic, including load balancers, reverse proxies, API gateways, WAFs, service meshes, packet captures, and Netty/application debug logs. Look for HTTP/2 requests where both `:authority` and `host` are present, especially when their values differ. In application logs, investigate duplicate Host header warnings, rejected ambiguous requests, unexpected virtual-host routing, cache entries keyed to unusual hostnames, redirects or password-reset links generated with unexpected domains, and mismatches between SNI, `:authority`, Host, and routed backend. If packet capture is available, decode HTTP/2 HEADERS frames and search for simultaneous `:authority` and `host` fields. Treat isolated malformed requests as probing; repeated requests across many paths or domains may indicate active testing for cache poisoning or Host-header confusion.

• HTTP/2 HEADERS frame containing both `:authority` and `host`
• `:authority` and `host` values differ in the same request
• duplicate Host header
• Duplicate Host header
• multiple Host headers
• Multiple Host headers
• more than one Host header
• Both :authority and host header present
• ambiguous Host header
• Http2StreamFrameToHttpObjectCodec
• InboundHttp2ToHttpAdapter

What your security team should do

• Inventory public-facing and internal HTTP/2 services that use Netty directly or through frameworks, gateways, or reactive application stacks.
• Prioritize upgrades for internet-exposed HTTP/2 endpoints, shared API gateways, authentication-adjacent services, and applications that use Host headers for routing, tenant selection, redirects, link generation, or cache keys.
• Upgrade affected deployments to Netty 4.1.136.Final, 4.2.16.Final, or later fixed releases.
• Add edge-layer rules to reject HTTP/2 requests containing both `:authority` and literal `host` where feasible.
• Search dependency manifests, lockfiles, SBOMs, and container images for vulnerable Netty versions, including transitive dependencies.
• Review cache, proxy, and application behavior for duplicate Host header handling and ensure a single canonical Host value is used consistently.
• Because there is no KEV listing, no supplied ransomware association, low EPSS, and no known exploit maturity, treat this as prioritized hardening rather than confirmed active exploitation unless local telemetry indicates probing.