CVE-2022-0235: node-fetch forwards sensitive headers on r...

CVE-2022-0235 is a sensitive-information-exposure vulnerability in node-fetch, the widely used fetch() implementation for Node.js. The flaw allowed node-fetch to forward sensitive request headers — specifically cookie, authorization, and www-authenticate — when a request was redirected (HTTP 3xx) to a different host than the one originally requested. In practice, that means an application making an authenticated request through node-fetch could have its session cookies, bearer tokens, or basic-auth credentials silently replayed to a third-party server if that request was ever redirected cross-origin — whether by a compromised upstream, a malicious API, an open redirect, or an SSRF-style chain. Because node-fetch sits underneath a huge share of the npm ecosystem's HTTP tooling, this "node-fetch header leak redirect" behavior had a wide, mostly invisible blast radius: teams calling fetch() directly rarely audit how their transitive HTTP client handles redirects, which is exactly why header-forwarding bugs like this one persist in production for years before discovery.

What the vulnerability actually does

Browsers apply well-defined rules for what happens to sensitive headers when a fetch is redirected across origins — the Fetch and CORS specifications strip or restrict headers like Authorization and Cookie when the redirect target's origin differs from the original request's origin. node-fetch, as a server-side, spec-adjacent reimplementation of fetch(), did not fully replicate this origin-check logic. Prior to the fix, node-fetch's redirect handling copied the original request's headers onto the follow-up request regardless of whether the Location header pointed at the same host, a different host, or an entirely different scheme.

For any Node.js service that:

• uses node-fetch to call third-party or partner APIs with an Authorization header or session cookie attached, and
• follows redirects automatically (the default redirect: 'follow' behavior),

a malicious or compromised endpoint on the other end of that request could respond with a 301/302/307/308 pointing to an attacker-controlled host, and node-fetch would happily attach the caller's credentials to the second request. This is a textbook CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor) issue, and it's particularly relevant in supply-chain contexts: webhook relays, API gateways, OAuth token exchanges, and internal service meshes that proxy requests through node-fetch were all plausible exposure points.

Affected versions and components

The vulnerability affects node-fetch across both of its major actively-used release lines:

• The 2.x branch, prior to the patched release 2.6.7
• The 3.x branch, prior to the patched release 3.1.1

Because node-fetch is a foundational dependency pulled in transitively by an enormous number of npm packages (HTTP clients, API SDKs, testing frameworks, CLI tools, and serverless function runtimes), the practical exposure extended well beyond applications that declared node-fetch as a direct dependency. Any project with a vulnerable node-fetch version anywhere in its dependency tree — and with code paths that attach credentials to outbound requests that could be redirected — was potentially affected. The fix was published upstream via the GitHub Security Advisory for node-fetch (tracked as GHSA-w7rc-rwvf-8q5r) and mirrored into the NVD as CVE-2022-0235.

CVSS, EPSS, and KEV context

Public vulnerability databases catalog CVE-2022-0235 as a network-exploitable, no-privileges-required issue whose impact is confined to confidentiality (credential/cookie disclosure) rather than integrity or availability — consistent with its CWE-200 classification. Severity ratings for this CVE vary somewhat between the GitHub Security Advisory and NVD scoring, which is common for issues where exploitability depends heavily on application-specific conditions (whether the app forwards credentials, whether it auto-follows redirects, and whether an attacker can control or influence a redirect target). We're intentionally not restating a single CVSS number here rather than risk citing an inconsistent figure — check the GHSA and NVD entries directly for the score as currently published, since these have been known to be revised after initial disclosure.

CVE-2022-0235 is not listed in CISA's Known Exploited Vulnerabilities (KEV) catalog, and there is no public evidence of widespread active exploitation. Real-world exploitation requires an attacker to control or manipulate the redirect target of a request the victim application makes with node-fetch and sensitive headers attached — a precondition (SSRF, compromised upstream, or malicious third-party API) rather than a directly internet-triggerable flaw. That constraint is reflected in the relatively low EPSS (Exploit Prediction Scoring System) likelihood typically associated with this class of vulnerability: it's a real and meaningful data-exposure risk, but it is not the kind of "scan the internet and pop it" bug that drives high EPSS percentiles or KEV inclusion. That does not make it low priority for affected applications — it makes it a targeted-exploitation risk that's easy to miss in dependency audits precisely because it doesn't show up as a headline-grabbing RCE.

Timeline

• Disclosure: The issue was reported and disclosed through node-fetch's GitHub Security Advisory (GHSA-w7rc-rwvf-8q5r), describing the forwarding of cookie, authorization, and www-authenticate headers across cross-origin redirects.
• Patch release: The node-fetch maintainers shipped fixes in v2.6.7 and v3.1.1, which add origin comparison logic before headers are re-attached to a redirected request — stripping sensitive headers whenever the redirect target's host differs from the original request's host.
• CVE assignment and NVD publication: The issue was assigned CVE-2022-0235 and published to the National Vulnerability Database in January 2022, shortly after the upstream fix, giving downstream consumers a canonical identifier to track alongside the GHSA advisory.
• Downstream propagation: As with most transitive npm vulnerabilities, the practical remediation timeline for most organizations extended well past the upstream patch date, since it depended on dependent packages bumping their node-fetch version ranges and on consuming applications refreshing their lockfiles.

Remediation steps

1. Identify exposure. Run npm ls node-fetch (or the equivalent for yarn/pnpm) across all services to find every direct and transitive instance of node-fetch, including nested copies pulled in by unrelated packages. A software bill of materials (SBOM) makes this trivial across an entire fleet of services instead of one repo at a time.
2. Upgrade to a patched version. Ensure node-fetch resolves to 2.6.7 or later on the 2.x line, or 3.1.1 or later on the 3.x line. If a transitive dependency pins an older, vulnerable range, use your package manager's override/resolution mechanism (overrides in npm, resolutions in yarn) until the upstream dependency updates its own constraint.
3. Audit redirect-following code paths. Even after patching, review any code that attaches Authorization headers, session cookies, or API keys to requests made with redirect: 'follow'. Where possible, set redirect: 'manual' for calls to third-party or untrusted endpoints and explicitly validate the redirect target's origin before re-issuing a request with credentials.
4. Rotate exposed credentials if you suspect prior exploitation. If logs show unexpected redirect responses from an endpoint that previously received an Authorization or Cookie header, treat those credentials as potentially disclosed and rotate them.
5. Re-run SCA/dependency scans after upgrading. Confirm the fix landed in your actual lockfile and built artifacts — not just your manifest — since Docker image layer caching and monorepo hoisting can leave stale, vulnerable copies in place even after a package.json bump.

How Safeguard Helps

CVE-2022-0235 is a good illustration of why supply-chain security can't stop at "is this CVE in the NVD." Safeguard's platform is built to catch exactly this category of risk before it becomes an incident:

• Continuous SCA across the full dependency graph. Safeguard resolves transitive dependencies — including nested, duplicated, and version-mismatched copies of packages like node-fetch — so a vulnerable version buried three layers deep in your node_modules tree doesn't go unnoticed just because it isn't a direct dependency.
• SBOM generation and drift detection. Every build produces an accurate, versioned SBOM, so when a new advisory like GHSA-w7rc-rwvf-8q5r drops, Safeguard can immediately tell you which services, containers, and deployed artifacts are affected — not just which repositories declare the package.
• Policy-driven build gating. Safeguard can block merges or releases that introduce or retain known-vulnerable ranges of node-fetch (or any package), so teams don't need to rely on someone remembering to check advisories manually.
• Prioritization beyond raw CVSS. Because CVEs like this one carry nuanced exploitability conditions — redirect-following behavior, credential attachment, attacker control over a redirect target — Safeguard's risk scoring incorporates reachability and usage context, helping teams triage real exposure instead of chasing every medium-severity CVE with equal urgency.
• Ongoing advisory monitoring. Safeguard tracks upstream GitHub Security Advisories in addition to NVD entries, closing the gap between when a fix like node-fetch 2.6.7/3.1.1 ships and when your organization's dependency scanners actually surface it.

Header-forwarding bugs like CVE-2022-0235 rarely make headlines, but they are exactly the kind of quiet, high-consequence issue that supply-chain security programs exist to catch — invisible in a typical code review, trivial to miss in a manual audit, and easy to remediate once you know it's there.