Live › vulnerability › CVE-2026-116689
Go to dashboardfollow-redirects 1.16.0 through 1.16.2 mishandles the sensitiveHeaders option when the array comes from another JavaScript realm, silently dropping the list. A custom credential header that should be stripped can then be forwarded to an attacker-controlled cross-origin redirect destination.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-27 20:33 UTC. All times on this page are UTC.
Applications that use follow-redirects 1.16.0 through 1.16.2 to make outbound HTTP or HTTPS requests, and that set a custom credential header via sensitiveHeaders so it is stripped on redirect. Exposure also requires the request to follow a redirect to a cross-origin host the attacker controls. Projects that do not set sensitiveHeaders or that run only on a single realm are less exposed, and projects on 1.16.2 or later are not affected.
No product ranges from the sources yet.
npm ls follow-redirects to find every installed copy and its version.sensitiveHeaders option to follow-redirects, for example in a wrapper around http or https.1.16.2 or later.sensitiveHeaders arrays created in another realm (such as from a VM context or iframe).Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
follow-redirects is a Node.js HTTP and HTTPS client wrapper that automatically follows redirects. From 1.16.0 until 1.16.2, the documented sensitiveHeaders option is checked with value instanceof Array, so an array created in another JavaScript realm is replaced with an empty list even though Array.isArray recognizes it. When a request then follows an attacker-controlled cross-origin redirect, a custom credential header named in that discarded list can be forwarded to the redirect destination. This issue is fixed in version 1.16.2.
This page as .md · .json · in your agent: get_signal("CVE-2026-116689")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.