CVE-2026-42581: HTTP/1.0 Request Smuggling in Netty

CVE-2026-42581 is a medium severity request smuggling flaw (CVSS 5.8) in Netty. For HTTP/1.0 requests carrying both Transfer-Encoding chunked and Content-Length, Netty decodes the body as chunked but leaves Content-Length in place. A downstream proxy that trusts that header will disagree on message boundaries. Upgrade to 4.2.13.Final or 4.1.133.Final.

What's affected

The record and the advisory give the same ranges for Netty:

• The 4.2 line: versions up to and including 4.2.12.Final, fixed in 4.2.13.Final.
• The 4.1 line: versions up to and including 4.1.132.Final, fixed in 4.1.133.Final.

Netty sits underneath many Java products, including web servers, clients, gateways and message systems. You may be using it without a direct dependency, through another library. Red Hat has also issued errata for this family of Netty fixes, so Red Hat products may carry their own fixed build numbers.

The risk applies where Netty's HTTP decoder feeds a downstream proxy or handler. A standalone service with no second HTTP parser behind it has less to worry about.

How to check if you're exposed

Find every Netty version on your classpath, including transitive ones.

mvn dependency:tree -Dincludes=io.netty
gradle dependencies | grep netty

For a finished application, list the jars in the deployment (for example netty-codec-http or netty-codec-dns) and read the version from the file name. Check container images as well, since a fat jar can hide a Netty copy.

Compare each result with 4.2.13.Final and 4.1.133.Final. A Safeguard dependency scan reads your manifests and lock files and shows transitive Netty versions.

Then ask a second question about your architecture. Does a Netty HTTP server pass requests on to another component that reads Content-Length? Gateways, reverse proxies and service meshes are the typical cases.

What to do now

1. Upgrade Netty to 4.2.13.Final on the 4.2 line or 4.1.133.Final on the 4.1 line.
2. Where Netty comes in through another library, upgrade that library or add a dependency constraint that pins the fixed Netty version.
3. Rebuild and redeploy containers and shaded jars, since updating the manifest alone does not change an already built artifact.
4. Review any layer behind a Netty HTTP front end that trusts Content-Length over Transfer-Encoding.
5. If you can, reject HTTP/1.0 requests that carry Transfer-Encoding at the edge.
6. Run a dependency scan afterwards to confirm no older Netty copy is left.

Why it matters

The weakness is CWE-444, inconsistent interpretation of HTTP requests, better known as request smuggling. The HTTP rules say that when both headers appear, chunked wins and Content-Length should be dropped. Netty did that for HTTP/1.1 messages but not for HTTP/1.0.

If a proxy and a back end disagree about where one request ends, an attacker can hide a second request inside the first. The CVSS score is moderate because the impact is limited to integrity and depends on the chain behind Netty. The KEV flag is false.

Quick check

Sources

• GitHub security advisory GHSA-xxqh-mfjm-7mv9 (listed in the NVD record, not retrieved)
• Gold page for this CVE

Last reviewed: 19 October 2026.