follow-redirects: Known Vulnerabilities and How to Stay Patched

follow-redirects has shipped fixes for two notable CVEs — an open-redirect flaw fixed in 1.15.4 and a Proxy-Authorization header leak fixed in 1.15.6 — and because it sits underneath axios, most Node.js applications carry it without ever choosing it. The package is a drop-in wrapper around Node's http and https modules that transparently follows HTTP redirects, which puts it in the most security-sensitive spot an HTTP helper can occupy: deciding where your requests go next and which credentials travel with them.

Why this small package matters so much

You will rarely see follow-redirects in a package.json. You will see axios. Axios delegates its redirect handling on Node to follow-redirects, which means the package rides along in a very large share of all JavaScript backends. When an advisory lands against it, the blast radius is "almost everyone running axios on the server," and the fix usually arrives via a transitive bump most teams never consciously perform.

That is the core operational problem this guide addresses: you must be able to answer "which follow-redirects npm version does my lockfile actually resolve?" quickly, because the manifest will not mention it at all.

npm ls follow-redirects
# └─┬ axios@1.x
#   └── follow-redirects@1.15.x

CVE-2023-26159: URL parsing confusion enabling open redirects

Disclosed in early January 2024 and affecting versions before 1.15.4, CVE-2023-26159 stemmed from improper handling of URLs in the code path that used url.parse(). When the platform URL parser threw on a malformed redirect target, follow-redirects could misinterpret the hostname and follow — or return — a redirect to a host other than the one the original URL intended.

The practical impact class is open redirect and, in server-side request contexts, SSRF-adjacent behavior: an attacker who controls a redirect response can steer a trusting client toward a host of their choosing. Anywhere your backend fetches URLs influenced by user input (webhook verification, link unfurling, importers), this bug turned "we validate the initial URL" into an incomplete defense, because the redirect target escaped that validation.

Fix: upgrade to 1.15.4 or later.

CVE-2024-28849: Proxy-Authorization kept across hosts

Two months later, CVE-2024-28849 showed a subtler credential-handling gap in versions up to and including 1.15.5. When following a redirect to a different origin, follow-redirects correctly cleared the Authorization header — but retained the Proxy-Authorization header. Any deployment that authenticates to an egress proxy could therefore replay those proxy credentials to an arbitrary redirecting host.

This one is easy to misjudge as low-risk ("we don't set that header") until you audit your environment: corporate proxies, egress gateways, and some SDK configurations inject Proxy-Authorization on your behalf. The advisory rates it moderate, but leaked proxy credentials tend to be broadly scoped, so treat exposure seriously.

Fix: upgrade to 1.15.6 or later.

The pattern behind both bugs

These CVEs — and the sibling issues that hit node-fetch and cross-fetch in the same era — share one root cause: redirects are a trust boundary, and every piece of request state must be re-evaluated when crossing it. Hostnames must be re-parsed strictly; credentials of every flavor (Authorization, Proxy-Authorization, cookies) must be dropped unless the new target provably shares trust with the old one. When you evaluate any HTTP client, write one integration test that redirects from a trusted local origin to a second origin and asserts that no credential headers survive the hop. That single test would have caught both follow-redirects issues and several equivalents in other libraries.

Staying patched in practice

Because the package arrives transitively, staying current is a lockfile discipline problem:

1. Regenerate resolutions on a schedule. npm update follow-redirects (or a lockfile-maintenance job in Renovate/Dependabot) pulls the newest in-range patch without touching axios itself — follow-redirects fixes ship as semver patches within 1.15.x.
2. Force the floor when an SDK lags. If some ancient tool pins a vulnerable version, override it:

{
  "overrides": {
    "follow-redirects": ">=1.15.6"
  }
}

3. Verify, don't assume. npm audit --omit=dev after regeneration, and check npm ls follow-redirects for duplicate resolutions — monorepos often carry two copies, one patched, one not.
4. Scan the lockfile continuously. Transitive pins are precisely what SCA scanning is built to watch; a tool like Safeguard flags the resolved version in every lockfile across your org, which beats relying on whichever repo happens to run npm audit locally. If you are comparing scanners for exactly this transitive-coverage question, our Snyk comparison covers how the approaches differ.

Hardening beyond version pins

Version currency is necessary but not sufficient. Defense-in-depth options that blunt this whole bug class:

• Cap redirects. Axios exposes maxRedirects; set it to the minimum your integrations genuinely need (often 0 for API-to-API calls — server APIs rarely redirect legitimately).
• Egress allowlisting. If your service should only talk to five hosts, enforce that at the network layer; a redirect to attacker.example then fails regardless of client behavior.
• Strip ambient credentials. Configure proxy auth as narrowly as possible, and prefer per-request credentials attached only after the final URL is known.

// axios: disable redirect following for API calls that never need it
const api = axios.create({
  baseURL: 'https://internal-api.example.com',
  maxRedirects: 0,
});

Health of the project

follow-redirects remains actively maintained: both CVEs were patched promptly, advisories were published through the standard GitHub process, and the maintainers coordinated with downstream axios releases. The project's track record on response time is good — the concern here has never been abandonment, only the outsized consequences any redirect bug has at this position in the dependency graph.

FAQ

Which versions of follow-redirects are vulnerable?

Versions before 1.15.4 are affected by CVE-2023-26159 (URL parsing confusion enabling open redirects). Versions up to and including 1.15.5 are affected by CVE-2024-28849 (Proxy-Authorization header retained across hosts). Running 1.15.6 or later clears both.

I use axios, not follow-redirects. Am I affected?

Yes, potentially — axios uses follow-redirects for redirect handling on Node.js. Run npm ls follow-redirects to see the version your lockfile resolves; the fix ships as a transitive patch update, no axios upgrade required.

How do I force a patched version through a stubborn dependency?

Use overrides in package.json (npm) or resolutions (yarn) to set a floor such as >=1.15.6, then reinstall and confirm with npm ls follow-redirects.

Does CVE-2024-28849 matter if I do not use a proxy?

Direct exposure requires a Proxy-Authorization header on outbound requests, which usually comes from egress proxies or injected SDK config. Audit whether your environment sets one before dismissing it — corporate egress infrastructure often does so invisibly.