CVE-2023-26159

What it actually does

The flaw is an improper URL validation issue in follow-redirects versions before 1.15.4. When the library attempts to parse a URL and the modern URL parser throws an error, fallback parsing with url.parse() can interpret malformed URLs differently, causing the effective hostname used for redirect handling to differ from the hostname the application believes it is contacting. In applications that accept or construct redirect destinations from untrusted input, this can allow an attacker to force HTTP(S) requests or user-facing redirects to an attacker-controlled host, enabling open redirect behavior, credential or token leakage through redirected requests, phishing, and policy bypasses based on hostname allowlists. The issue is remotely triggerable, low complexity, and requires user interaction in common phishing/open-redirect scenarios. Public exploit techniques are available, but it is not listed in CISA KEV and has low EPSS at the time of assessment.

Why it matters to the business

Organizations using vulnerable follow-redirects versions may unintentionally send users or backend HTTP traffic to untrusted destinations. The most likely business risks are phishing using trusted application links, leakage of URL-embedded tokens or request metadata, reputational damage from abused redirects, and bypass of outbound destination controls in integrations that rely on hostname validation. Because follow-redirects is a common Node.js dependency, exposure may exist indirectly through transitive packages even where it is not imported directly. The vulnerability is older and has available exploit knowledge, so remediation should be handled through dependency hygiene and prioritized for internet-facing applications, authentication flows, payment or account workflows, and services that process externally supplied URLs.

How an attack unfolds

An attacker first identifies an application or service that uses a vulnerable follow-redirects release and accepts a URL, redirect target, webhook endpoint, callback URL, import URL, or other externally influenced destination. The attacker supplies a specially crafted malformed URL designed to trigger inconsistent parsing behavior: the application or validation logic may see an expected or allowed hostname, while follow-redirects ultimately follows or sends traffic to a different attacker-controlled hostname. If the vulnerable behavior is reachable through a user-facing redirect, the attacker can distribute a trusted-looking link that sends the victim to a malicious site after validation. If it is reachable through server-side HTTP requests, the attacker may cause the server to contact an unintended external host and potentially disclose headers, tokens, cookies, request bodies, or other metadata included in the outbound request. Successful exploitation generally depends on how the consuming application handles untrusted URLs and whether sensitive data is attached to redirected requests.

How to fix it

Upgrade follow-redirects to version 1.15.4 or later. For source-based remediation, ensure the dependency includes the fixed upstream commit 65858205e59f1e23c9bf173348a7a7cbb8ac47f5. Regenerate lockfiles after upgrading and verify that no transitive dependency still resolves to a vulnerable version. If immediate upgrade is not possible, mitigate by rejecting malformed URLs before they reach follow-redirects, using a single canonical URL parser for both validation and request execution, denying URLs containing ambiguous authority syntax such as encoded backslashes, raw backslashes, unexpected userinfo, control characters, or mixed encodings, and enforcing strict allowlists on normalized hostnames and schemes. Avoid placing secrets in URLs, do not forward sensitive headers across redirects to different origins, and disable automatic redirects or require explicit redirect validation for security-sensitive outbound HTTP clients.

How to confirm the fix worked

Confirm dependency remediation by inspecting package manifests and lockfiles for follow-redirects and verifying that every resolved instance is 1.15.4 or later, or includes commit 65858205e59f1e23c9bf173348a7a7cbb8ac47f5 for Git-sourced dependencies. Use npm, yarn, pnpm, SCA, or SBOM tooling to identify both direct and transitive copies. Run regression tests for URL-handling workflows with malformed URLs containing encoded backslashes, raw backslashes, userinfo delimiters, and invalid host syntax, and confirm the application rejects them or resolves the same canonical hostname throughout validation and request execution. For services that follow redirects, test that redirects to a different origin do not receive sensitive headers or tokens unless explicitly intended. Validate deployed artifacts, container images, and serverless bundles, not only source repositories.

Typical attack path

1. Find an application endpoint, integration, webhook, callback, import, or redirect flow that accepts or derives a destination URL from user-controlled input.
2. Determine whether the application uses follow-redirects before 1.15.4 directly or through a transitive Node.js dependency.
3. Craft a malformed URL that causes inconsistent hostname interpretation between validation logic and the library's redirect handling.
4. Submit the crafted URL to a vulnerable workflow or embed it in a phishing link sent to a target user.
5. Cause the application or user to follow the redirect to an attacker-controlled domain while appearing to pass validation for a trusted domain.
6. Capture leaked request data, URL parameters, tokens, headers, or credentials, or use the redirect as part of a phishing or trust-abuse campaign.

How to detect it

To determine whether this was already exploited, review application logs for endpoints that accept redirect, callback, webhook, return, next, url, target, destination, or import parameters and look for malformed URL syntax, especially encoded or raw backslashes, userinfo delimiters, invalid host characters, or unusually complex percent-encoding. Correlate those requests with reverse proxy, CDN, WAF, and egress proxy logs to identify cases where a request appeared to target an approved domain but was followed by outbound traffic or user redirects to an unrelated external host. For backend request flows, inspect outbound HTTP logs for unexpected destinations reached immediately after processing user-supplied URLs, especially if authorization headers, cookies, API keys, signed URLs, or request bodies may have been included. For user-facing exploitation, look for spikes in 3xx responses, phishing reports referencing trusted application links, unusual referrers from corporate applications to unfamiliar domains, and repeated requests using crafted URL encodings. Endpoint forensics are usually less useful because this is a library-level URL handling issue rather than code execution; focus on HTTP access logs, application request logs, redirect traces, WAF events, DNS logs, proxy logs, and outbound network telemetry.

• %5c@
• %5C@
• \\@
• %255c
• %255C
• http://%5c
• https://%5c
• http://%5C
• https://%5C
• Location: http://%5c
• Location: https://%5c
• Location: http://%5C
• Location: https://%5C
• url=http%3A%2F%2F%5c
• url=https%3A%2F%2F%5c
• redirect=http%3A%2F%2F%5c
• redirect=https%3A%2F%2F%5c
• returnUrl=http%3A%2F%2F%5c
• returnUrl=https%3A%2F%2F%5c
• next=http%3A%2F%2F%5c
• next=https%3A%2F%2F%5c
• destination=http%3A%2F%2F%5c
• destination=https%3A%2F%2F%5c
• target=http%3A%2F%2F%5c
• target=https%3A%2F%2F%5c
• callback=http%3A%2F%2F%5c
• callback=https%3A%2F%2F%5c
• follow-redirects@1.15.3
• follow-redirects@1.15.2
• follow-redirects@1.15.1
• follow-redirects@1.15.0

What your security team should do

• Inventory all Node.js applications and build artifacts for follow-redirects versions before 1.15.4, including transitive dependencies captured in lockfiles and SBOMs.
• Prioritize remediation for internet-facing services, login or account flows, payment workflows, webhook/callback handlers, URL fetchers, importers, and any feature that processes user-supplied URLs.
• Upgrade to follow-redirects 1.15.4 or later and regenerate lockfiles; verify Git-sourced dependencies include commit 65858205e59f1e23c9bf173348a7a7cbb8ac47f5.
• Add centralized URL validation that canonicalizes once and enforces allowed schemes and normalized hostnames before any outbound request or redirect.
• Review redirect behavior to ensure sensitive headers, cookies, bearer tokens, and request bodies are not forwarded to a different origin after a redirect.
• Search historical web, application, proxy, and egress logs for malformed URL patterns and unexpected redirects to newly observed or suspicious external domains.
• Add automated dependency policy checks to block vulnerable follow-redirects versions from future builds.
• Treat findings as medium priority overall, but escalate if the affected application handles authentication links, secrets in URLs, server-side URL fetching, or trusted-domain redirect flows.