node-fetch Security Guide (2026)

If you're tracking Node.js security news, node-fetch belongs on the list: it's the library that brought the browser's fetch API to Node.js. For years, before Node shipped a stable built-in fetch, it was the default way to make HTTP requests from server-side JavaScript, and it remains one of the highest-volume packages on npm — pulled in directly by application code and transitively by SDKs, API clients, and frameworks. Any library that "just needs to make an HTTP call" reached for it. That reach is what makes its security history worth knowing. node-fetch's two notable CVEs are not memory-corruption exotica; they are subtle protocol-handling mistakes — what happens to your headers and your size limits when a server responds with a redirect — and both are the kind of bug that behaves correctly in testing and leaks or stalls only against a hostile endpoint.

The notable historical CVEs

node-fetch's advisories center on redirect handling, the trickiest part of an HTTP client. Both are real, published advisories:

• CVE-2022-0235 — node-fetch forwarded sensitive headers across a cross-domain redirect. If a request carried an Authorization header or cookies and the server responded with a redirect to a different origin, node-fetch followed it and sent those secure headers to the new host — handing credentials to a third party the caller never intended to trust. Fixed in 2.6.7 on the 2.x line and 3.1.1 on the 3.x line, which strip sensitive headers when a redirect crosses origins.
• CVE-2020-15168 — node-fetch did not honor the size option after following a redirect. The size limit is meant to cap how many bytes a response body may contain, but once a redirect was followed the cap was not reapplied, so a malicious endpoint could return an unbounded body and exhaust memory — a denial of service. Fixed in 2.6.1 and 3.0.0-beta.9.

Both bugs share a lesson: a redirect is a trust boundary. Anything you assumed about the first request — who receives your credentials, how large the response can be — has to be re-evaluated for the destination, and node-fetch originally did not.

Common misuse and risks

• Sending credentials to attacker-controlled URLs. CVE-2022-0235 is most dangerous when your code fetches a URL that an attacker can influence while carrying an Authorization header or cookies. A redirect to their host leaks the credential. This overlaps heavily with SSRF: if the target URL comes from user input, redirects compound the risk.
• Fetching untrusted URLs at all. node-fetch will happily request whatever URL you give it, including internal addresses and cloud metadata endpoints. The library does not protect you from server-side request forgery — that is your responsibility.
• Trusting the size cap across redirects. On a vulnerable version, setting size gave a false sense of protection because it was dropped after a redirect (CVE-2020-15168).
• Unbounded responses and no timeouts. Reading a response body with no size limit or request timeout invites resource-exhaustion denial of service even apart from the CVE.

How to use node-fetch safely

Set the version floor: run node-fetch 2.6.7 or later on the 2.x line, or 3.1.1 or later on the 3.x line. Those releases fix the cross-origin header leak and sit above the size-limit-after-redirect fix. If you are on a modern Node.js runtime, also consider the built-in fetch, which removes node-fetch from your tree entirely.

Then treat outbound HTTP as a trust boundary:

• Never fetch attacker-controlled URLs with credentials attached. Separate authenticated internal calls from calls to URLs derived from user input, and validate or allow-list destinations before requesting them.
• Guard against SSRF explicitly. Resolve and check the target host, block private and link-local ranges and cloud metadata addresses, and decide deliberately whether to follow redirects for untrusted destinations.
• Set size and a timeout on every external request. Cap the response body and abort slow requests so a hostile endpoint cannot exhaust memory or hang the process.
• Re-evaluate trust on redirect. Prefer a configuration that strips sensitive headers on cross-origin redirects — patched node-fetch does this — and consider disabling automatic redirect following for high-risk calls.
• Pin and monitor. Commit a lockfile and confirm every resolved copy is patched.

How to monitor node-fetch with SCA and reachability

For teams building a broader node.js security or node js security program, node-fetch is a useful test case: it appears across a huge range of Node.js projects, frequently transitively through SDKs and clients, so a scanner will flag it widely. The bare finding tells you it is present; what matters is whether your code makes requests to attacker-influenced URLs while carrying credentials, and whether the resolved copy is patched.

Safeguard's software composition analysis resolves your full npm dependency graph, surfaces every node-fetch version in the tree, and adds call-path reachability so a header-leak advisory on a request path that actually handles untrusted URLs and credentials is separated from a copy that only ever calls a fixed, trusted endpoint. When a bump is warranted, autonomous auto-fix opens a tested pull request, and Griffin AI explains the exposure — including the SSRF interplay — in plain terms. Developers run the same analysis locally and in CI with the Safeguard CLI, and teams weighing options can review the pricing.

Bring continuous, prioritized dependency analysis to your Node.js services — get started free or read the documentation.

Frequently Asked Questions

Which node-fetch version is safe in 2026?

Run node-fetch 2.6.7 or later on the 2.x line, or 3.1.1 or later on the 3.x line. Those releases fix the cross-origin secure-header leak (CVE-2022-0235) and sit above the size-limit-after-redirect denial-of-service fix (CVE-2020-15168). On a current Node.js runtime you can also drop node-fetch in favor of the built-in fetch.

What was the node-fetch header-leak bug?

CVE-2022-0235: when a request carried an Authorization header or cookies and the server responded with a redirect to a different origin, node-fetch followed the redirect and sent those sensitive headers to the new host — leaking credentials to a third party. Patched versions strip sensitive headers when a redirect crosses origins.

Does node-fetch protect me from SSRF?

No. node-fetch requests whatever URL you pass it, including internal and cloud-metadata addresses, and following redirects can widen that exposure. Preventing server-side request forgery is your responsibility: validate or allow-list destinations, block private and link-local ranges, and decide deliberately whether to follow redirects for untrusted URLs.

How do I know if a node-fetch CVE actually affects my app?

Use reachability-aware SCA. It enumerates every node-fetch copy in your dependency tree and traces whether your code reaches a request path that handles attacker-influenced URLs or attaches credentials — so you can prioritize a genuinely reachable, unpatched copy over one that only calls a single trusted endpoint deep inside an SDK.