https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Tue, 06 Oct 2026 19:31:09 +0000 https://db.gcve.eu/vuln/ghsa-v8h7-rr48-vmmv <p><strong>Affected:</strong> Maven: io.netty:netty-codec-http</p> <p>### 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()`.</p> <p>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.</p> <p>In practice, this leads to HTTP request smuggling / desynchronization on the HTTP side and request injection on the RTSP side.</p> <p>### Details The root issue is that URI validation exists only on the constructor path, but not on the public setter path.</p> <p>- `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</p> <p>This creates the following bypass:</p> <p>1. An application creates a `DefaultHttpRequest` or `DefaultFullHttpRequest` with a safe URI 2. Later, attacker-influenced input is passe…</p> <p><strong>Affected:</strong> Maven: io.netty:netty-codec-http</p> <p>### 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()`.</p> <p>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.</p> <p>In practice, this leads to HTTP request smuggling / desynchronization on the HTTP side and request injection on the RTSP side.</p> <p>### Details The root issue is that URI validation exists only on the constructor path, but not on the public setter path.</p> <p>- `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</p> <p>This creates the following bypass:</p> <p>1. An application creates a `DefaultHttpRequest` or `DefaultFullHttpRequest` with a safe URI 2. Later, attacker-influenced input is passe…</p> https://db.gcve.eu/vuln/ghsa-v8h7-rr48-vmmv