CVE-2026-41417

What it actually does

The flaw is an input-validation bypass in Netty request construction. Netty validates request-target values for unsafe characters when a DefaultHttpRequest or DefaultFullHttpRequest is created, but the same validation is not applied when the URI is later modified with setUri(). If untrusted data can reach setUri(), carriage return, line feed, or whitespace characters can be inserted into the HTTP or RTSP request line. HttpRequestEncoder and RtspEncoder then serialize that URI verbatim, allowing an attacker to terminate the current request line and inject additional protocol lines or full requests. In HTTP deployments this can cause request smuggling, request desynchronization between intermediaries and backends, or unintended backend requests. In RTSP deployments it can allow injected RTSP requests. The direct CVSS impact is integrity-focused rather than confidentiality or availability-focused, but downstream effects depend heavily on where Netty is used in a proxy, gateway, client, or service-to-service request path.

Why it matters to the business

Applications, gateways, SDKs, and services that build outbound HTTP or RTSP requests with attacker-influenced URIs may be tricked into sending unintended requests to downstream systems. Business consequences can include bypass of routing or access controls, cache poisoning, fraudulent or unauthorized backend actions, corrupted audit trails, and difficult-to-debug service behavior caused by protocol desynchronization. The current public exploitation signal is low: EPSS is approximately 0.0031 and stable over 30 days, there is no CISA KEV listing, no ransomware association, and no known mature public exploit in the supplied data. Even so, Netty is widely embedded in Java ecosystems, so exposure may be indirect through frameworks, gateways, clients, or vendor products that bundle Netty.

How an attack unfolds

An attacker first identifies an application path where user-controlled input is used to update a Netty DefaultHttpRequest or DefaultFullHttpRequest URI after construction, typically through setUri(). Instead of supplying a normal path or URL, the attacker supplies a value containing CRLF or whitespace sequences that break the request line and append additional HTTP or RTSP protocol content. The application accepts or transforms the input and calls setUri(), bypassing the constructor validation that would normally reject the unsafe characters. When the request is later encoded by HttpRequestEncoder or RtspEncoder, Netty writes the modified URI into the wire protocol without revalidating it. A downstream proxy, origin server, RTSP server, cache, or gateway may then parse the bytes as more than one request or as a malformed/desynchronized request stream. Successful exploitation depends on application-specific data flow and on how downstream components parse the resulting traffic; the vulnerability is most dangerous where Netty is used in proxies, reverse proxies, API gateways, service clients, media-control clients, or request forwarding components.

How to fix it

Upgrade Netty to a fixed release: 4.2.13.Final or later in the 4.2.x line, or 4.1.133.Final or later in the 4.1.x line. Because Netty is often a transitive dependency, review application dependency trees, shaded JARs, vendor-bundled libraries, container images, and framework-managed dependency versions rather than only direct package declarations. If immediate upgrade is not possible, add strict validation before any call to setUri(): reject carriage return, line feed, tabs, spaces, other request-line-breaking characters, and ambiguous encoded forms that may decode to those characters. Prefer constructing requests with already-validated immutable URI values, avoid mutating request URIs from untrusted input, and normalize/decode input before validation so encoded CRLF sequences cannot bypass filters. Where feasible, add downstream protections at proxies and servers to reject malformed request lines, duplicate or unexpected request framing, and requests containing embedded protocol delimiters in the request target.

How to confirm the fix worked

Confirm that all deployed applications and build artifacts resolve Netty to 4.2.13.Final or later, or 4.1.133.Final or later. Use dependency inspection for Maven, Gradle, SBT, Bazel, container SBOMs, and vendor package inventories, and verify runtime classpaths where shaded or fat JARs are used. Review code for DefaultHttpRequest, DefaultFullHttpRequest, setUri(), HttpRequestEncoder, and RtspEncoder usage, especially where URI values come from request parameters, headers, user profiles, callback URLs, redirects, routing metadata, or external service descriptors. As a functional validation, test representative request-building paths with benign inputs containing encoded and decoded CRLF/whitespace characters and confirm they are rejected before Netty encodes the request. Also confirm downstream HTTP/RTSP servers do not receive request lines containing embedded CRLF or multiple requests on a connection from a single logical application action.

Typical attack path

1. Find an application, gateway, or service using vulnerable Netty versions in an HTTP or RTSP request construction path.
2. Identify an input field, URL parameter, header-derived value, path segment, redirect target, callback URL, or upstream destination value that influences a Netty request URI after the request object has already been created.
3. Submit a crafted value containing CRLF, whitespace, or encoded characters that are later decoded into CRLF/whitespace before setUri() is called.
4. Trigger the application workflow that creates a DefaultHttpRequest or DefaultFullHttpRequest, then updates the URI via setUri().
5. Allow Netty HttpRequestEncoder or RtspEncoder to serialize the request with the attacker-controlled URI embedded in the request line.
6. Cause a downstream HTTP or RTSP parser to interpret the injected bytes as an additional request, malformed request, or desynchronized request stream.
7. Abuse the resulting request smuggling or injection condition to reach unintended backend routes, alter request semantics, poison caches, or perform unauthorized actions depending on the deployment.

How to detect it

Look for evidence at multiple layers because exploitation may appear as malformed traffic, request smuggling symptoms, or unexpected backend requests rather than as a Netty exception. Review application logs for workflows that accept user-controlled URLs, paths, callback destinations, redirect targets, or routing metadata followed by downstream 400 errors or unexpected successful backend actions. Review proxy, load balancer, WAF, and origin logs for request targets containing literal or encoded CRLF sequences, multiple HTTP request lines associated with one client request, abnormal request-line parsing errors, or disagreement between front-end and back-end request counts. For RTSP deployments, inspect RTSP server logs for malformed request lines, unexpected command sequences, or multiple RTSP methods arriving in a single client interaction. Network packet captures are useful where available: search for HTTP request lines where the request-target contains CR/LF before the protocol version, or for additional HTTP/RTSP methods immediately following an injected line. Correlate suspicious malformed inbound input with outbound connections from the vulnerable service to determine whether attacker-supplied URI data was propagated to Netty-encoded requests.

• %0d%0a
• %0D%0A
• %0d%0A
• %0D%0a
• \r\nGET
• \r\nPOST
• \r\nPUT
• \r\nDELETE
• \r\nPATCH
• \r\nHEAD
• \r\nOPTIONS
• \r\nRTSP/1.0
• HTTP/1.1\r\nHost:
• HTTP/1.0\r\nHost:
• Invalid character found in method name
• Invalid character found in the request target
• Bad Request: invalid request line
• malformed request line
• 400 Bad Request

What your security team should do

• Inventory Netty usage across direct dependencies, transitive dependencies, shaded libraries, application servers, API gateways, service clients, and container images.
• Prioritize upgrades to Netty 4.2.13.Final or 4.1.133.Final or later for internet-facing gateways, reverse proxies, request-forwarding services, service mesh components, HTTP clients handling untrusted URLs, and RTSP/media-control applications.
• Search source code and dependency usage for setUri() on DefaultHttpRequest or DefaultFullHttpRequest and assess whether any argument can be influenced by untrusted input.
• Add or verify centralized URI validation that rejects CR, LF, tabs, spaces, and encoded equivalents before request objects are mutated or serialized.
• Increase monitoring for malformed request lines, embedded protocol delimiters, unexpected secondary requests, backend 400 spikes, proxy/backend request-count mismatches, and cache anomalies.
• If upgrade timelines are constrained, deploy compensating controls at edge proxies and backend servers to reject request targets containing CRLF, encoded CRLF, or whitespace that could alter request-line parsing.
• Because EPSS is low and the issue is not in KEV, treat this as important hygiene unless the affected Netty path is reachable from untrusted input or is used in a proxy/gateway role; in those cases, raise priority.