CVE-2026-42585

What it actually does

Netty versions prior to 4.2.13.Final and 4.1.133.Final incorrectly parse malformed Transfer-Encoding headers. When Netty is deployed behind or in front of another HTTP component that interprets the same request differently, an attacker can create HTTP request desynchronization. This can cause one HTTP parser to treat attacker-controlled bytes as part of the current request while another treats them as the start of a second request. The likely impacts are request smuggling, bypass of front-end routing or access controls, poisoning of subsequent requests, limited exposure of another user's request/response data, or manipulation of application behavior. The CVSS profile indicates unauthenticated remote exploitation with low complexity and potential confidentiality and integrity impact, but no direct availability impact.

Why it matters to the business

Applications and services built on vulnerable Netty versions may mishandle specially crafted HTTP requests, allowing attackers to interfere with normal web traffic and potentially bypass security controls at proxies, gateways, load balancers, or application layers. This can lead to unauthorized actions, leakage of sensitive request data, cache or routing abuse, and hard-to-investigate web application anomalies. Although this issue is not currently listed in CISA KEV, has low EPSS, and has no known mature public exploitation signal in the provided data, Netty is a widely used Java networking framework, so exposure can exist indirectly through many downstream applications and embedded dependencies.

How an attack unfolds

An attacker sends a crafted HTTP request to a service using a vulnerable Netty HTTP parser, typically where Netty is one component in a request chain involving a proxy, load balancer, gateway, CDN, WAF, or upstream application server. The request contains malformed Transfer-Encoding syntax, duplicate Transfer-Encoding values, conflicting Content-Length and Transfer-Encoding headers, or other ambiguity that causes Netty and another HTTP component to disagree about where one request ends and the next begins. The attacker then appends a second, smuggled request in the same TCP connection or payload. If the front-end component forwards bytes that Netty interprets differently, the smuggled request may be processed under the wrong security context, routed to an unintended backend path, queued ahead of a victim request, or used to poison a shared connection. Successful exploitation depends heavily on deployment topology and parser differences, but does not require authentication or user interaction.

How to fix it

Upgrade Netty to a fixed release: 4.2.13.Final or later for the 4.2.x line, or 4.1.133.Final or later for the 4.1.x line. If Netty is included transitively through another framework or platform, upgrade the parent dependency or override the Netty dependency to a fixed version after compatibility testing. Where immediate upgrade is not possible, reduce exposure by normalizing or rejecting ambiguous HTTP requests at the earliest ingress point, especially requests with malformed Transfer-Encoding, duplicate Transfer-Encoding, both Content-Length and Transfer-Encoding, obsolete line folding, or unusual whitespace in header names/values. Ensure front-end proxies, gateways, and Netty-based services use consistent HTTP/1.1 parsing rules, disable unsafe connection reuse where feasible, and prefer HTTP/2 end-to-end where supported and correctly terminated. Mitigations should be treated as temporary; parser fixes in Netty are the durable remediation.

How to confirm the fix worked

Confirm software composition analysis, dependency manifests, build output, and runtime classpaths no longer include vulnerable Netty artifacts below 4.2.13.Final or 4.1.133.Final. Check Maven, Gradle, shaded JARs, container images, and application server bundles because Netty is often included transitively. Validate using dependency tools such as `mvn dependency:tree`, `gradle dependencies`, SBOM scanners, container scanners, and runtime inspection of loaded Netty JAR versions. After patching, send controlled negative tests with malformed Transfer-Encoding, duplicate Transfer-Encoding, and conflicting Content-Length/Transfer-Encoding headers and confirm they are rejected consistently at the edge or application layer. Also verify reverse proxy and backend logs agree on request boundaries, status codes, and request counts for each test connection.

Typical attack path

1. Identify an externally reachable service or API endpoint that uses vulnerable Netty versions directly or through a Java framework, gateway, or embedded server.
2. Determine whether the service is behind another HTTP component such as a reverse proxy, load balancer, WAF, CDN, or upstream/downstream server with different HTTP parsing behavior.
3. Send benign probe requests containing ambiguous or malformed Transfer-Encoding and Content-Length combinations to test for differential parsing, timing anomalies, connection reuse issues, or unexpected responses.
4. Craft a request where the front-end component and Netty disagree on the request boundary.
5. Append an attacker-controlled smuggled HTTP request after the ambiguous request body or header sequence.
6. Use the smuggled request to reach internal routes, bypass access controls, alter application state, poison cache or connection state, or interfere with another user's request.
7. Repeat and tune payloads based on response behavior, backend timing, and whether the target reuses HTTP connections.

How to detect it

To determine whether exploitation may already have occurred, review HTTP access logs, reverse proxy logs, WAF/CDN logs, Netty application logs, API gateway logs, and packet captures for malformed or ambiguous HTTP/1.1 request headers. Focus on requests containing Transfer-Encoding anomalies, duplicate Transfer-Encoding headers, both Content-Length and Transfer-Encoding, unusual whitespace around header names or values, chunked encoding syntax errors, unexpected 400/408/502 responses, backend requests without corresponding front-end requests, front-end and backend request count mismatches, and repeated short-lived connection reuse anomalies. Look for suspicious access to internal-only paths, administrative routes, unexpected methods, or requests that appear immediately after malformed header probes from the same source IP or connection. If full packet capture or HTTP request logging is available, compare how ingress proxies and Netty-based services recorded the same connection; request smuggling often appears as one request at the edge but two requests at the backend, or as unexplained backend requests with missing client metadata. There are no provided named threat actors or known active campaigns for this CVE, so detection should be behavior-based rather than actor-specific.

• Transfer-Encoding: chunked, chunked
• Transfer-Encoding: chunked\r\nTransfer-Encoding:
• Transfer-Encoding : chunked
• Transfer-Encoding:\tchunked
• Transfer-Encoding: chunked
• Transfer-Encoding: xchunked
• Transfer-Encoding: chunked;
• Transfer-Encoding: identity
• Content-Length: 0\r\nTransfer-Encoding: chunked
• Transfer-Encoding: chunked\r\nContent-Length:
• Transfer-Encoding: chunked\r\n\r\n0\r\n\r\nGET
• Transfer-Encoding: chunked\r\n\r\n0\r\n\r\nPOST
• Transfer-Encoding: chunked\r\n\r\n0\r\n\r\nHEAD
• Transfer-Encoding: chunked\r\n\r\n0\r\n\r\nOPTIONS
• Transfer-Encoding: chunked\r\n\r\n0\r\n\r\nPUT
• Transfer-Encoding: chunked\r\n\r\n0\r\n\r\nDELETE
• Transfer-Encoding: chunked\r\n\r\n0\r\n\r\nPATCH
• Invalid chunked encoding
• malformed Transfer-Encoding
• multiple Transfer-Encoding headers
• Both Content-Length and Transfer-Encoding
• HTTP/1.1 400 Bad Request
• HTTP/1.1 502 Bad Gateway

What your security team should do

• Inventory all applications, gateways, Java services, containers, and third-party products that bundle Netty, including transitive dependencies and shaded JARs.
• Prioritize internet-facing HTTP services, API gateways, reverse proxies, WebSocket endpoints, and services behind load balancers or WAFs where HTTP request parsing differentials are most exploitable.
• Upgrade to Netty 4.2.13.Final or later, or 4.1.133.Final or later, and redeploy affected services after compatibility testing.
• Add or tighten ingress rules to reject ambiguous HTTP/1.1 requests containing malformed Transfer-Encoding, duplicate Transfer-Encoding, or both Content-Length and Transfer-Encoding.
• Review proxy, gateway, CDN, and WAF configurations for request normalization and consistent backend forwarding behavior.
• Monitor for request smuggling probes in access logs, WAF logs, reverse proxy logs, application logs, and packet captures, especially unusual Transfer-Encoding syntax and desynchronization symptoms.
• Because EPSS is low and the issue is not currently KEV-listed, prioritize remediation based on exposure and criticality rather than emergency global patching, but do not defer internet-facing systems unnecessarily.
• Retest after remediation with safe request-smuggling test cases to confirm malformed requests are rejected and no backend desynchronization occurs.