GHSA-6wvx-3r32-xmcg

Dashboard / Vulnerabilities / GHSA-6wvx-3r32-xmcg

GHSA-6wvx-3r32-xmcg

Summary: Forge: Prototype Pollution in forge.http cookie handling via a malicious Set-Cookie

Details: ### Summary 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__']` returned `Object.prototype`, and the cookie path was written as a new `Object.prototype` property, visible on every object; - a cookie named `constructor` wrote onto the global `Object` function the same way; - 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's secure-flag and domain checks, so it also worked for `http://` 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.

References: https://github.com/digitalbazaar/forge/security/advisories/GHSA-6wvx-3r32-xmcg, https://nvd.nist.gov/vuln/detail/CVE-2026-118777, https://github.com/digitalbazaar/forge/commit/797c3f816a22748a96fceebb34eb3a6716853991, https://github.com/digitalbazaar/forge, https://github.com/digitalbazaar/forge/releases/tag/v1.4.1