CVE-2022-0536: follow-redirects leaks Authorization heade...

What happened

CVE-2022-0536 is a sensitive-information-exposure vulnerability in follow-redirects, the small but enormously popular Node.js library that handles HTTP/HTTPS redirect-following for a huge share of the npm ecosystem — most notably as the transport layer underneath axios, one of the most widely used HTTP clients in JavaScript. The flaw: when follow-redirects processed a redirect response (a 3xx status with a Location header) that pointed to a different host than the original request, it continued to forward the original request's Authorization header to that new, unrelated host.

That behavior breaks a security assumption most developers take for granted. Browsers and well-behaved HTTP clients strip credential-bearing headers like Authorization and Cookie when a redirect crosses an origin boundary, precisely because the whole point of scoping those headers to a host is to prevent them from leaking somewhere else. follow-redirects, prior to the fix, did not perform that same-host check before re-attaching Authorization on the follow-up request.

Impact: in practice, this means any application making an outbound HTTP request with an Authorization header (bearer tokens, Basic auth credentials, API keys passed as bearer tokens, etc.) through a vulnerable version of follow-redirects/axios was at risk of silently forwarding that credential to a third-party host if the original server responded with a cross-domain redirect. That could happen because:

• The destination server was compromised or misconfigured to redirect elsewhere.
• An attacker controlled or influenced part of the redirect chain (e.g., open redirect on an intermediary, or a server-side request forgery style setup where the app followed a URL it didn't fully trust).
• A CDN, load balancer, or third-party integration issued an unexpected cross-origin redirect during normal operation.

The practical result is credential and token leakage — an attacker-controlled endpoint could passively receive live Authorization header values (OAuth bearer tokens, API keys, Basic-auth credentials) simply by causing or waiting for a redirect, with no need to compromise the calling application directly.

Affected versions and components

• Package: follow-redirects (npm)
• Affected versions: releases prior to the version that introduced the same-host check on the Authorization header during redirect handling. If your dependency tree resolves an older follow-redirects release, you are exposed.
• Indirect exposure: because follow-redirects is a dependency of axios and numerous other HTTP-related packages, applications rarely depend on it directly — they inherit it transitively. That's the core supply-chain wrinkle here: a team can be fully unaware they ship a vulnerable redirect handler because it's several layers down in node_modules, pulled in by a framework, SDK, or internal tool that itself depends on axios.
• Fixed in: the maintainers shipped a patch that strips Authorization from the outgoing request when the redirect target's host differs from the original request's host. Consumers should upgrade to the patched follow-redirects release (and, transitively, whatever axios/framework version pins that patched release) rather than pinning to anything older.

Because exact version boundaries for transitive dependencies shift depending on lockfile state and semver ranges, the reliable way to confirm exposure is to resolve the actual installed version in your lockfile (npm ls follow-redirects / yarn why follow-redirects / pnpm why follow-redirects) rather than trusting the version your top-level package.json declares for axios or another parent package.

CVSS, EPSS, and KEV context

CVE-2022-0536 is tracked in the NVD as a sensitive information exposure issue (CWE-200) with Medium severity under CVSS v3.x — reflecting that exploitation requires a specific condition (a cross-domain redirect actually occurring on a request that carries an Authorization header) rather than being trivially triggerable against every deployment. Severity should be read as a floor, not a ceiling: for an application whose Authorization header carries a long-lived, high-privilege token, the real-world blast radius of a single leaked header value can be far more damaging than a Medium rating implies.

On exploitation likelihood, we're not aware of this CVE appearing in CISA's Known Exploited Vulnerabilities (KEV) catalog, and it hasn't been associated with the kind of mass, automated exploitation campaigns that drive EPSS scores upward. That fits the vulnerability's profile: it's a passive-leak, condition-dependent issue (you need to control or observe a redirect target) rather than a remotely triggerable RCE or a pattern attackers can mass-scan for. Low EPSS and absence from KEV do not mean "ignore it," though — they mean the exposure is opportunistic and targeted rather than wormable, which is exactly the kind of risk that goes unnoticed until an incident review turns up a token in an access log on a server you don't control.

Timeline

• Discovery/disclosure: the issue was reported to the follow-redirects maintainer as a header-leak-on-cross-domain-redirect problem, consistent with a broader pattern of redirect-handling libraries across languages (not just Node.js) having to retrofit same-origin checks for sensitive headers that predate stricter cross-origin norms.
• Patch released: the maintainer shipped a fix that clears the Authorization header whenever a redirect changes the target host, aligning follow-redirects behavior with browser-standard cross-origin redirect handling.
• CVE assignment/publication: CVE-2022-0536 was published to track the issue, allowing dependency scanners and SCA tools to flag vulnerable installs.
• Downstream propagation: because axios and other packages depend on follow-redirects, the fix had to propagate through each downstream package's own release cycle before consuming applications could pick it up via a normal npm install/npm update — a common lag point in transitive-dependency remediation.

Remediation steps

1. Identify actual exposure. Run npm ls follow-redirects (or the yarn/pnpm equivalent) across every service and lockfile in your organization — not just the ones you remember using axios. Transitive dependencies hide in unexpected places: internal tooling, CI scripts, serverless functions, and vendored SDKs.
2. Upgrade, don't just patch the top level. Bump follow-redirects to a patched release, and make sure any package that pins an older axios/follow-redirects range is also updated — a patched follow-redirects sitting behind an axios version that still resolves an old range via npm-shrinkwrap/lockfile drift won't help you.
3. Regenerate lockfiles and rebuild. After bumping versions, regenerate package-lock.json/yarn.lock/pnpm-lock.yaml and rebuild all affected artifacts (including container images) so the fix actually ships, rather than just updating package.json ranges.
4. Rotate exposed credentials where redirects were possible. If you can identify any request path where an Authorization header was sent to a server capable of issuing cross-domain redirects — third-party APIs, webhooks, proxies — treat those tokens as potentially exposed and rotate them, especially long-lived API keys or Basic-auth credentials.
5. Add defense in depth at the application layer. Where possible, avoid attaching long-lived, high-privilege Authorization headers to outbound calls that traverse third-party or redirect-prone endpoints; prefer short-lived tokens, and validate redirect targets against an allowlist before following them in custom HTTP logic.
6. Bake SCA scanning into CI, not just point-in-time audits. A one-time npm audit catches what's vulnerable today; it won't catch a new transitive dependency introduced next sprint that reintroduces an old, vulnerable follow-redirects range.

How Safeguard Helps

CVE-2022-0536 is a textbook example of why software supply chain security can't stop at "we ran npm audit once." The vulnerable code lived several dependency hops away from most of the applications that shipped it, the exposure condition was environment-specific (it only mattered if your app sent Authorization headers through requests that could be redirected cross-domain), and the fix had to trickle down through multiple maintainers' release cadences before reaching end users.

Safeguard is built for exactly this class of problem:

• Continuous SCA across the full dependency graph — not just direct dependencies. Safeguard resolves and tracks transitive packages like follow-redirects wherever they appear across your services, so a vulnerable version buried under axios, a framework, or an internal SDK doesn't go unnoticed.
• Reachability-aware risk scoring — rather than flagging every instance of a vulnerable package with the same urgency, Safeguard helps teams understand which services actually send Authorization headers through affected code paths, so remediation effort goes to real exposure first.
• Drift detection over time, so a dependency that's clean today but gets pulled back into a vulnerable range by a future update — through lockfile changes, new transitive requirements, or a re-added dependency — gets caught on the next scan rather than at the next incident review.
• CVE and advisory correlation tied to your actual SBOM, so when a new advisory like this one lands, you get an immediate answer to "are we affected, and where" instead of a manual grep through every repo's package-lock.json.
• Remediation guidance and PR automation that surfaces the correct patched version and the affected package paths, so engineering teams can fix the actual vulnerable dependency chain rather than guessing at which top-level package to bump.

Header-leak vulnerabilities like CVE-2022-0536 rarely announce themselves — there's no crash, no obvious error, just a token quietly forwarded somewhere it shouldn't go. Catching that class of risk requires visibility into the full dependency tree and the request paths that traverse it, which is exactly the gap Safeguard is designed to close.