- Severity: MEDIUM
- CVE: CVE-2026-118777
- Ecosystems: npm
- Packages: node-forge
### 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 so…
Source: GitHub Security Advisories · 2026-10-30