CVE-2026-41417: Netty HTTP Request Smuggling Vulnerability

CVE-2026-41417 Overview

CVE-2026-41417 is a request-line validation bypass in Netty, an asynchronous event-driven network application framework for Java. The flaw resides in DefaultHttpRequest and DefaultFullHttpRequest, where constructors reject CRLF and whitespace characters but the setUri() method does not enforce equivalent validation. HttpRequestEncoder and RtspEncoder then write the URI verbatim into the outgoing request line. Attackers who control input passed to setUri() can inject CRLF sequences, smuggle additional HTTP requests, or inject RTSP requests. The issue is fixed in Netty 4.2.13.Final and 4.1.133.Final. The vulnerability is categorized under [CWE-93]: Improper Neutralization of CRLF Sequences.

Critical Impact

Attacker-controlled URIs reaching setUri() enable HTTP request smuggling, desynchronization attacks, and RTSP request injection against downstream servers.

Affected Products

• Netty versions prior to 4.2.13.Final on the 4.2.x branch
• Netty versions prior to 4.1.133.Final on the 4.1.x branch
• Applications using DefaultHttpRequest, DefaultFullHttpRequest, HttpRequestEncoder, or RtspEncoder with mutable URIs

Discovery Timeline

• 2026-05-06 - CVE-2026-41417 published to NVD
• 2026-05-06 - Last updated in NVD database

Technical Details for CVE-2026-41417

Vulnerability Analysis

Netty's HTTP and RTSP request objects validate URI content during construction. The constructors of DefaultHttpRequest and DefaultFullHttpRequest reject characters that would break the start-line, including carriage return (\r), line feed (\n), and embedded whitespace. This validation prevents injection at object creation.

The setUri() method on the same classes omits this check. Code paths that build a request with a benign URI and later mutate it via setUri() can store a malicious value containing CRLF sequences. When the request reaches HttpRequestEncoder or RtspEncoder, the encoder writes the URI directly into the request line without re-validating.

Downstream HTTP intermediaries and origin servers parse the resulting bytes as multiple requests. This produces request smuggling or desynchronization on HTTP and request injection on RTSP. Refer to the Netty GitHub Security Advisory GHSA-v8h7-rr48-vmmv for full technical details.

Root Cause

Validation logic is duplicated inconsistently between the constructor and the mutator. The setter trusts the caller, violating the principle that all state-changing entry points must enforce the same invariants as the constructor.

Attack Vector

An attacker supplies a crafted URI value, typically through proxy logic, URL rewriting middleware, or any application code that forwards user input into setUri(). The injected payload contains \r\n followed by a fabricated request line and headers. The encoder serializes the malicious URI into the wire format, and the receiving parser interprets the smuggled request as legitimate.

The vulnerability is reachable over the network without authentication when an upstream component routes attacker-controlled paths through a vulnerable Netty client or proxy.

Detection Methods for CVE-2026-41417

Indicators of Compromise

• Outbound HTTP or RTSP requests containing embedded \r\n sequences within the request URI field
• Unexpected duplicate Host, Content-Length, or Transfer-Encoding headers in traffic originating from Netty-based services
• Backend access logs showing requests with paths or methods that no upstream client legitimately issued

Detection Strategies

• Inspect application dependencies for vulnerable Netty versions using software composition analysis tools and Maven or Gradle dependency reports
• Deploy a web application firewall or reverse proxy that strictly rejects request lines containing CRLF or whitespace before forwarding
• Audit application source code for calls to HttpRequest.setUri() or FullHttpRequest.setUri() that pass externally sourced strings

Monitoring Recommendations

• Log and alert on HTTP parser errors and protocol-violation events from front-end load balancers, which often signal smuggling attempts
• Correlate request volume between front-end and back-end tiers to identify desynchronization where back-end request counts exceed front-end counts
• Monitor RTSP servers for unexpected method invocations or session state transitions originating from Netty-based clients

How to Mitigate CVE-2026-41417

Immediate Actions Required

• Upgrade Netty to 4.2.13.Final for the 4.2.x branch or 4.1.133.Final for the 4.1.x branch
• Inventory all services and transitive dependencies that pull in io.netty:netty-codec-http or io.netty:netty-codec-rtsp
• Review and sanitize any application code path that passes external input into setUri() on Netty request objects

Patch Information

The fix extends the constructor validation logic to the setUri() method, rejecting CRLF and whitespace characters consistently across both code paths. Apply the patched releases through your build system. The Netty Security Advisory GHSA-v8h7-rr48-vmmv documents the corrected behavior.

Workarounds

• Validate and reject CRLF (\r, \n), space, and tab characters in URI strings before passing them to setUri()
• Construct new DefaultHttpRequest or DefaultFullHttpRequest instances rather than mutating existing requests when handling untrusted URI values
• Place a strict HTTP parser between Netty-based components and untrusted clients to drop malformed request lines at the perimeter

# Maven dependency update example
mvn versions:set-property -Dproperty=netty.version -DnewVersion=4.1.133.Final
mvn dependency:tree | grep netty