CVE-2026-118777 in forge
Summary
by MITRE • 10/29/2026
Forge (also called node-forge) is a native implementation of Transport Layer Security in JavaScript. Prior to 1.4.1, the forge.http client stored cookie names and paths from Set-Cookie response headers in ordinary JavaScript objects. A malicious server could use the cookie name __proto__ so that the attacker-controlled cookie path was written as a property on Object.prototype, or use inherited names such as constructor to modify Object. An empty cookie value could use the removal path to delete an inherited Object.prototype property. Applications using forge.http directly or through forge.xhr are affected; applications that do not use forge.http are unaffected. This issue is fixed in version 1.4.1.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/29/2026
The vulnerability identified in node-forge, a native implementation of Transport Layer Security written in JavaScript, represents a critical prototype pollution flaw within the HTTP client module. Prior to version 1.4.1, the library processed Set-Cookie response headers by storing cookie names and their corresponding paths directly into standard JavaScript objects without adequate sanitization or use of secure data structures such as Map or Object.create(null). This architectural decision created an attack surface where maliciously crafted server responses could manipulate the internal state of the application in unintended ways. The core technical flaw lies in how JavaScript handles property assignment on plain object literals, which inherit from Object.prototype by default. When a cookie name matches a key already present on the prototype chain or one that can be used to access it, such as _proto_, constructor, or hasOwnProperty, the library inadvertently modifies these inherited properties rather than creating new own properties on the instance.
This behavior enables an attacker-controlled server to perform prototype pollution attacks against any application utilizing forge.http directly or through its wrapper forge.xhr. By sending a Set-Cookie header with a name of _proto_, an attacker can inject arbitrary values into Object.prototype, effectively altering the behavior of all objects within that JavaScript execution context for subsequent operations. For instance, setting a cookie named _proto_ allows the injection of custom properties that may interfere with security checks, serialization processes, or other logic dependent on standard object behaviors. Similarly, using inherited names like constructor can allow an attacker to overwrite the constructor function itself, potentially leading to arbitrary code execution if combined with other vulnerabilities in the host application environment. The severity is compounded by the fact that even empty cookie values paired with specific path attributes could be leveraged to delete critical properties from Object.prototype, further destabilizing the runtime environment and removing essential safeguards provided by standard JavaScript objects.
The operational impact of this vulnerability extends beyond simple data corruption or session hijacking typically associated with cookie manipulation. Prototype pollution is a high-severity class of vulnerabilities because it affects the global state of the application's object model. In server-side applications using Node.js, this can lead to denial of service conditions by crashing the event loop through malformed property access patterns. In client-side contexts, it may allow cross-site scripting vectors or bypass security mechanisms that rely on checking for specific properties like hasOwnProperty or isPrototypeOf. Since forge.http is often used in environments where trust boundaries are critical, such as API clients interacting with untrusted third-party services, the ability to pollute prototypes undermines the integrity of data processing and state management throughout the application lifecycle. The vulnerability specifically impacts applications that rely on this HTTP client for making requests; those not using forge.http remain unaffected by this specific flaw but should still maintain updated dependencies to avoid other potential issues in the broader ecosystem.
Mitigation strategies primarily involve upgrading to node-forge version 1.4.1 or later, where the developers have addressed these prototype pollution vectors by implementing safer object handling mechanisms that do not rely on plain objects for storing cookie data without proper isolation. For applications unable to upgrade immediately, defensive coding practices should be employed within the consuming application layer. This includes validating and sanitizing all incoming HTTP headers before they are processed by any library functions, ensuring that only expected alphanumeric characters or safe symbols are accepted as cookie names. Additionally, developers can implement a temporary workaround by replacing standard object literals with Map objects or null-prototype objects for internal storage of cookie data if the source code is accessible and modifiable. It is also advisable to audit other parts of the application for similar patterns where user-controlled input from HTTP responses is assigned directly to plain JavaScript objects without checking against prototype keys. Regular security audits and dependency updates are essential to maintain resilience against such low-level but high-impact vulnerabilities in foundational networking libraries.