The undici npm package is the high-performance HTTP client maintained by the Node.js team, and it is the engine behind Node's built-in fetch, which means most modern Node applications depend on it whether they installed it directly or not. Keeping npm undici patched matters because vulnerabilities here sit on your outbound network path, and several have been disclosed and fixed in recent releases.
If your app calls fetch on Node 18 or later, undici is already in your process. Treating it as an invisible dependency is the mistake.
What undici is and why it is everywhere
undici is a from-scratch HTTP/1.1 client built for speed, replacing the older http module patterns with connection pooling and a modern API. Its significance jumped when Node.js adopted it as the implementation behind the global fetch function. From Node 18 onward, calling fetch() routes through undici internally.
That gives it two footprints in your dependency graph. You may depend on undici directly as a package, and you also depend on the copy bundled inside your Node runtime. Both need attention, and they are patched differently: the standalone package via npm, the bundled copy via Node version upgrades.
Recent security history
undici has had a handful of CVEs, which is normal for a widely used networking library under active development. Two worth knowing about:
CVE-2025-22150 is an insecure-randomness issue. undici used Math.random() to select the boundary string for multipart/form-data requests, and Math.random() is not cryptographically secure. An attacker able to predict the boundary could potentially tamper with request bodies. It was fixed in versions 5.28.5, 6.21.1, and 7.2.3.
CVE-2025-47279 is a denial-of-service via bad certificate data. Applications using undici to implement a webhook-like system could be pushed into a memory leak if an attacker stood up a server with an invalid certificate and forced repeated calls to it. It was patched in versions 5.29.0, 6.21.2, and 7.5.0.
The pattern across undici's advisories is typical of an HTTP client: issues around request construction, TLS handling, and resource management under adversarial servers. None require exotic conditions, which is why staying current is the simplest defense.
How to check what you are running
Look at both footprints. For the standalone package:
npm ls undici
For the copy bundled in your runtime, check your Node version, since the bundled undici tracks Node releases:
node -p "process.versions.undici"
That second command prints the exact undici version compiled into your Node binary, which is the copy behind fetch. If it is old, the fix is a Node upgrade, not an npm command.
Keeping undici patched
For the standalone dependency, upgrade to a version at or above the fixed releases listed for the CVEs that apply to you. Because undici maintains several major lines (5.x, 6.x, 7.x) with backported fixes, pick the patched release on the major you are already using rather than forcing a major bump you are not ready for:
npm install undici@latest
# or stay on your major line with a patched version
npm install undici@6.21.2
If a vulnerable undici is transitive, use npm why undici to find the parent, then update that parent or apply an override:
{
"overrides": {
"undici": ">=6.21.2"
}
}
For the bundled copy behind fetch, keep Node on a supported LTS and apply its security releases. The Node team ships undici fixes as part of Node patch releases, so a routine runtime update usually carries them.
Reducing your own exposure
Beyond patching, a few habits shrink the blast radius of any HTTP-client bug:
- Validate URLs before fetching. If your app fetches attacker-influenced URLs (webhooks, avatar imports, link previews), guard against server-side request forgery by allowlisting hosts and rejecting internal addresses.
- Set timeouts. A slow or hostile server should not be able to tie up a connection indefinitely. undici supports request and connection timeouts; use them.
- Verify TLS. Do not disable certificate validation to "make it work." The CVE-2025-47279 DoS aside, turning off verification opens you to interception.
Seeing it across your fleet
The reason undici bugs linger is that teams forget it is there. It is bundled, transitive, and rarely on anyone's mind until an advisory lands. Continuous dependency scanning fixes the visibility problem: an SCA tool inventories every copy of undici across your services, matches versions against advisory feeds, and flags the ones behind a fixed release. Because it walks the resolved tree, it catches transitive copies your package.json never mentions. If you are weighing scanners, our comparison with Snyk covers how advisory coverage and transitive detection differ in practice.
FAQ
What is the undici npm package used for?
undici is a fast HTTP/1.1 client for Node.js maintained by the Node core team. It is also the engine behind Node's built-in fetch function from Node 18 onward, so most modern Node apps use it directly or through fetch.
How do I check the undici version behind fetch?
Run node -p "process.versions.undici". That prints the undici version bundled into your Node runtime, which is the copy that powers fetch. Update Node to patch it.
Which undici versions fix the recent CVEs?
CVE-2025-22150 (insecure randomness) was fixed in 5.28.5, 6.21.1, and 7.2.3. CVE-2025-47279 (certificate-related DoS) was fixed in 5.29.0, 6.21.2, and 7.5.0. Upgrade to the patched release on your major line.
Do I need to patch undici if I only use fetch?
Yes. fetch is implemented by undici, so a vulnerability in undici affects your fetch calls. The fix in that case is upgrading your Node runtime, since the fetch-backing copy is bundled with Node.