CVE-2026-42581

What it actually does

This flaw is an HTTP request parsing inconsistency in Netty's HttpObjectDecoder. For HTTP/1.1 requests, Netty removes a conflicting Content-Length header when Transfer-Encoding: chunked is also present, but prior to Netty 4.2.13.Final and 4.1.133.Final the same protection is missing for HTTP/1.0 requests. As a result, Netty may decode the request body using chunked framing while still forwarding a Content-Length header to downstream application logic, proxies, gateways, or handlers. If any downstream component gives precedence to Content-Length, the two components can disagree about where one HTTP request ends and the next begins, creating an HTTP request smuggling condition. The likely impact is limited integrity impact across a trust boundary, such as request desynchronization, bypass of routing or security controls, cache poisoning in certain deployments, or manipulation of a subsequent request stream.

Why it matters to the business

Applications and edge services built on affected Netty versions may be vulnerable to request smuggling when they sit in front of, behind, or alongside other HTTP parsers that interpret conflicting headers differently. In practical terms, this can allow attackers to bypass access controls, interfere with other users' requests, poison caches, or route hidden requests to internal handlers depending on deployment architecture. The current EPSS is low and stable, the issue is not listed in CISA KEV, and no exploit maturity is reported, but the vulnerability affects a widely used network framework and can be exposed anywhere Netty processes untrusted HTTP traffic.

How an attack unfolds

An attacker connects to a Netty-based HTTP service and sends a crafted HTTP/1.0 request that includes both Transfer-Encoding: chunked and Content-Length headers. The vulnerable Netty decoder treats the message body as chunked but does not strip the Content-Length header from the forwarded message. If the request then passes to another handler, proxy, gateway, load balancer integration, or application component that trusts Content-Length instead of Transfer-Encoding, that component calculates a different request boundary than Netty. The attacker can place additional bytes after the chunked body so that one parser treats them as part of the current request while another parser treats them as the beginning of a subsequent request. This parser desynchronization can be used to smuggle a hidden request, influence how the next request is processed, bypass front-end validation, or poison shared HTTP state. Successful exploitation depends on the surrounding HTTP processing chain and whether a downstream component disagrees with Netty's framing decision.

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 commonly included transitively through application frameworks, API gateways, RPC frameworks, and embedded servers, verify both direct and transitive dependencies in build manifests and software composition analysis results. If immediate upgrade is not possible, block or normalize HTTP requests that contain both Transfer-Encoding and Content-Length before they reach Netty, especially HTTP/1.0 requests. Reject ambiguous framing at reverse proxies, load balancers, WAFs, and service gateways. Prefer a single authoritative HTTP parser at trust boundaries and ensure downstream components do not re-interpret conflicting headers differently. Where supported, disable HTTP/1.0 from untrusted clients or enforce strict request validation that rejects Transfer-Encoding on HTTP/1.0 requests.

How to confirm the fix worked

Confirm that all deployed artifacts use Netty 4.2.13.Final or later, or 4.1.133.Final or later. Check dependency trees, container images, shaded JARs, fat JARs, application server libraries, and SBOMs for older io.netty artifacts. Validate runtime classpaths where possible because packaged dependencies may differ from source manifests. To test exposure safely, send a benign HTTP/1.0 request containing both Transfer-Encoding: chunked and Content-Length to a non-production endpoint and confirm the request is rejected, normalized, or processed consistently without forwarding both conflicting headers. Review reverse proxy and WAF rules to ensure ambiguous requests are denied before reaching the application. Confirm no application logs, access logs, or upstream gateway logs show accepted HTTP/1.0 requests containing both Transfer-Encoding and Content-Length after remediation.

Typical attack path

1. Identify a Netty-based HTTP endpoint that accepts direct or proxied HTTP/1.0 requests from untrusted clients.
2. Send probe requests containing both Transfer-Encoding: chunked and Content-Length headers and observe timing, response splitting, routing anomalies, or parser errors.
3. Craft an HTTP/1.0 request where Netty decodes the body as chunked while a downstream component may rely on Content-Length.
4. Append a second request or request prefix after the chunked terminator to create a disagreement about message boundaries.
5. Use the desynchronization to smuggle a hidden request, bypass front-end controls, poison cache entries, or interfere with subsequent request handling.
6. Repeat and refine payloads based on response behavior and backend parser characteristics.

How to detect it

Look for evidence of ambiguous HTTP framing in access logs, reverse proxy logs, WAF logs, application logs, packet captures, and Netty debug logs if enabled. High-value indicators include HTTP/1.0 requests that contain both Transfer-Encoding: chunked and Content-Length, requests with chunk terminators followed by additional HTTP methods, malformed or duplicate request-line errors, unexplained 400/408/502 responses around the same client connection, routing anomalies, or backend requests that do not appear in front-end logs. Compare front-end and backend logs for mismatched request counts, missing request IDs, unexpected methods or paths, and multiple backend requests associated with a single front-end request. If packet capture is available, inspect persistent connections for a chunked body ending in 0 followed by another embedded request line such as GET, POST, PUT, DELETE, PATCH, or OPTIONS. Because no named threat actors or public exploit maturity are reported, focus detection on protocol-level anomalies rather than actor-specific infrastructure.

• HTTP/1.0
• Transfer-Encoding: chunked
• Content-Length:
• Transfer-Encoding: chunked\r\nContent-Length:
• Content-Length:\r\nTransfer-Encoding: chunked
• \r\n0\r\n\r\nGET
• \r\n0\r\n\r\nPOST
• \r\n0\r\n\r\nPUT
• \r\n0\r\n\r\nDELETE
• \r\n0\r\n\r\nPATCH
• \r\n0\r\n\r\nOPTIONS
• io.netty.handler.codec.http.HttpObjectDecoder
• io.netty.handler.codec.http.HttpRequestDecoder
• netty-codec-http
• netty-all

What your security team should do

• Prioritize inventory of internet-facing and proxy-adjacent services that use Netty for HTTP processing, including services that embed Netty through frameworks or shaded dependencies.
• Upgrade affected Netty dependencies to 4.2.13.Final or later, or 4.1.133.Final or later, and rebuild/redeploy affected applications.
• Add edge controls to reject requests containing both Transfer-Encoding and Content-Length, with special attention to HTTP/1.0 traffic.
• Search historical logs for ambiguous HTTP requests using both headers to identify possible probing or exploitation attempts.
• Review architectures where Netty forwards traffic to another HTTP parser, proxy, gateway, or application layer that may make independent framing decisions.
• Add regression tests for conflicting HTTP framing headers so future dependency or proxy changes do not reintroduce request smuggling behavior.
• Monitor vulnerability intelligence for any change in exploit maturity, EPSS movement, or KEV listing, since request smuggling flaws can become more urgent when reliable exploit chains are published.