CVE-2026-42585: Netty Request Smuggling Vulnerability

CVE-2026-42585 Overview

CVE-2026-42585 is an HTTP Request Smuggling vulnerability in Netty, an asynchronous, event-driven network application framework widely used in Java-based servers, proxies, and microservices. The flaw stems from incorrect parsing of malformed Transfer-Encoding headers, allowing attackers to desynchronize front-end and back-end HTTP processing. The vulnerability affects Netty versions prior to 4.2.13.Final and 4.1.133.Final and is classified under CWE-444 (Inconsistent Interpretation of HTTP Requests).

Critical Impact

Attackers can smuggle HTTP requests through intermediaries, bypass security controls, poison caches, and hijack user sessions on applications that rely on Netty for HTTP request parsing.

Affected Products

• Netty versions prior to 4.2.13.Final
• Netty versions prior to 4.1.133.Final
• Applications and frameworks that embed vulnerable Netty HTTP codecs

Discovery Timeline

• 2026-05-13 - CVE-2026-42585 published to NVD
• 2026-05-13 - Last updated in NVD database

Technical Details for CVE-2026-42585

Vulnerability Analysis

Netty's HTTP codec incorrectly parses malformed Transfer-Encoding headers in inbound HTTP requests. When a front-end proxy and the Netty-based back-end interpret the same request differently, an attacker can append a hidden second request to a benign one. The back-end treats the smuggled bytes as a new request, while the proxy treats them as part of the original message body.

Request smuggling enables session hijacking, cache poisoning, security control bypass, and unauthorized access to internal endpoints. Because Netty often runs in reverse proxies, API gateways, and microservice meshes, exploitation can affect entire service chains rather than a single endpoint.

The vulnerability requires no authentication or user interaction and is exploitable remotely over the network against any HTTP listener built on the vulnerable codec.

Root Cause

The root cause is lenient handling of malformed Transfer-Encoding header values. RFC 7230 requires strict rejection of ambiguous chunked encoding declarations, but the vulnerable Netty versions accept variants that differ from how upstream proxies interpret them. This interpretation gap is the foundation of all HTTP Request Smuggling attacks classified under [CWE-444].

Attack Vector

An attacker crafts a single HTTP request containing both Content-Length and a malformed Transfer-Encoding header, or a Transfer-Encoding header with obfuscated whitespace, casing, or duplicate values. The front-end accepts one interpretation while Netty applies another, causing the boundary between requests to shift. The smuggled portion is then processed as a fresh request, potentially executing in the security context of subsequent legitimate users.

Refer to the GitHub Security Advisory GHSA-38f8-5428-x5cv for technical specifics on the malformed header variants.

Detection Methods for CVE-2026-42585

Indicators of Compromise

• HTTP requests containing both Content-Length and Transfer-Encoding headers in the same message
• Transfer-Encoding headers with non-standard whitespace, tabs, or unusual casing such as Transfer-Encoding : chunked
• Unexpected requests in back-end logs that lack a corresponding entry in front-end proxy logs
• Anomalous response-to-request correlation, such as responses returned to the wrong client connection

Detection Strategies

• Compare front-end proxy access logs against Netty back-end logs to identify request count or boundary mismatches
• Inspect raw HTTP traffic for duplicate framing headers and malformed Transfer-Encoding values
• Deploy web application firewall rules that reject ambiguous framing per RFC 7230 §3.3.3
• Enumerate deployed Java applications and identify embedded Netty versions through dependency scans

Monitoring Recommendations

• Alert on HTTP requests that include both Transfer-Encoding and Content-Length headers
• Monitor for sudden spikes in 400-class responses from Netty-based services, which can indicate smuggling probes
• Track outbound responses to internal administrative endpoints that should not be externally reachable

How to Mitigate CVE-2026-42585

Immediate Actions Required

• Upgrade Netty to 4.2.13.Final or 4.1.133.Final across all services and transitive dependencies
• Audit application dependency trees using mvn dependency:tree or gradle dependencies to locate shaded or relocated Netty copies
• Restart all services after upgrading to ensure the patched codec is loaded into running JVMs

Patch Information

Netty maintainers released fixes in versions 4.2.13.Final and 4.1.133.Final. The patches enforce strict parsing of Transfer-Encoding headers and reject malformed values consistent with RFC 7230. Patch details are documented in the Netty GitHub Security Advisory GHSA-38f8-5428-x5cv.

Workarounds

• Place a strict HTTP-compliant reverse proxy in front of Netty services that rejects requests with both Content-Length and Transfer-Encoding
• Disable HTTP keep-alive on affected listeners to limit the scope of smuggling, accepting the performance trade-off
• Configure web application firewalls to drop requests containing obfuscated Transfer-Encoding header variants

# Example WAF rule pattern to block ambiguous framing
# ModSecurity rule blocking requests with both framing headers
SecRule REQUEST_HEADERS:Transfer-Encoding "@rx ." \
    "id:1042585,phase:1,deny,status:400,\
    chain,msg:'CVE-2026-42585 - Ambiguous HTTP framing'"
    SecRule REQUEST_HEADERS:Content-Length "@rx ."