CVE-2026-116689 in follow-redirects
Summary
by MITRE • 10/27/2026
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.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/27/2026
The follow-redirects library serves as a widely adopted Node.js HTTP and HTTPS client wrapper designed to automatically handle URL redirections, a common requirement in modern web application architectures where services frequently route traffic through intermediate endpoints or load balancers. A critical security vulnerability was identified within versions 1.16.0 through 1.16.2 of this library, specifically concerning the handling of sensitive headers during cross-origin redirects. The library provides a documented option called sensitiveHeaders, which allows developers to specify an array of header names that should not be forwarded when a redirect occurs across different origins. This mechanism is crucial for preventing the accidental leakage of authentication tokens, session cookies, or other credentials from a secure context to a potentially untrusted external domain.
The technical flaw stems from how the library validates whether the provided sensitiveHeaders value is an array. The implementation relies on checking if the input object is an instance of Array using the instanceof operator rather than utilizing the more robust and realm-agnostic Array.isArray method. In JavaScript, particularly in environments with multiple execution contexts or realms such as those found in complex web applications, iframe communications, or certain module loading scenarios, objects created in one realm are not considered instances of classes defined in another realm by the instanceof check. Consequently, an array constructed outside the current realm fails this specific type check and is incorrectly treated as a non-array value.
When the sensitiveHeaders parameter is misidentified due to this cross-realm issue, the library defaults to discarding the list entirely rather than preserving it for security checks. This behavior creates a dangerous blind spot in the redirect logic. If an application configures follow-redirects with a custom array of headers intended to be protected from leakage, and that array is created in a different JavaScript realm, the validation fails silently. The library then proceeds without any restrictions on header forwarding during redirects.
The operational impact of this vulnerability is significant when combined with attacker-controlled redirect scenarios. If an application uses follow-redirects to make requests that may result in cross-origin redirections controlled by an external party or a compromised third-party service, the failure to properly identify sensitive headers means those credentials are forwarded unconditionally. An attacker could exploit this by crafting a URL that triggers a redirect to their own server. Because the library fails to recognize the protected header list due to the realm mismatch, it transmits authentication cookies, authorization tokens, or other sensitive data in clear text to the malicious destination. This constitutes an unauthorized information disclosure vulnerability where confidential user credentials are exfiltrated without consent.
This issue aligns with CWE-200, which covers Information Exposure, as well as CWE-942, concerning Permissive Cross-domain Referrer Leakage. From a threat modeling perspective using the MITRE ATT&CK framework, this behavior facilitates data exfiltration and can be categorized under techniques related to Collection via Browser or Client-side Exfiltration if used in conjunction with other client-side vulnerabilities. The root cause is classified as CWE-697, Incorrect Comparison, specifically involving the misuse of type checking operators that do not account for multiple execution contexts.
The vulnerability was resolved in version 1.16.2 by replacing the instanceof Array check with a call to Array.isArray(). This standard method correctly identifies arrays regardless of their realm or origin, ensuring that sensitive header lists are properly recognized and enforced even when constructed in different JavaScript environments. Developers using versions prior to 1.16.2 should immediately upgrade to the patched version to restore the intended security controls for cross-origin redirects. Additionally, it is recommended to audit any custom implementations of redirect handling logic to ensure they utilize robust type-checking mechanisms that are resilient to multi-realm edge cases in JavaScript execution environments.