CVE-2026-42584

What it actually does

In affected Netty versions, HttpClientCodec incorrectly advances its internal request/response pairing queue for informational 1xx responses. When an HTTP client pipelines requests such as GET followed by HEAD, and the server returns a 103 informational response followed by a 200 response with a GET body and then a 200 response for HEAD, Netty can associate the GET response with the HEAD request. Because HEAD responses are expected to have no body, the client skips consuming the actual GET body bytes, leaving them on the TCP stream. Subsequent bytes are then parsed from the wrong offset, causing HTTP response desynchronization. The practical impact is incorrect response attribution, possible data confusion or leakage between logical requests on the same connection, protocol parsing errors, and potential denial of service for clients that rely on affected Netty HTTP client behavior.

Why it matters to the business

Applications that use vulnerable Netty HTTP client components may process the wrong HTTP response for a request when communicating with a malicious, compromised, or attacker-influenced HTTP server. This can cause incorrect business transactions, corrupted downstream data, failed API calls, exposure of response content to the wrong application workflow, or service instability. The vulnerability is network-reachable, unauthenticated, and low complexity, but current public exploit maturity is listed as none, EPSS is low and stable at 0.0075, and it is not listed in CISA KEV or known ransomware use, so remediation should be prioritized for internet-facing clients, proxy/gateway components, webhook fetchers, SSRF-prone features, and services that call untrusted or third-party HTTP endpoints.

How an attack unfolds

An attacker needs to influence the HTTP server response stream received by a vulnerable Netty-based client. This could occur through a malicious external server contacted by the application, a compromised upstream service, a man-in-the-middle position on unprotected traffic, or an application feature that lets users provide URLs for server-side fetching. The attacker causes the client to pipeline a GET request followed by a HEAD request on the same connection, then returns a crafted sequence of HTTP responses: an informational 103 response, a 200 response containing the GET body, and a later 200 response intended for the HEAD request. Due to the queue handling bug, Netty associates the first final 200 response with the HEAD request and does not consume the response body. The leftover body bytes remain in the stream and are interpreted as part of the next response, desynchronizing the client. Depending on how the application uses the returned data, this may lead to incorrect response handling, request/response confusion, protocol exceptions, connection termination, data leakage across application operations, or availability impact.

How to fix it

Upgrade Netty to a fixed release: 4.1.133.Final or later for the 4.1.x line, or 4.2.13.Final or later for the 4.2.x line. Because Netty is frequently pulled in transitively by frameworks, application servers, RPC clients, HTTP clients, messaging clients, and cloud SDKs, review dependency trees and software bills of materials rather than only direct dependencies. If immediate upgrade is not possible, reduce exposure by disabling HTTP/1.1 pipelining where configurable, avoiding connection reuse for untrusted HTTP endpoints, blocking or sanitizing server-side requests to user-supplied URLs, preferring TLS with certificate validation to prevent response manipulation in transit, and applying strict allowlists for outbound HTTP destinations. Treat these mitigations as temporary; the reliable fix is to deploy a corrected Netty version.

How to confirm the fix worked

Confirm that no runtime artifact includes vulnerable Netty versions prior to 4.1.133.Final or 4.2.13.Final. Validate both direct and transitive dependencies using build tooling such as Maven dependency:tree, Gradle dependencies, SCA/SBOM scanners, container image scanners, and runtime classpath inspection. Search packaged applications, fat JARs, shaded JARs, containers, and server plugin directories for netty-codec-http and related Netty artifacts. After upgrading, run integration tests that exercise HTTP client behavior against a test server returning a 103 informational response followed by pipelined GET and HEAD responses, and verify that responses remain correctly associated and response bodies are consumed correctly. Monitor production after rollout for reductions in Netty HTTP decoder errors, malformed response parsing, and unexplained upstream connection resets.

Typical attack path

1. Identify an application or service that uses a vulnerable Netty HTTP client version before 4.1.133.Final or 4.2.13.Final.
2. Find a path where the application connects to an attacker-controlled or attacker-influenced HTTP endpoint, such as a webhook target, metadata fetcher, URL previewer, proxy, integration connector, or third-party API call.
3. Cause the Netty client to reuse a connection and pipeline a GET request followed by a HEAD request.
4. Return a crafted HTTP response sequence containing a 103 informational response, then a 200 response with a body for the GET request, then a 200 response for the HEAD request.
5. Rely on the vulnerable HttpClientCodec behavior to mispair the first final 200 response with the HEAD request.
6. Leave the GET response body unread on the connection so that subsequent parsing begins at the wrong byte offset.
7. Trigger application-level impact such as wrong response processing, parse failures, connection resets, data confusion, or service disruption.

How to detect it

Evidence of exploitation is likely to appear in client-side application logs, Netty codec logs, outbound proxy logs, packet captures, and upstream HTTP access logs rather than endpoint malware artifacts. Review outbound HTTP sessions from Netty-based applications for unusual sequences where a 103 informational response is followed by final 200 responses on a reused HTTP/1.1 connection involving GET and HEAD requests. Pay particular attention to untrusted, user-supplied, newly registered, or partner-controlled destinations. In application logs, look for Netty HTTP decoding failures, malformed HTTP response parsing, unexpected bytes before an HTTP status line, response/request correlation mismatches, unexpected empty HEAD handling, connection resets after 103 responses, or business logic errors where a response body appears associated with the wrong request. If full packet capture or proxy logging is available, inspect whether response bodies were left unread before the next response status line. There are no known public exploit-specific payload strings from the provided intelligence, so detections should focus on protocol patterns and Netty decoder anomalies rather than a single definitive IOC.

• HTTP/1.1 103
• 103 Early Hints
• HTTP/1.1 200
• GET followed by HEAD on the same HTTP/1.1 connection
• io.netty.handler.codec.http.HttpClientCodec
• io.netty.handler.codec.http.HttpObjectDecoder
• io.netty.handler.codec.DecoderException
• io.netty.handler.codec.TooLongFrameException
• invalid version format
• invalid constant type
• malformed HTTP response
• PrematureChannelClosureException
• Connection reset by peer
• HEAD response with unexpected body
• unexpected HTTP content
• response decoding failed

What your security team should do

• Inventory applications and services that include Netty, especially netty-codec-http, netty-all, or frameworks that embed Netty transitively.
• Prioritize remediation for systems that make outbound HTTP requests to internet, partner, customer-supplied, webhook, or otherwise untrusted endpoints.
• Upgrade affected deployments to Netty 4.1.133.Final or later, or 4.2.13.Final or later, and rebuild/redeploy all dependent applications and containers.
• Use SCA and SBOM tooling to detect shaded, repackaged, or transitive Netty copies that may not appear as direct dependencies.
• Temporarily disable HTTP/1.1 pipelining or connection reuse for untrusted destinations where supported until upgrades are complete.
• Restrict server-side outbound HTTP fetch functionality with destination allowlists, DNS/IP filtering, and TLS certificate validation.
• Add monitoring for unusual 103 Early Hints responses from untrusted upstreams, Netty HTTP decoder exceptions, malformed response errors, and spikes in upstream connection resets.
• Because EPSS is low and the issue is not in KEV, handle through normal vulnerability remediation workflows unless the application contacts untrusted HTTP servers or processes sensitive data from pipelined HTTP responses, in which case expedite patching.