node-forge CVE-2026-118777

Exploitation requires that the application actually uses the forge.http client - either directly or through forge.xhr in the forge.all browser bundle with a configured socket pool - AND connects to a server the attacker controls or can influence, since the pollution is driven entirely by the server's Set-Cookie response headers (cookie names __proto__ or constructor, or an empty value to invoke the removal/delete path). Critically, forge.http is NOT loaded by require('node-forge'), so the common Node.js usage of node-forge for TLS/crypto is unaffected - this is the primary limiting factor. The deletion path skips the secure-flag and domain checks, so it works against both http:// and https:// clients. Applications that do not use forge.http/forge.xhr are not exploitable at all, and the impact is limited to Object/Object.prototype modification within the JavaScript realm (no direct code execution or data disclosure indicated by the evidence).

This is a genuinely moderate-severity issue rather than a high-CVSS-but-low-risk inflation case - the vendor-supplied CVSS 3.1 base score is 4.8 (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:L), which already reflects a limited blast radius: no confidentiality impact (C:N) and only low integrity and availability impact (I:L/A:L) from prototype pollution. The signals are largely consistent: AV:N and PR:N reflect that a remote, unauthenticated malicious server triggers the flaw, while AC:H captures the real-world precondition that the victim application must use the forge.http/forge.xhr code path against that untrusted server. EPSS is not provided in the input, and the CVE is not listed in CISA KEV, so there is no confirmed active exploitation. A detailed proof-of-concept and regression test are published in the GitHub Security Advisory itself. The vuln.today decision label is 'this_month' (not act_now/emergency), which aligns with a patch-this-cycle posture rather than an emergency. Net: real but bounded priority - the narrow exploitation surface (forge.http is not loaded by require('node-forge') and is only in the forge.all browser bundle with a socket pool) is the main factor keeping real-world risk lower than the network-reachable vector alone would suggest.

An application that uses the forge.http client (directly or via forge.xhr in the forge.all browser bundle) connects to an attacker-controlled or compromised server. The server returns a response with a crafted header such as 'Set-Cookie: __proto__=evil; path=polluted', causing forge.http's cookie store to write the attacker's value onto Object.prototype for the entire JavaScript realm; alternatively 'Set-Cookie: __proto__=; path=toLocaleString' deletes a built-in Object.prototype method (working for both http:// and https:// clients). A working proof-of-concept and regression tests are published in the GHSA advisory.