CVE-2022-0536

What it actually does

In affected versions of the npm follow-redirects library prior to 1.14.8, sensitive request information may not be stripped correctly when an HTTP redirect is followed. If an application sends sensitive headers such as authorization tokens, cookies, or other credentials and the response redirects to a different host or less-trusted destination, those headers can be forwarded to the redirect target. The result is limited confidentiality impact: an attacker who can influence the original request target or redirect response may receive credentials intended only for the original service.

Why it matters to the business

Applications using vulnerable versions may unintentionally disclose API tokens, session cookies, or authorization headers to a redirected endpoint. In business terms, this can lead to unauthorized access to third-party services or internal APIs if leaked credentials are valid and sufficiently privileged. The public exploitation likelihood is currently low, with low EPSS, no known CISA KEV listing, and no known ransomware association, but the package is commonly used transitively in Node.js applications, so exposure can exist indirectly through dependencies.

How an attack unfolds

An attacker first needs a way to cause a vulnerable application to make an outbound HTTP or HTTPS request using follow-redirects while including sensitive headers. This could occur when an application fetches a user-supplied URL, contacts a compromised service, or communicates with a service whose redirect behavior the attacker can influence. The attacker-controlled or compromised endpoint returns an HTTP 3xx redirect to an attacker-controlled host. The vulnerable library follows the redirect and may incorrectly preserve sensitive request headers. The attacker then observes the redirected request on their server and captures the leaked credential material. The attacker can then attempt to reuse the captured token, cookie, or credential against the service for which it was originally intended.

How to fix it

Upgrade follow-redirects to version 1.14.8 or later. If consuming the library directly, update package.json and lockfiles, then rebuild and redeploy affected applications. If the dependency is transitive, update the parent package, use npm/yarn/pnpm override or resolution mechanisms where appropriate, and regenerate the lockfile. The upstream Git fix is commit 3d81dc3237b4ffe8b722bb3d1c70a7866657166e. As defense in depth, avoid sending sensitive headers to URLs influenced by users, validate outbound request destinations, disable automatic redirect following where not required, strip Authorization and Cookie headers before following cross-origin redirects, and use short-lived, least-privileged tokens.

How to confirm the fix worked

Confirm that no deployed application or container image includes follow-redirects versions prior to 1.14.8. Check package-lock.json, npm-shrinkwrap.json, yarn.lock, pnpm-lock.yaml, SBOMs, and node_modules/follow-redirects/package.json. Run dependency scanners such as npm audit, OSV-Scanner, Snyk, GitHub Dependabot, or equivalent SCA tooling and verify the finding is resolved. Functional validation can be performed in a controlled test by sending a request with a benign test Authorization header to a local server that redirects to a second host, then confirming the redirected request does not receive the sensitive header.

Typical attack path

1. Identify an application or workflow that performs outbound HTTP requests using the vulnerable follow-redirects library.
2. Cause the application to send a request containing sensitive headers, such as Authorization or Cookie, to a URL whose redirect behavior can be influenced.
3. Return an HTTP 301, 302, 303, 307, or 308 redirect to an attacker-controlled domain or endpoint.
4. Receive the redirected request and inspect headers for leaked credentials or tokens.
5. Replay or use the exposed credential against the original service or related APIs, subject to token scope, expiration, and access controls.

How to detect it

There is no universal exploit signature for this issue because exploitation appears as normal outbound HTTP redirect behavior. To determine whether it was already exploited, review application, proxy, egress gateway, WAF, and HTTP client logs for outbound requests that included sensitive headers and then followed a 3xx redirect to a different host, domain, scheme, or trust boundary. Focus on requests made by Node.js services using follow-redirects before 1.14.8, especially requests to user-controlled URLs, webhook destinations, third-party integrations, URL fetchers, or previously compromised endpoints. Look for sequences where a request containing Authorization, Cookie, X-API-Key, Proxy-Authorization, or similar headers receives a 301/302/303/307/308 response and is immediately followed by a request to an unrelated domain. If full request headers were logged, search for sensitive header names in outbound requests to domains that should not receive them. If potential leakage is found, identify the exact credential, determine its scope and lifetime, revoke or rotate it, and review downstream service logs for subsequent use from unexpected IP addresses, user agents, geographies, or applications.

What your security team should do

• Inventory all Node.js applications and container images for direct or transitive use of follow-redirects prior to 1.14.8.
• Prioritize remediation for services that make outbound requests to user-supplied URLs, third-party endpoints, webhook targets, URL previewers, integrations, or any destination outside direct administrative control.
• Upgrade to follow-redirects 1.14.8 or later, or apply package-manager overrides/resolutions where transitive dependencies delay remediation.
• Review application code for outbound requests that attach Authorization, Cookie, X-API-Key, or similar sensitive headers while allowing redirects.
• Add guardrails to block or require approval for cross-origin redirects when sensitive headers are present.
• Rotate credentials if logs show sensitive headers may have been sent to untrusted redirect destinations.
• Add monitoring for unusual outbound 3xx redirect chains from backend services to unfamiliar domains.