GitHub Security Advisory: GHSA-v8h7-rr48-vmmv
Package: io.netty:netty-codec-http (MAVEN)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection'), CWE-444: Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling')
Vulnerable versions: <= 4.1.132.Final
Patched in: 4.1.133.Final

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

Details:
### 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 outboun