CVE-2026-42581: Netty HTTP Request Smuggling Vulnerability

CVE-2026-42581 Overview

CVE-2026-42581 is an HTTP Request Smuggling vulnerability [CWE-444] in Netty, an asynchronous, event-driven network application framework widely used in Java-based services. The flaw affects Netty versions prior to 4.2.13.Final and 4.1.133.Final. The HttpObjectDecoder strips a conflicting Content-Length header when an HTTP/1.1 request includes both Transfer-Encoding: chunked and Content-Length, but this guard is absent for HTTP/1.0 requests. Attackers exploit this inconsistency to desynchronize message boundaries between Netty and downstream proxies or handlers.

Critical Impact

An unauthenticated remote attacker can smuggle HTTP requests through HTTP/1.0 messages carrying both Transfer-Encoding: chunked and Content-Length headers, bypassing security controls at intermediary proxies.

Affected Products

• Netty versions prior to 4.2.13.Final
• Netty versions prior to 4.1.133.Final
• Applications and proxies built on vulnerable Netty releases

Discovery Timeline

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

Technical Details for CVE-2026-42581

Vulnerability Analysis

Netty's HttpObjectDecoder parses incoming HTTP messages and normalizes ambiguous framing headers. For HTTP/1.1 traffic, the decoder removes a Content-Length header when Transfer-Encoding: chunked is also present, aligning with RFC 7230 guidance. This sanitization step is missing for HTTP/1.0 messages. The decoder still processes the body as chunked while passing the original Content-Length header forward in the HttpMessage object.

Downstream components that prefer Content-Length over Transfer-Encoding interpret the message body differently than Netty. The disagreement on message boundaries enables HTTP Request Smuggling, allowing an attacker to inject a second request that the downstream parser treats as independent traffic.

Root Cause

The root cause is an incomplete input validation routine in HttpObjectDecoder. The conflict-resolution logic that strips Content-Length when both framing headers are present is gated on the HTTP/1.1 version check. HTTP/1.0 messages bypass this branch, leaving the conflicting header pair intact in the parsed message forwarded to handlers and proxies.

Attack Vector

An attacker sends an HTTP/1.0 request to a Netty-backed endpoint or proxy with both Transfer-Encoding: chunked and Content-Length headers set to incompatible values. Netty decodes the body using chunked semantics, while a downstream proxy or backend trusting Content-Length reads a different byte range as the body. The remaining bytes are interpreted as a new, smuggled request. Attackers leverage this primitive to bypass access controls, poison web caches, or hijack adjacent sessions.

No verified public exploit code is available. See the Netty GitHub Security Advisory for technical details.

Detection Methods for CVE-2026-42581

Indicators of Compromise

• HTTP/1.0 requests containing both Transfer-Encoding: chunked and Content-Length headers in the same message
• Unexpected secondary requests appearing in backend logs without corresponding front-end proxy log entries
• Mismatched byte counts between proxy access logs and Netty application logs for the same connection

Detection Strategies

• Inspect HTTP traffic at WAF or reverse proxy layers for HTTP/1.0 messages that include both framing headers and reject or normalize them before they reach Netty.
• Correlate request counts and body sizes across front-end load balancers and Netty backends to surface desynchronization events.
• Run dependency scans across Java codebases and container images to identify Netty versions below 4.2.13.Final and 4.1.133.Final.

Monitoring Recommendations

• Enable verbose HTTP framing logs on Netty pipelines and forward them to a centralized analytics platform for anomaly review.
• Alert on any HTTP/1.0 traffic in production environments where only HTTP/1.1 or HTTP/2 is expected.
• Track outbound responses that do not map to a logged inbound request as a smuggling indicator.

How to Mitigate CVE-2026-42581

Immediate Actions Required

• Upgrade Netty to 4.2.13.Final or 4.1.133.Final across all services, libraries, and container images.
• Audit the dependency tree for transitive Netty inclusions in frameworks such as Spring WebFlux, Vert.x, gRPC-Java, and Apache Cassandra clients.
• Configure upstream proxies to reject HTTP/1.0 requests that carry both Transfer-Encoding and Content-Length headers.

Patch Information

The Netty maintainers fixed this vulnerability in versions 4.2.13.Final and 4.1.133.Final. The patch extends the conflicting-header sanitization logic in HttpObjectDecoder to cover HTTP/1.0 messages, ensuring that Content-Length is stripped whenever Transfer-Encoding: chunked is also present. Patch details are published in the Netty GitHub Security Advisory GHSA-xxqh-mfjm-7mv9.

Workarounds

• Disable HTTP/1.0 support at front-end load balancers or API gateways when application requirements allow.
• Deploy a WAF rule that drops requests containing both Transfer-Encoding: chunked and Content-Length headers regardless of HTTP version.
• Terminate HTTP at a hardened reverse proxy that normalizes framing headers before forwarding traffic to Netty backends.

# Example WAF rule snippet to block conflicting framing headers
SecRule REQUEST_HEADERS:Transfer-Encoding "@contains chunked" \
  "id:1042581,phase:1,deny,status:400,\
   chain,msg:'Block HTTP smuggling: conflicting framing headers'"
  SecRule REQUEST_HEADERS:Content-Length "@rx ^[0-9]+$"