Live › vulnerability › CVE-2026-118777
Prior to 1.4.1, the forge.http client stored cookie names from Set-Cookie headers in plain JavaScript objects, so a malicious server could write attacker-chosen properties onto Object.prototype. The sources do not say what code paths beyond prototype modification an attacker can reach.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-29 19:26 UTC. All times on this page are UTC.
Only applications that use forge.http directly or through forge.xhr are affected, and only when they talk to a server that can send Set-Cookie headers. Applications that do not use forge.http are unaffected. Exposure is tied to the client-side cookie handling, so a team that only uses node-forge for cryptographic primitives can skip it.
No product ranges from the sources yet.
node-forge with npm ls node-forge and look for any version below 1.4.1.forge.http or forge.xhr, which are the affected components.node-forge 1.4.1Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
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.
This page as .md · .json · in your agent: get_signal("CVE-2026-118777")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.