CVE-2026-42580

What it actually does

Netty’s HTTP chunked-transfer parser accepted chunk-size values that could overflow a signed integer before Netty 4.2.13.Final and 4.1.133.Final. Because the malformed chunk size may be interpreted differently by Netty and by an upstream proxy, load balancer, gateway, or downstream application component, an unauthenticated remote attacker can create HTTP request desynchronization conditions. The primary technical consequence is HTTP request smuggling, where attacker-controlled bytes are treated as part of a different request by one component in the request chain. This can enable limited integrity and availability impact, such as bypassing routing or access-control assumptions, poisoning connection state, interfering with other users’ requests on reused connections, or causing malformed request handling.

Why it matters to the business

Applications and services built on vulnerable Netty versions may mishandle specially crafted HTTP traffic, especially when deployed behind reverse proxies, API gateways, ingress controllers, or load balancers. Business impact can include unauthorized actions through request-routing confusion, disruption of web/API traffic, cache or connection poisoning, and difficult-to-diagnose intermittent application errors. The CVSS score is moderate and EPSS is currently low and flat, with no CISA KEV listing and no known public exploit maturity reported, but Netty is widely embedded in Java services and frameworks, so exposure may exist indirectly through dependencies and should be remediated through dependency updates.

How an attack unfolds

An attacker sends a specially crafted HTTP/1.1 request using chunked transfer encoding with an abnormally large chunk-size value designed to trigger integer overflow in Netty’s chunk parser. If Netty and another HTTP component in the path, such as a reverse proxy or application gateway, disagree about where the request body ends and where the next request begins, the attacker can desynchronize the shared connection. The attacker then places a second, smuggled HTTP request in the byte stream. One component may treat it as body data while another treats it as a new request, allowing the attacker to influence the next request processed on that connection or reach endpoints under different parsing, routing, or authorization assumptions. Successful exploitation depends on the surrounding HTTP chain and connection reuse behavior, but it requires no 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. Because Netty is often included transitively through Java frameworks and application servers, review the full dependency tree and ensure packaged or shaded Netty artifacts are also updated. Rebuild and redeploy affected applications after dependency updates. If immediate upgrade is not possible, reduce exposure by disabling HTTP/1.1 chunked request bodies where feasible, normalizing or rejecting oversized chunk-size values at the edge, closing backend connections on malformed requests, disabling risky connection reuse between proxies and backends where practical, and ensuring all front-end and back-end HTTP components enforce consistent parsing behavior. These mitigations should be treated as temporary controls, not substitutes for upgrading.

How to confirm the fix worked

Confirm the runtime classpath and packaged artifacts use Netty 4.2.13.Final or later, or 4.1.133.Final or later. Use dependency tooling such as Maven dependency:tree, Gradle dependencies, software composition analysis, container image scanning, and artifact inspection to identify io.netty modules, including shaded or bundled copies. Validate running services by checking build manifests, SBOMs, container layers, and deployed JARs rather than only source manifests. After remediation, send benign test requests using chunked transfer encoding with oversized hexadecimal chunk-size values and confirm the service or edge layer consistently rejects them, closes the connection safely, and does not produce request desynchronization behavior. Also verify that proxy, gateway, and backend logs show consistent handling of malformed chunked requests.

Typical attack path

1. Identify an HTTP service or API endpoint backed by a Netty-based server or framework using vulnerable Netty versions before 4.2.13.Final or 4.1.133.Final.
2. Confirm that HTTP/1.1 chunked transfer encoding is accepted and that the service is deployed through one or more intermediaries such as a proxy, load balancer, gateway, or ingress controller.
3. Send probing requests with malformed or oversized chunk-size values and observe differences in responses, timeouts, connection reuse, or backend behavior.
4. Craft a desynchronization payload containing an oversized chunk-size header followed by attacker-controlled bytes that one component treats as body data and another treats as a separate request.
5. Use the smuggled request to interfere with request routing, poison a reused connection, bypass front-end checks, or trigger unintended backend actions.
6. Repeat or automate the technique against high-value endpoints if the HTTP chain remains desynchronized.

How to detect it

Investigate whether exploitation has already occurred by reviewing HTTP access logs, reverse proxy logs, WAF events, API gateway logs, load balancer logs, and Netty/application logs for malformed chunked-transfer requests. Focus on requests with 'Transfer-Encoding: chunked' and unusually large hexadecimal chunk-size lines, especially values near or above signed 32-bit integer boundaries such as 80000000, ffffffff, or longer hex values. Look for clusters of 400, 408, 411, 413, 414, 431, 499, 502, 503, or 504 responses, unexpected backend connection resets, request timeout anomalies, and logs indicating invalid chunk sizes or malformed HTTP messages. Correlate suspicious requests with subsequent unexpected requests on the same source IP, user agent, connection, or proxy/backend connection where available. Because request smuggling often leaves indirect traces, also review authentication, routing, and application audit logs for requests reaching unusual paths, methods, hosts, or administrative endpoints immediately after malformed chunked requests from the same source or connection pool.

• Transfer-Encoding: chunked
• transfer-encoding: chunked
• 80000000
• FFFFFFFF
• ffffffff
• 100000000
• 7fffffff
• invalid chunk
• Invalid chunk
• invalid chunk size
• Invalid chunk size
• malformed chunk
• Malformed chunk
• chunk size
• TooLongHttpLineException
• TooLongFrameException
• DecoderException
• CorruptedFrameException
• io.netty.handler.codec.DecoderException
• io.netty.handler.codec.http.HttpObjectDecoder
• io.netty.handler.codec.http.HttpRequestDecoder
• io.netty.handler.codec.http.HttpServerCodec
• HTTP/1.1 400
• HTTP/1.1 408
• HTTP/1.1 502

What your security team should do

• Prioritize inventory of internet-facing Java services, API gateways, and backend applications that embed Netty, especially those accepting HTTP/1.1 traffic through reverse proxies or load balancers.
• Upgrade all affected Netty dependencies to 4.2.13.Final or later, or 4.1.133.Final or later, including transitive, shaded, and vendor-bundled copies.
• Add software composition analysis checks to CI/CD and container scanning to prevent reintroduction of vulnerable Netty versions.
• Review edge proxy and application gateway settings to reject malformed chunked transfer encoding and oversized chunk-size values before traffic reaches backend Netty services.
• Search HTTP access logs, WAF logs, proxy logs, and application logs for evidence of oversized hexadecimal chunk-size values, malformed chunked requests, parser errors, abnormal 400/408/502 responses, and unexpected connection resets.
• Where feasible, enable request smuggling protections in WAF, API gateway, ingress, and load balancer products and ensure front-end and back-end HTTP parsing policies are aligned.
• Because current EPSS is low, flat, and there is no KEV listing, schedule remediation according to normal internet-facing dependency patch SLAs, but accelerate for exposed API platforms or services with sensitive authorization boundaries.