[CVE-2025-58056] Netty’s lenient chunk extension parsing opens the door to HTTP request smuggling

TL;DR
A standards violation in Netty’s HTTP decoder means that a newline (\n) without a preceding carriage return (\r) is accepted as the end of a chunk-size line. When a reverse proxy in front of Netty follows the RFC and insists on the full CRLF sequence, the two components end up with different views of where the request ends. That difference can be weaponised to smuggle requests, poison caches or bypass authentication. Fixed releases 4.1.125.Final and 4.2.5.Final were published alongside a GitHub advisory. Proof-of-concept payloads are public.

1. Summary

The bug allows an unauthenticated attacker to craft a single HTTP request that the reverse proxy and the Netty backend parse differently. By inserting a smuggled inner request, an attacker can reach endpoints that would normally be blocked by the proxy, poison intermediate caches or hijack another user’s session.

2. Context - Where Netty sits in the modern Java stack

Netty underpins scores of Java and Kotlin frameworks, from gRPC and Elasticsearch transport layers to Spring Boot’s reactive web stack. Cloud services often expose Netty behind NGINX, Traefik or AWS ALB. When those front-end components follow RFC 9112 and insist on a CRLF line ending, but Netty accepts a lone LF, a desynchronisation gap opens. Similar gaps have powered headline-making request smuggling exploits against AWS API Gateway, CloudFront and assorted CDNs. The widespread use of Netty therefore turns what looks like a niche parsing error into a high-leverage vulnerability.

3. Technical Details - One missing carriage return

HTTP/1.1 allows large bodies to be sent using chunked transfer encoding. Each body chunk starts with a line containing the chunk size in hex, optionally followed by semicolon-delimited extensions, and is terminated by the character pair \r\n.

Netty’s ChunkedInputHandler trims white space from the start of the extension parsing loop, then looks only for \n to mark the end of the line. As a result, the sequence

4;foo=bar\n

is accepted as a valid chunk header even though it violates the spec. A proxy that strictly requires \r\n will stop reading at the earlier legitimate CRLF, while Netty continues until the bare LF. By carefully positioning the stray LF an attacker can convince the proxy that the request is finished while Netty still expects more data. The remaining bytes become a second, hidden request.

Minimal reproduction

Save the following plaintext as smuggle.txt and pipe it to nc pointed at a vulnerable Netty service behind an RFC-compliant proxy.

POST /login HTTP/1.1
Host: example.com
Transfer-Encoding: chunked
Content-Length: 0

4
dead
0
GET /admin HTTP/1.1
X-Ignore: foo

The proxy forwards only the declared 4-byte chunk and the terminating 0\r\n\r\n, believing the request ends there. Netty swallows the lone LF after 4 and reads the leftover GET /admin as a second, authenticated request.

4. Impact - From cache poisoning to full account compromise

Real-world impact depends on how the vulnerable service is deployed:

• Public APIs that sit behind a Layer 7 load balancer can have authentication or rate-limiting enforced at the edge. A smuggled internal request bypasses those controls.
• Content-heavy sites may see cache poisoning. An attacker can serve malicious JavaScript or stale data to other users by forcing the reverse proxy to cache a crafted response under the wrong key.
• If the backend exposes administrative endpoints on the same port, a smuggled request can trigger configuration changes that were never meant to be internet-accessible.

Because request smuggling abuses legitimate HTTP syntax, Web Application Firewalls rarely block it without custom rules.

5. Remediation - Upgrade first, reconfigure if you cannot

The Netty team released 4.1.125.Final and 4.2.5.Final with a one-line fix that reinstates the CR check. Upgrading is a drop-in replacement for most applications.

When an upgrade is not immediately possible:

• Place a strict HTTP normaliser in front of Netty that rewrites or rejects any bare LF within chunk headers.
• Disable chunked transfer encoding by forcing clients to send a Content-Length header. This is practical for APIs with predictable request sizes.
• Enable HSTS and same-site cookies to limit the blast radius of cache poisoning and session fixation attacks.

6. Timeline

7. References

• Netty advisory: https://github.com/netty/netty/security/advisories/GHSA-fghv-69vj-qj49
• Patch commit: https://github.com/netty/netty/commit/edb55fd8e0a3bcbd85881e423464f585183d1284
• RFC 9112 section on chunked encoding: https://datatracker.ietf.org/doc/html/rfc9112#name-chunked-transfer-coding
• Issue tracker discussion: https://github.com/netty/netty/issues/15522
• PoC and deep dive: https://w4ke.info/2025/06/18/funky-chunks.html

About Volerion

Volerion delivers AI-driven enrichment minutes after a CVE goes live. A single call to our REST API returns CVSS 4.0 vectors, exploitability metrics and affected products complete with remediation. Additionally, we offer different scoring profiles, complete with insight into the eight comprehensive categories that make up the final score. Our API is also available in the traditional NVD API 2.0 format, so integration is as simple as swapping hosts. Spend less time parsing CVEs and more time closing them.

How the Volerion Risk Score fits with CVSS, EPSS and KEV

At the time of writing:

• This CVE is scored at 7.5 using CVSS 3.1, reflecting high integrity impact and network reachability.
• EPSS has no score yet because the CVE is brand new.
• CISA’s KEV listing is absent so there is no federal remediation deadline.

The Volerion Risk Score of 8.5 balances technical severity with the immediate availability of exploits and the prevalence of Netty across modern cloud stacks, providing a more actionable prioritisation signal than any single data point alone.