CVE-2025-58056

What it actually does

This vulnerability is an HTTP/1.1 request smuggling weakness in Netty caused by inconsistent parsing of chunk extensions in chunked transfer encoding. When Netty is deployed behind certain reverse proxies, the proxy and the Netty-based backend may disagree about where one HTTP request ends and the next begins. That parser differential can allow an attacker to cause bytes they control to be interpreted as a separate or prefixed backend request, potentially bypassing front-end routing, authentication, header normalization, or security controls that assume the proxy’s interpretation is authoritative.

Why it matters to the business

Systems using vulnerable Netty builds in HTTP-facing services, API gateways, application servers, or embedded Java services may be exposed to request routing confusion, unauthorized access paths, cache poisoning, session interference, or data exposure depending on how the reverse proxy and backend are configured. The current EPSS score is low and the issue is not listed in CISA KEV, but it has been public for an extended period and is associated with the MadeYouReset threat context, so internet-facing services using Netty behind reverse proxies should still be prioritized for review and remediation.

How an attack unfolds

An attacker sends a specially crafted HTTP/1.1 request using Transfer-Encoding: chunked and malformed or ambiguous chunk extension syntax. The front-end reverse proxy parses, normalizes, forwards, or delimits the request differently than the vulnerable Netty backend. Because the two components disagree on message boundaries, attacker-controlled bytes can be queued or interpreted by Netty as part of a subsequent backend request. In a successful attack, the attacker may smuggle a hidden request through the proxy, make the backend process requests that the proxy did not authorize or inspect as intended, poison responses for other users, or interfere with another client connection. Practical impact depends heavily on proxy behavior, connection reuse, backend routing, and whether authentication or authorization decisions are enforced only at the proxy layer.

How to fix it

Upgrade Netty to a version that includes the upstream fix for this issue. For source-based builds, ensure the code includes commit 406a58fd36e351b299553b3ceba5708f40a6153d or a later release containing that change. Because Netty is commonly embedded transitively, review dependency trees for all applications, frameworks, gateways, and vendor components that package Netty. Where immediate upgrade is not possible, mitigate by rejecting ambiguous HTTP/1.1 chunked requests at the edge, disabling backend connection reuse for affected routes where feasible, ensuring the reverse proxy fully normalizes or buffers requests before forwarding, rejecting chunk extensions if not required, and avoiding security decisions that are enforced only at the proxy while trusting the backend to receive identical request boundaries.

How to confirm the fix worked

Confirm that deployed artifacts use a Netty build containing commit 406a58fd36e351b299553b3ceba5708f40a6153d or a later fixed release. Validate application dependency manifests, software bills of materials, shaded JARs, container images, and runtime classpaths because Netty may be bundled indirectly. In staging, test representative reverse proxy and backend combinations with benign malformed chunk-extension requests and verify that the edge rejects them consistently or that both proxy and backend agree on request boundaries. Confirm that HTTP request smuggling test cases no longer produce response desynchronization, unexpected backend requests, or inconsistent status codes. Review proxy configuration to ensure request buffering, normalization, and Transfer-Encoding handling are consistent with vendor guidance.

Typical attack path

1. Identify an HTTP/1.1 service using Netty behind a reverse proxy, load balancer, CDN, API gateway, or ingress controller.
2. Confirm that the front end permits or forwards chunked requests to the backend rather than rejecting or fully normalizing them.
3. Send probe requests with Transfer-Encoding: chunked and unusual chunk extension formatting to test for proxy/backend parsing differences.
4. Observe timing changes, response desynchronization, unexpected status codes, duplicated responses, or evidence that a queued backend request was processed.
5. Refine the payload to smuggle a second HTTP request or alter the effective backend request seen by the Netty service.
6. Use the smuggled request to reach internal paths, bypass proxy-side controls, poison cacheable responses, or interfere with other users’ requests where connection reuse allows it.

How to detect it

Look for evidence of HTTP request smuggling attempts across reverse proxy, WAF, load balancer, CDN, application access, and Netty application logs. Useful telemetry includes raw HTTP request captures, WAF request bodies, proxy error logs, backend access logs, correlation IDs, connection IDs, and timing data. Focus on HTTP/1.1 requests using Transfer-Encoding: chunked with chunk extensions, unusual semicolon-delimited chunk-size lines, conflicting or repeated Transfer-Encoding and Content-Length headers, malformed chunk boundaries, unexpected backend requests that lack matching proxy log entries, multiple responses on a single client connection, bursts of 400/408/502/503 responses around malformed requests, and access to sensitive backend paths immediately following parser errors. Since successful exploitation may leave few application-level traces, compare front-end and backend logs by timestamp, source IP, connection reuse identifier, request ID, and requested path to find requests processed by the backend that were not clearly accepted by the proxy. If MadeYouReset-related activity is being tracked, include these chunked-request anomalies in threat hunting pivots, but do not treat the campaign name alone as a reliable indicator of compromise.

• Transfer-Encoding: chunked
• transfer-encoding: chunked
• Transfer-Encoding: chunked, chunked
• Transfer-Encoding: identity, chunked
• Content-Length: 0\r\nTransfer-Encoding: chunked
• Transfer-Encoding: chunked\r\nContent-Length:
• 0;
• 1;
• chunk-ext
• invalid chunk length
• invalid chunk
• HTTP/1.1 400 Bad Request
• HTTP/1.1 502 Bad Gateway
• io.netty.handler.codec.http.HttpObjectDecoder
• io.netty.handler.codec.http.HttpRequestDecoder
• TooLongHttpLineException
• TooLongFrameException
• DecoderException

What your security team should do

• Inventory internet-facing and internal HTTP services that use Netty directly or through frameworks, especially services behind reverse proxies, ingress controllers, API gateways, CDNs, or load balancers.
• Prioritize remediation for externally reachable services, multi-tenant APIs, authentication-adjacent services, and systems where the reverse proxy performs access control, routing, or header-based trust decisions.
• Upgrade affected Netty dependencies to a fixed build containing commit 406a58fd36e351b299553b3ceba5708f40a6153d or a later fixed release, including transitive and shaded copies.
• Add WAF, reverse proxy, or gateway rules to reject suspicious chunked requests with unusual chunk extensions while upgrades are being rolled out.
• Review proxy/backend HTTP parsing settings, request buffering, connection reuse, and Transfer-Encoding normalization to reduce parser differential risk.
• Run targeted request-smuggling validation tests after patching and after any proxy configuration changes.
• Hunt historical logs for malformed chunked requests, unexplained 400/502 responses, backend-only path access, response queue desynchronization, and MadeYouReset-related activity patterns where telemetry is available.