follow-redirects CVE-2026-111755

Requires a narrow set of concrete preconditions: (1) the application runs follow-redirects 1.16.0 (the only affected version); (2) the application explicitly declares a sensitive/strippable header whose NAME contains a regex metacharacter ^ or | (an unusual naming choice); and (3) the outgoing request follows a cross-origin or HTTPS-to-HTTP redirect, with the attacker controlling the redirect target. Limiting factors: exploitation is impossible unless the developer uses such metacharacter-bearing header names, so default configurations and conventionally-named headers are NOT affected; this is reflected by AT:P in the CVSS 4.0 vector. No victim user interaction or authentication is needed on the attacker's side.

This is a credential-leak flaw (CWE-185, incorrect regular expression) in follow-redirects, a hugely popular Node.js HTTP/HTTPS client wrapper. The supplied CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N) scores 8.2 (High) and reflects a network-reachable, unauthenticated issue with high confidentiality impact but - critically - AT:P, meaning a specific attack requirement must be met. That requirement sharply narrows real-world risk: the victim application must declare a sensitive header whose NAME contains the regex metacharacters ^ or | AND then follow a cross-origin or HTTPS-to-HTTP redirect. These are uncommon header-name choices, so despite the High score and ubiquitous library, practical exposure is limited. No EPSS score was provided; the CVE is NOT on CISA KEV, and no public exploit code was supplied - the only source evidence is the vendor patch diff, not a weaponized POC. Signal summary: high nominal severity and broad deployment, but a genuine attack precondition (unusual sensitive-header naming) plus no evidence of exploitation means this is a 'patch-on-normal-cadence' issue rather than an emergency, for most deployments. Note the impact is pure information disclosure (VI/VA = N), consistent with the description of a leaked credential header.

An application using follow-redirects 1.16.0 declares a sensitive header with a name containing ^ or | (e.g., a custom auth token header) to be stripped on redirect. The attacker causes the application's request to be redirected cross-origin (or HTTPS→HTTP) to a server they control; because escapeRegex fails to escape ^ and |, the strip filter does not match and the credential header is forwarded to the attacker's endpoint. No public exploit code was supplied - only the vendor fix commit is available.