CVE-2026-1525: Duplicate Content-Length Headers in undici

CVE-2026-1525 affects the undici HTTP client for Node.js, scored 6.5 (medium). When headers are passed as a flat array with names that differ only by case, undici can send two conflicting Content-Length values. Upgrade to 6.24.0 or 7.24.0, the patched versions in the advisory, and normalize header names that come from user input.

What's affected

• Package: undici on npm.
• Affected: versions before 6.24.0, and 7.x versions before 7.24.0. The advisory writes this as below 6.24.0 and from 7.0.0 up to but not including 7.24.0.
• Fixed: 6.24.0 and 7.24.0.
• Severity: the record scores it 6.5. GitHub rates the advisory moderate at 4.8. It is not on the CISA Known Exploited Vulnerabilities list.
• Who is impacted, per the advisory: applications that call undici.request(), undici.Client or similar low level APIs with headers passed as flat arrays, and applications that accept user controlled header names without normalizing case.

The advisory covers the npm package. If a runtime or tool bundles its own copy of undici, check that vendor's release notes for the fixed version rather than assuming it tracks the npm release.

How to check if you're exposed

Find every copy of the package in your projects:

npm ls undici

Versions below 6.24.0, or from 7.0.0 up to 7.23.x, are in range. Transitive copies count, so run the command in every service and in each workspace of a monorepo. A lockfile search is also quick:

grep -n '"undici"' package-lock.json

Then ask whether your code can reach the problem. Search for places where you build a headers array by hand, and for places where header names come from a request, a configuration file or another service:

grep -rn "undici" --include=*.js --include=*.ts . | grep -i "headers"

If you always pass headers as a plain object, the advisory notes that this naturally deduplicates by key, so the described path does not apply. If you pass arrays and some header names come from outside your code, treat the finding as live and fix it first.

What to do now

1. Upgrade undici to 6.24.0 or later on the 6.x line, or 7.24.0 or later on the 7.x line, and refresh the lockfile.
2. If you cannot upgrade yet, use the advisory's workarounds: pass headers as a plain object, or lowercase header names and reject duplicates before the call.
3. Review any code that forwards user supplied header names to an outbound request. Allow only a fixed list of names.
4. Check that any proxy or gateway in front of your backends rejects duplicate Content-Length headers, so a malformed request cannot be read two ways.
5. Redeploy and confirm the version inside the running image.

Why it matters

The advisory classifies the flaw as CWE-444, inconsistent interpretation of HTTP requests, commonly called HTTP request smuggling. The rule in RFC 9110 is that Content-Length must not be sent more than once. HTTP header names are case insensitive, so Content-Length and content-length are the same header. undici failed to treat them as the same when headers arrived in an array, and it put both on the wire.

The advisory describes two consequences. The mild one is denial of service: strict parsers such as proxies and servers answer a request with duplicate Content-Length values with a 400 error, so affected calls simply fail. The serious one depends on the deployment. If an intermediary and a backend disagree about which value to trust, one using the first and the other the last, a request can be split differently by each. The advisory lists ACL bypass, cache poisoning and credential hijacking as possible results in that situation.

Note how conditional this is. It needs a particular calling pattern in your code, and for the worse outcome it needs two components that parse duplicates differently. That is why the score is medium and why exploitability matters more than the number here. Your own HTTP stack tells you whether the severe version is possible: if every hop rejects duplicates, a malformed request fails loudly and goes no further.

Smuggling bugs are easy to miss because both sides think they are following the standard. The durable fix is at the boundaries. Normalize header names at the edge of your service, refuse requests with duplicate length headers, and keep the HTTP client current.

Try it yourself

A medium score does not tell you whether your code takes the risky path. This demo shows how to check exploitability before you rank the fix.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• GitHub advisory GHSA-2mjp-6q6p-2qxm for undici
• CWE-444 definition on MITRE

Last reviewed: 19 October 2026.