GHSA-r4q5-vmmm-2653

What it actually does

The vulnerable versions of the npm package follow-redirects can forward custom authentication-related HTTP headers when following a redirect to a different origin. If an application sends sensitive headers such as API tokens, bearer tokens, session cookies, or other custom credentials in an outbound request, and the response redirects to an attacker-controlled or otherwise untrusted domain, those headers may be included in the redirected request. This results in credential or secret disclosure to the redirect target.

Why it matters to the business

Applications that use affected versions of follow-redirects may unintentionally expose credentials or tokens to external services, especially when making requests to URLs that can be influenced by users, third-party services, or upstream APIs. Stolen credentials could allow unauthorized access to APIs, customer data, internal services, or third-party accounts. The issue is not listed in CISA KEV and has no reported exploit maturity in the provided data, but it has been public for 117 days, so affected dependencies should be considered overdue for remediation.

How an attack unfolds

An attacker needs a way to cause an application using follow-redirects to make an authenticated outbound HTTP request to a URL that returns a cross-domain redirect. This could happen through user-supplied URLs, integrations with third-party APIs, webhook fetchers, server-side request workflows, or a trusted endpoint that contains an open redirect. The vulnerable library follows the redirect and incorrectly includes custom authentication headers on the request to the new domain. If the redirect target is controlled by the attacker, they can capture the leaked headers from web server logs or request inspection tools. The attacker may then reuse the exposed token, API key, cookie, or credential against the service for which it was intended.

How to fix it

Upgrade follow-redirects to version 1.16.0 or later. If the package is a transitive dependency, update the parent dependency or use package manager override/resolution features to force follow-redirects to a fixed version. For npm-based projects, review package-lock.json, npm-shrinkwrap.json, yarn.lock, or pnpm-lock.yaml to ensure no vulnerable version remains. As defense in depth, avoid sending credentials when requesting URLs that may redirect, validate redirect targets before following them, restrict outbound requests to trusted domains, and ensure sensitive headers are stripped on cross-origin redirects.

How to confirm the fix worked

Confirm the installed dependency tree no longer contains vulnerable versions by running commands such as npm ls follow-redirects, npm audit, yarn why follow-redirects, or pnpm why follow-redirects depending on the package manager. Verify lockfiles resolve follow-redirects to 1.16.0 or later. Add a regression test that sends a request with a sensitive custom header to a controlled endpoint that returns a redirect to a different origin, and confirm the redirected request does not include the sensitive header. Review build artifacts and container images to ensure the updated dependency is present in deployed packages, not only in source repositories.

Typical attack path

1. Identify an application or service that uses a vulnerable version of the follow-redirects npm package.
2. Find a feature that causes the application to make outbound HTTP requests with authentication headers, such as API calls, webhook retrieval, URL previewing, integration polling, or file import by URL.
3. Cause the outbound request to target a URL that responds with an HTTP 3xx redirect to an attacker-controlled domain, or abuse an open redirect on a trusted domain.
4. Receive the redirected request at the attacker-controlled server.
5. Inspect captured HTTP headers for leaked authorization tokens, cookies, API keys, or other custom authentication headers.
6. Attempt to reuse the exposed credential against the relevant API, service, or account.

How to detect it

Look for evidence that applications using affected follow-redirects versions made authenticated outbound HTTP requests that were redirected to a different domain. Useful sources include application HTTP client logs, reverse proxy logs, egress proxy logs, DNS logs, web application logs, API gateway logs, and outbound firewall telemetry. Focus on HTTP 301, 302, 303, 307, or 308 responses where the Location header points to a different host, followed by a request to that new host carrying Authorization, Cookie, X-API-Key, or other custom credential headers. If full request headers are logged, search for sensitive headers sent to domains outside the expected allowlist. If an unexpected destination received such headers, treat the exposed credentials as compromised and rotate them. There are no universal exploit payloads or malware artifacts for this advisory; exploitation appears as normal HTTP redirect behavior with abnormal credential propagation.

What your security team should do

• Inventory all applications, services, containers, and serverless functions that include the follow-redirects npm package.
• Prioritize upgrades to follow-redirects 1.16.0 or later, especially in services that make outbound HTTP requests with authentication headers or process user-supplied URLs.
• Search lockfiles and software composition analysis results for vulnerable versions and ensure transitive dependencies are remediated.
• Review application logic that follows redirects while using Authorization, Cookie, API key, or custom credential headers.
• Add egress controls or allowlists for services that should only call known external APIs.
• Rotate credentials if logs show sensitive headers may have been sent to untrusted or unexpected redirect targets.
• Add automated dependency scanning to block reintroduction of vulnerable follow-redirects versions.