GHSA-6WVX-3R32-XMCG
Vulnerability from github – Published: 2026-10-30 23:02 – Updated: 2026-10-30 23:02Summary
The forge.http client stored cookies from Set-Cookie response headers in a plain object keyed by cookie name and path. A malicious server could use the cookie name __proto__ to add properties to Object.prototype, use inherited names such as constructor to add properties to Object, and send an empty cookie value to delete Object.prototype properties. Fixed in node-forge 1.4.1.
Details
client.setCookie() in lib/http.js stored a cookie with client.cookies[cookie.name][cookie.path] = cookie, creating client.cookies[cookie.name] only when !(cookie.name in client.cookies). Both values come from the server's Set-Cookie header via response.getCookies(). Because in also sees inherited properties:
- a cookie named
__proto__skipped the initialization,client.cookies['__proto__']returnedObject.prototype, and the cookie path was written as a newObject.prototypeproperty, visible on every object; - a cookie named
constructorwrote onto the globalObjectfunction the same way; - a cookie with an empty value calls
client.removeCookie(name, path), which used the sameinchecks and thendelete client.cookies[name][path], soSet-Cookie: __proto__=; path=toStringdeletedObject.prototype.toString. This path skipped the cookie's secure-flag and domain checks, so it also worked forhttp://clients.
forge.http is not loaded by require('node-forge'). It is included in the forge.all browser bundle and is used with a socket pool, for example by forge.xhr.
The fix uses own-property checks for the cookie store and ignores cookies named __proto__ or with the path __proto__.
Patches
Fixed in node-forge 1.4.1. Cookies from a server can no longer add or remove properties of Object.prototype or Object.
Workarounds
Don't use forge.http or forge.xhr with servers that aren't trusted, or filter Set-Cookie headers named __proto__, constructor or other Object.prototype property names before they reach the client.
Credits
Reported by @arunmozhivarman-dtx and @Dremig.
Proof of concept
A server response for a forge.http client (http.createClient({url: 'https://...', socketPool: ...})) containing:
Set-Cookie: __proto__=evil; path=polluted
On 1.4.0, after the client processes the response, ({}).polluted is the cookie object. With Set-Cookie: __proto__=; path=toLocaleString, Object.prototype.toLocaleString is deleted (for http:// and https:// clients). On 1.4.1 these cookies are ignored and Object.prototype is unchanged.
Regression tests are in tests/security/ghsa-6wvx-3r32-xmcg.js.
Impact
Applications that use the forge.http client (directly, or through forge.xhr in the forge.all browser bundle) against a server that can be malicious are affected. The server can add properties to Object.prototype and Object for the whole JavaScript realm, which can change application logic that reads properties from plain objects, and can delete built-in Object.prototype methods, breaking the page or process. Applications that don't use forge.http are not affected.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.4.0"
},
"package": {
"ecosystem": "npm",
"name": "node-forge"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.4.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-118777"
],
"database_specific": {
"cwe_ids": [
"CWE-1321"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-30T23:02:35Z",
"nvd_published_at": "2026-10-29T19:17:20Z",
"severity": "MODERATE"
},
"details": "### Summary\nThe `forge.http` client stored cookies from `Set-Cookie` response headers in a plain object keyed by cookie name and path. A malicious server could use the cookie name `__proto__` to add properties to `Object.prototype`, use inherited names such as `constructor` to add properties to `Object`, and send an empty cookie value to delete `Object.prototype` properties. Fixed in node-forge 1.4.1.\n\n### Details\n`client.setCookie()` in `lib/http.js` stored a cookie with `client.cookies[cookie.name][cookie.path] = cookie`, creating `client.cookies[cookie.name]` only when `!(cookie.name in client.cookies)`. Both values come from the server\u0027s `Set-Cookie` header via `response.getCookies()`. Because `in` also sees inherited properties:\n\n- a cookie named `__proto__` skipped the initialization, `client.cookies[\u0027__proto__\u0027]` returned `Object.prototype`, and the cookie path was written as a new `Object.prototype` property, visible on every object;\n- a cookie named `constructor` wrote onto the global `Object` function the same way;\n- a cookie with an empty value calls `client.removeCookie(name, path)`, which used the same `in` checks and then `delete client.cookies[name][path]`, so `Set-Cookie: __proto__=; path=toString` deleted `Object.prototype.toString`. This path skipped the cookie\u0027s secure-flag and domain checks, so it also worked for `http://` clients.\n\n`forge.http` is not loaded by `require(\u0027node-forge\u0027)`. It is included in the `forge.all` browser bundle and is used with a socket pool, for example by `forge.xhr`.\n\nThe fix uses own-property checks for the cookie store and ignores cookies named `__proto__` or with the path `__proto__`.\n\n#### Patches\nFixed in node-forge 1.4.1. Cookies from a server can no longer add or remove properties of `Object.prototype` or `Object`.\n\n#### Workarounds\nDon\u0027t use `forge.http` or `forge.xhr` with servers that aren\u0027t trusted, or filter `Set-Cookie` headers named `__proto__`, `constructor` or other `Object.prototype` property names before they reach the client.\n\n#### Credits\nReported by @arunmozhivarman-dtx and @Dremig.\n\n### Proof of concept\nA server response for a `forge.http` client (`http.createClient({url: \u0027https://...\u0027, socketPool: ...})`) containing:\n\n Set-Cookie: __proto__=evil; path=polluted\n\nOn 1.4.0, after the client processes the response, `({}).polluted` is the cookie object. With `Set-Cookie: __proto__=; path=toLocaleString`, `Object.prototype.toLocaleString` is deleted (for `http://` and `https://` clients). On 1.4.1 these cookies are ignored and `Object.prototype` is unchanged.\n\nRegression tests are in tests/security/ghsa-6wvx-3r32-xmcg.js.\n\n### Impact\nApplications that use the `forge.http` client (directly, or through `forge.xhr` in the `forge.all` browser bundle) against a server that can be malicious are affected. The server can add properties to `Object.prototype` and `Object` for the whole JavaScript realm, which can change application logic that reads properties from plain objects, and can delete built-in `Object.prototype` methods, breaking the page or process. Applications that don\u0027t use `forge.http` are not affected.",
"id": "GHSA-6wvx-3r32-xmcg",
"modified": "2026-10-30T23:02:35Z",
"published": "2026-10-30T23:02:35Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/digitalbazaar/forge/security/advisories/GHSA-6wvx-3r32-xmcg"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-118777"
},
{
"type": "WEB",
"url": "https://github.com/digitalbazaar/forge/commit/797c3f816a22748a96fceebb34eb3a6716853991"
},
{
"type": "PACKAGE",
"url": "https://github.com/digitalbazaar/forge"
},
{
"type": "WEB",
"url": "https://github.com/digitalbazaar/forge/releases/tag/v1.4.1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:L",
"type": "CVSS_V3"
}
],
"summary": "Forge: Prototype Pollution in forge.http cookie handling via a malicious Set-Cookie"
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.