CVE-2022-0155: follow-redirects leaks Proxy-Authorization...

CVE-2022-0155 affects follow-redirects, the small but extraordinarily widely-used Node.js library that handles HTTP and HTTPS redirect-following for popular clients like axios, node-fetch-adjacent tooling, and countless internal services. The flaw: versions of follow-redirects prior to the fix did not strip the Proxy-Authorization header when a redirect sent the request to a different host than the one the header was originally scoped to. In practice, that means an application configured to authenticate to an HTTP/HTTPS proxy could have its proxy credentials silently forwarded to a completely different — and potentially attacker-controlled — destination server once a redirect changed the target host.

For a library that exists specifically to transparently follow 3xx responses on behalf of the calling application, this is a textbook credential-leakage bug. The developer never sees it happen; the request simply "just works," redirects included, while the Proxy-Authorization header rides along to wherever the redirect chain ends up. If an attacker can influence a redirect target — through a compromised endpoint, an open redirect elsewhere in the chain, or a malicious server the client is coerced into talking to — they can harvest valid proxy authentication material without the victim application ever logging an anomaly.

Affected versions and components

• Package: follow-redirects (npm)
• Affected versions: releases prior to 1.14.7, which is the version that shipped the fix for this issue.
• Fixed in: follow-redirects 1.14.7 and later.

The practical blast radius is larger than the package's own download numbers suggest, because follow-redirects is a transitive dependency of axios — one of the most widely installed HTTP clients in the JavaScript ecosystem — as well as a dependency of numerous other HTTP tooling packages. Most consumers never install follow-redirects directly; they inherit it through axios or similar libraries, which is exactly why this class of vulnerability is a supply chain problem rather than a first-party code problem. A team can carefully review its own HTTP request logic and still ship a vulnerable dependency three or four levels down in node_modules.

It's also worth noting that this CVE shipped alongside a closely related sibling, CVE-2022-0536, which covers the analogous leak of the standard Authorization header across redirects to different hosts. Both were addressed together in the follow-redirects 1.14.7 release, and any remediation work should treat them as a matched pair rather than patching one and assuming the other is out of scope.

CVSS, EPSS, and KEV context

Public advisory data classifies CVE-2022-0155 as a medium-severity issue, consistent with a CVSS v3.1 vector reflecting a network-exploitable, low-complexity condition that requires a specific configuration (proxy authentication in use, plus a redirect to a different host) to be reachable — it does not grant remote code execution or full system compromise on its own, which keeps the severity in the medium band rather than critical.

The vulnerability is not listed in CISA's Known Exploited Vulnerabilities (KEV) catalog, and there is no public evidence of widespread active exploitation. EPSS scoring for this CVE sits at the low end typical of dependency-level information-disclosure bugs that require a specific proxy-authentication configuration to be exploitable — it is not the kind of vulnerability that shows up in mass internet scanning campaigns, because exploitation depends on the target application's proxy setup rather than a directly reachable network service.

That said, "medium severity, low EPSS" is exactly the profile that tends to get deprioritized in vulnerability backlogs — and exactly the profile that matters most for supply chain risk. Proxy credentials are often long-lived, shared across environments, and used to reach internal or metered infrastructure. A leaked Proxy-Authorization value can be far more damaging in a specific enterprise context than its generic CVSS score implies.

Timeline

• Prior to fix: follow-redirects versions before 1.14.7 retain the Proxy-Authorization header across redirects to different hosts, contrary to the expected behavior of scoping sensitive headers to the original destination.
• Disclosure and fix: The issue was reported and addressed by the follow-redirects maintainers, who shipped version 1.14.7 with logic to strip the Proxy-Authorization (and Authorization, under CVE-2022-0536) header whenever a redirect changes the target host.
• CVE assignment: The issue was assigned CVE-2022-0155 and published to the National Vulnerability Database, with a corresponding GitHub Security Advisory for the follow-redirects npm package.
• Downstream propagation: Because follow-redirects is a dependency of axios and other widely used packages, downstream projects needed their own dependency bumps (or lockfile updates) to actually pull in the fixed version — the fix landing in follow-redirects did not automatically protect consumers pinned to older resolved versions.

Remediation steps

1. Identify exposure. Run npm ls follow-redirects (or the Yarn/pnpm equivalent) across your services to find every resolved version, including transitive copies pulled in via axios or other HTTP clients. Don't assume a single version exists in your tree — npm's dependency resolution can leave multiple copies of follow-redirects at different versions across different subtrees.
2. Upgrade to a patched version. Ensure follow-redirects resolves to 1.14.7 or later everywhere it appears. If it's a transitive dependency, upgrading the direct dependency (e.g., axios) to a version that requires the patched follow-redirects is usually the cleanest path; a package.json overrides/resolutions entry can force the version where a direct upgrade isn't immediately available.
3. Regenerate the lockfile and verify. After bumping versions, regenerate package-lock.json/yarn.lock/pnpm-lock.yaml and confirm via npm ls that no vulnerable copy remains anywhere in the dependency tree.
4. Rotate proxy credentials if exposure is plausible. If your services route outbound traffic through an authenticated proxy and have historically followed redirects to third-party or less-trusted hosts, treat the associated proxy credentials as potentially exposed and rotate them, particularly if logs can't rule out cross-host redirects during the vulnerable window.
5. Review redirect-following configuration generally. Where possible, restrict or validate redirect targets for outbound requests that carry sensitive headers, rather than relying solely on the library's default header-scoping behavior. Defense in depth here means not assuming any single dependency will always get header scoping right.
6. Add CI-level dependency scanning. Bake a check into CI/CD that fails builds when known-vulnerable versions of common HTTP libraries (including follow-redirects) are present, so a future regression — say, a lockfile downgrade during a merge — doesn't silently reintroduce the issue.

How Safeguard Helps

CVE-2022-0155 is a clean illustration of why supply chain security has to operate below the level of "what did we write" and down at "what did we pull in." Nobody on a typical engineering team writes a line of code that says "leak the proxy credentials on redirect" — the exposure arrives quietly, several dependency layers removed from any code a reviewer actually reads.

Safeguard is built for exactly this gap. Our platform continuously inventories the real, resolved dependency graph across your repositories — not just the packages declared in package.json, but the transitive packages like follow-redirects that end up in node_modules through axios and similar libraries. When a CVE like this one is published, Safeguard cross-references it against every version actually deployed across your codebases and flags exact matches immediately, rather than waiting for a manual npm audit run someone remembers to trigger.

Because this vulnerability's severity is genuinely context-dependent — a medium CVSS score that can matter a great deal if your services route sensitive traffic through authenticated proxies — Safeguard's policy engine lets teams set enforcement rules that reflect their own risk posture: blocking builds that resolve to vulnerable follow-redirects versions, requiring lockfile verification before merge, or simply generating a prioritized remediation ticket scoped to the affected services rather than a generic org-wide alert.

Safeguard also closes the loop that manual processes tend to miss: after a fix is identified, we verify the patched version is actually present in the resolved lockfile across every affected repository, catching the all-too-common case where a direct dependency gets bumped but a stale lockfile or an overrides misconfiguration leaves the vulnerable transitive version in place. For vulnerabilities that hinge on specific usage patterns — like proxy authentication combined with cross-host redirects — Safeguard's software composition analysis surfaces not just "is this package present" but "is it present in a configuration where this CVE is actually exploitable," so security and engineering teams can prioritize the fixes that matter and avoid burning cycles on theoretical exposure.

The broader lesson from CVE-2022-0155 holds for the next dependency advisory too: attackers don't need to find a bug in your code when a bug in your dependency tree will do. Continuous, accurate visibility into what's actually running — and automated verification that fixes actually land — is the difference between a vulnerability that gets patched in hours and one that lingers, unnoticed, for months.