CVE-2023-26159: SSRF/credential exposure in follow-redire...

Lede

In late 2023, security researchers disclosed CVE-2023-26159, a vulnerability in the widely used Node.js package follow-redirects stemming from how the library parses URLs when processing HTTP redirect responses. Improper URL parsing meant that, under certain crafted redirect conditions, follow-redirects could send a request — potentially including sensitive headers such as Authorization — to a host other than the one the developer intended. That combination of behaviors is what earns this bug its dual label: a Server-Side Request Forgery (SSRF) condition paired with credential/header exposure across origins.

follow-redirects is not an application most engineers install directly — it's a transitive dependency pulled in by some of the most popular HTTP clients in the JavaScript ecosystem, most notably axios, as well as numerous other libraries that need automatic redirect handling for http/https requests. That ubiquity is exactly why URL-parsing bugs in follow-redirects tend to generate outsized attention: a flaw two or three dependency layers deep can silently affect thousands of downstream applications that never directly reference the package in their own code.

Affected Versions and Components

• Package: follow-redirects (npm)
• Vulnerable versions: Releases prior to 1.15.4
• Fixed version: 1.15.4 and later
• Ecosystem exposure: Any Node.js application or service that depends — directly or transitively — on a vulnerable follow-redirects version. The most common exposure path is through axios, which historically bundled follow-redirects as its default HTTP/HTTPS adapter. Other HTTP client wrappers, proxy tooling, and scraping/automation libraries built on top of Node's core http/https modules with redirect support have also pulled in the affected versions.

Because follow-redirects sits deep in the dependency graph, npm audit, npm ls follow-redirects, or an SBOM/SCA scan are typically the only ways teams discover they're exposed — a plain code review of first-party source will not surface it.

CVSS, EPSS, and KEV Context

CVE-2023-26159 has been assessed as a medium-severity issue in public vulnerability databases. The scoring reflects a network-exploitable weakness that requires an attacker to control (or influence) a redirect target — for example, by operating a malicious or compromised server that a victim application requests, or by injecting a redirect into a request chain — rather than a flaw that can be triggered arbitrarily by a remote attacker with no preconditions. That "requires a crafted redirect response" precondition is a meaningful mitigating factor and is a big part of why this doesn't score in critical territory despite touching credential material.

On exploitation likelihood, this CVE has not attracted the kind of active, mass-exploitation activity that drives high EPSS (Exploit Prediction Scoring System) percentiles, and it does not appear on CISA's Known Exploited Vulnerabilities (KEV) catalog. That doesn't make it safe to ignore — header-leak and SSRF bugs in redirect-handling libraries are exactly the class of issue that gets weaponized later in targeted supply-chain attacks, phishing infrastructure, or internal network reconnaissance once an application can be coerced into following an attacker-controlled redirect. Low current exploitation telemetry is a reason to prioritize sensibly, not a reason to deprioritize the fix.

Timeline

• Root cause: The underlying issue traces to how follow-redirects parsed and compared URLs when deciding whether a redirect target should be treated as "the same host" for purposes of forwarding sensitive headers like Authorization, Cookie, and Proxy-Authorization. Edge cases in URL parsing allowed that same-host determination to be bypassed or mishandled.
• Fix released: The maintainers shipped a corrected version, 1.15.4, which tightens URL parsing and header-forwarding logic to prevent sensitive headers from leaking to unintended hosts on redirect.
• Public disclosure: The issue was assigned CVE-2023-26159 and published to the National Vulnerability Database and GitHub Security Advisories in late 2023, alongside the patched release.
• Downstream remediation: Major consumers of follow-redirects, including axios, subsequently bumped their pinned or minimum dependency versions in follow-up releases so that fresh installs would pull in the patched code by default. Applications that had already locked their lockfiles to older resolutions, however, remained exposed until they explicitly updated.

This is a familiar pattern in npm-ecosystem CVEs: the fix lands quietly in a minor/patch version of a low-level dependency, and the real-world remediation timeline for any given organization depends entirely on how quickly their lockfiles and CI pipelines pick up the update — which, without automated dependency monitoring, can lag the actual patch by months.

Remediation Steps

1. Identify exposure. Run npm ls follow-redirects (or the Yarn/pnpm equivalent) across every service and repository to find where the package is resolved, and at what version. Don't assume — check transitive dependencies pulled in by axios and any other HTTP tooling.
2. Upgrade to 1.15.4 or later. If follow-redirects is a direct dependency, bump it directly. If it's transitive, upgrade the parent package (e.g., axios) to a version that requires the patched follow-redirects, or use overrides (npm) / resolutions (Yarn) / pnpm.overrides to force resolution to a safe version without waiting on every intermediate maintainer.
3. Regenerate and commit updated lockfiles. A version bump in package.json alone doesn't help if package-lock.json or yarn.lock still pins the vulnerable resolution.
4. Audit for actual credential exposure. If your application processes redirects from untrusted or third-party endpoints and sends authenticated requests (bearer tokens, API keys, session cookies) through follow-redirects-based clients, review logs/traffic for evidence that sensitive headers were forwarded cross-origin. If exposure is plausible, rotate the affected credentials.
5. Harden redirect handling at the application layer. Regardless of library patches, avoid blindly following redirects to arbitrary, user-influenced, or third-party-controlled URLs. Where feasible, allowlist expected redirect hosts, disable automatic redirect following for sensitive authenticated calls, or strip sensitive headers explicitly before any cross-origin hop.
6. Bake this into CI, not a one-time fix. Add SCA scanning (npm audit, Dependabot, Snyk, or equivalent) to your pipeline so future follow-redirects-class issues — and the next dependency with the same problem — are caught automatically rather than discovered during a manual review months later.

How Safeguard Helps

CVE-2023-26159 is a textbook illustration of the modern supply-chain security problem: the vulnerable code isn't in your repository, it's three node_modules layers deep, and traditional code review will never find it. Safeguard is built precisely for that blind spot.

• Full dependency graph visibility. Safeguard generates and maintains accurate SBOMs across your services, mapping not just direct dependencies but transitive ones like follow-redirects, so a follow-redirects ssrf url parsing issue buried under axios (or any other wrapper) is surfaced immediately rather than discovered by chance.
• Continuous vulnerability monitoring. As new CVEs are published against packages already in your environment, Safeguard flags affected services automatically — no need to wait for a quarterly audit or manual npm audit run to catch a header-leak vulnerability like this one.
• Reachability-aware prioritization. Not every instance of a vulnerable package is equally exploitable. Safeguard helps teams understand whether the vulnerable code path (in this case, redirect-following behavior with credentialed requests) is actually reachable in a given service, so engineering effort goes to genuinely exposed services first rather than every repository that happens to list the package.
• Risk context beyond the CVSS number. By correlating CVE data with EPSS trends, KEV status, and your own deployment context, Safeguard helps you separate "patch this in the next release" from "patch this today," which matters for medium-severity, precondition-dependent bugs exactly like CVE-2023-26159.
• Policy gates in CI/CD. Safeguard can enforce dependency-version policies at build time, blocking merges or deployments that would reintroduce a known-vulnerable follow-redirects (or any other flagged package) version — turning "we fixed it once" into "it stays fixed."
• Provenance and integrity checks. Beyond known CVEs, Safeguard verifies the provenance of the packages your build pulls in, reducing the risk that a compromised or typosquatted redirect-handling library slips into your supply chain in the first place.

Header-leak and SSRF bugs in low-level HTTP libraries rarely make headlines, but they sit at the heart of how modern applications trust and route requests. Treating dependency updates like follow-redirects 1.15.4 as routine hygiene — backed by automated, continuous scanning rather than periodic manual checks — is what keeps a medium-severity CVE from becoming the entry point for a much larger incident.