
Loading

Loading
We use strictly necessary cookies to run this site, and analytics cookies to understand how it's used. See our Privacy Policy for details.
A GitHub-reviewed security advisory, not necessarily under active exploitation the way our CISA KEV advisories are, but a real, disclosed vulnerability in an open-source dependency.
Affected packages
Vulnerable: < 6.28.1
Patched in 6.28.1
Vulnerable: >= 7.0.0, < 7.29.1
Patched in 7.29.1
Vulnerable: >= 8.0.0, < 8.10.2
Patched in 8.10.2
Details
Undici's interceptors.retry() can resume a request after a partial response and append the resumed bytes to an already partially delivered body, while the application still receives the original response's status and headers. When that response carried a Content-Length, the application can receive a longer body. Applications that forward Undici's status, headers, and body downstream without recalculating framing, for example proxy or gateway applications, may emit a response whose body exceeds the forwarded Content-Length, and the excess bytes can be read as the start of a subsequent HTTP response (downstream response splitting or desynchronization).
For example, a 404 Not Found with Content-Length: 2 that sends one byte then closes can be resumed with an open-ended Range request, and the resumed 206 Partial Content bytes are appended, so the application receives more than two body bytes while still seeing Content-Length: 2. The bug requires interceptors.retry() enabled, an attacker-controlled or faulty upstream, and a downstream forwarder that does not recalculate Content-Length.
Patched in undici v6.28.1, v7.29.1, and v8.10.2. Upgrade to one of these or later.
interceptors.retry() for untrusted upstreams, or set maxRetries: 0.Content-Length before forwarding a response body assembled by Undici.EPSS, exploit probability
Low0.31%
estimated chance of real-world exploitation in the next 30 days, higher than 24.1% of every CVE FIRST.org scores
Refreshed 11/14/2026, via FIRST.org's EPSS model, not CVSS, this measures likelihood of exploitation, not how severe it would be.
More npm advisories
Talk to us about this
Find out whether this dependency (or others like it) is actually reachable in your codebase.
Get help patching, or building dependency-scanning into your pipeline going forward.
A secure code review or supply chain review finds this before an advisory does.