follow-redirects EUVD-2026-111363

Exploitation requires all of: follow-redirects 1.16.0 or 1.16.1; a direct caller or wrapper that supplies the sensitiveHeaders option as a genuine cross-realm array (for example one created with node:vm/runInNewContext or otherwise originating in a different JavaScript realm) - same-realm arrays are handled correctly and are not vulnerable; at least one custom credential header name listed in that sensitiveHeaders option; and an attacker-controlled or compromised endpoint that issues a cross-origin redirect which the client then follows. Limiting factors: built-in Authorization, Proxy-Authorization, and Cookie stripping remained effective and are not affected; callers (such as Axios 1.20.0) that normalize the array before passing it did not reproduce; and only the custom header(s) named in the discarded list are exposed. This combination is why the trigger is rated high-complexity rather than default-config remote.

This is a genuine but conditional information-disclosure flaw, best treated as medium rather than urgent. The CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N, 5.9) is internally consistent with the description: exploitation is network-reachable and needs no authentication or user interaction (PR:N/UI:N), but AC:H correctly reflects that several non-default preconditions must align - a caller must pass sensitiveHeaders as a genuine cross-realm array (e.g. built via node:vm), a custom credential header must be named in that option, and the attacker must control or compromise an endpoint that returns a cross-origin redirect. Impact is limited to disclosure of that one custom header (C:H, no integrity or availability effect). No EPSS score, KEV listing, or confirmed public working exploit is present in the input, and the SSVC/priority signal is 'this_month' rather than act_now or emergency, so the signals agree that this is a real-but-targeted issue, not mass-exploitable. The CVSS 4.0 reading supplied in the advisory (8.2 High) diverges upward mainly because 4.0 scores AC:L with AT:P, shifting the 'hard preconditions' from complexity into an attack requirement; the practical risk is unchanged - narrow preconditions, single-header disclosure. Note the advisory explicitly found built-in Authorization/Proxy-Authorization/Cookie protections unaffected and that Axios normalizes the array and did not reproduce, which further bounds real-world exposure.

A Node.js application uses follow-redirects 1.16.0/1.16.1 and passes a sensitiveHeaders list containing a custom credential header (e.g. X-API-Key) as an array created in another JS realm, such as via node:vm. Because the library checks the list with instanceof Array it silently drops the list, so when the client follows a redirect to an attacker-controlled cross-origin host, that custom header - which should have been stripped - is forwarded to the attacker. The advisory describes a loopback proof-of-concept demonstrating this, but the full harness is held privately.