CVE-2026-41417
Netty URI Validation Bypass via setUri()
Publication date: 2026-05-06
Last updated on: 2026-05-11
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| netty | netty | to 4.1.133 (exc) |
| netty | netty | From 4.2.0 (inc) to 4.2.13 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-444 | The product acts as an intermediary HTTP agent (such as a proxy or firewall) in the data flow between two entities such as a client and server, but it does not interpret malformed HTTP requests or responses in ways that are consistent with how the messages will be processed by those entities that are at the ultimate destination. |
| CWE-93 | The product uses CRLF (carriage return line feeds) as a special element, e.g. to separate lines or records, but it does not neutralize or incorrectly neutralizes CRLF sequences from inputs. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
This vulnerability exists in Netty where request-line validation can be bypassed if a DefaultHttpRequest or DefaultFullHttpRequest is created first and then its URI is changed later using the setUri() method.
While the constructors reject CRLF and whitespace characters that would break the start-line, the setUri() method does not perform the same validation.
As a result, the HttpRequestEncoder and RtspEncoder write the URI into the request line exactly as provided, allowing an attacker to inject CRLF characters and additional HTTP or RTSP requests.
This can lead to HTTP request smuggling or desynchronization on the HTTP side and request injection on the RTSP side.
The issue is fixed in Netty versions 4.2.13.Final and 4.1.133.Final.
How can this vulnerability impact me? :
This vulnerability can allow an attacker to perform HTTP request smuggling or desynchronization, which can lead to unauthorized request injection.
Such attacks can bypass security controls, manipulate web application behavior, or cause unexpected processing of requests.
On the RTSP side, it can enable injection of additional RTSP requests, potentially disrupting streaming services or allowing unauthorized commands.
What immediate steps should I take to mitigate this vulnerability?
To mitigate this vulnerability, update Netty to versions 4.2.13.Final or 4.1.133.Final where the issue is fixed.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability involves bypassing request-line validation in Netty when the URI is changed via setUri(), enabling CRLF injection and HTTP request smuggling or RTSP request injection.
To detect this vulnerability on your network or system, you should monitor for unusual or malformed HTTP request lines that contain unexpected CRLF characters or additional injected requests.
You can use network traffic inspection tools like tcpdump or Wireshark to capture HTTP traffic and look for suspicious request lines.
- Use tcpdump to capture HTTP traffic on port 80 or 443 (if unencrypted): tcpdump -A -s 0 'tcp port 80'
- Use grep or similar tools to search captured traffic for CRLF sequences or multiple HTTP requests in a single packet.
- If you have access to application logs, check for HTTP request lines containing unexpected whitespace or CRLF characters.
Since the vulnerability is specific to Netty versions before 4.2.13.Final and 4.1.133.Final, verifying the Netty version used in your applications is also important.