CVE-2026-42584 is a high severity flaw (CVSS 7.3) in the Netty HTTP client codec. It pairs responses with requests incorrectly when a server sends an interim 1xx reply to pipelined requests, so later responses are read from the wrong offset. 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.
Only code that uses Netty as an HTTP client with HttpClientCodec is concerned, and the trigger described involves pipelined requests.
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 search your own code for HttpClientCodec and for HTTP client libraries built on Netty. Pipelining is uncommon in modern clients, so note whether yours enables it.
What to do now
- Upgrade Netty to 4.2.13.Final on the 4.2 line or 4.1.133.Final on the 4.1 line.
- Where Netty comes in through another library, upgrade that library or add a dependency constraint that pins the fixed Netty version.
- Rebuild and redeploy containers and shaded jars, since updating the manifest alone does not change an already built artifact.
- If you use a vendor product built on Netty, check the vendor advisory or the Red Hat errata for your platform.
- Run a dependency scan afterwards to confirm no older Netty copy is left.
Why it matters
The class is CWE-444, inconsistent interpretation of HTTP messages. The codec keeps a queue of sent requests and takes one off the queue for every response, including interim 1xx responses. The advisory example is a client that pipelines GET then HEAD. If the server sends 103 and then the real replies, the queue pairs the HEAD request with the first final response.
A HEAD response has no body, so the codec skips reading the GET body. Those bytes stay on the connection and the next response is parsed from the wrong place. That can mix up responses between requests. The KEV flag is false.
Quick check
Does it need a malicious server?
The scenario in the record has the server sending an interim 103 response before the final ones, so the client must talk to a server that behaves that way.
Sources
- GitHub security advisory GHSA-57rv-r2g8-2cj3 (listed in the NVD record, not retrieved)
- Gold page for this CVE
Last reviewed: 19 October 2026.
