KEVWire

Security intelligence, with context.

Response snapshot Oct 31, 2026, 01:26 UTC

Back to the wire
Permalink
VulnerabilityCVE-2026-118777

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

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.

At a glance

Exploited
Not known
Severity
4.8 Medium (CVSS 3.1)
Chance of exploitation
Not estimated
Sources
1 source

What to do

GitHub lists first patched versions: node-forge: 1.4.1. Confirm the affected range and upgrade guidance in the exact advisory.

Read GitHub-reviewed advisory GHSA-6wvx-3r32-xmcg (opens a new tab)

What happened

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:

Continue reading

- 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.

Affected package ranges reported by GitHub: node-forge: <= 1.4.0

Scores and how they were measured

CVSS base severity

4.8

Version 3.1As of

CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:L

Measurement source (opens a new tab)

How bad it is if exploited. Not a prediction of exploitation or proof you are exposed.

EPSS probability

Not available

A model's estimate of exploitation in the next 30 days, not certainty or your own risk.

Related technology

Sources

  1. Primary source

    GitHub-reviewed advisory GHSA-6wvx-3r32-xmcg (opens a new tab)

    The public advisory supplies the description, affected package/version ranges, and any listed CVSS metric. GitHub review is not local review.

    Published Checked

  2. Primary source

    GitHub public advisory API page (opens a new tab)

    The API page supplied GHSA-6wvx-3r32-xmcg, its actual identifiers, source dates, and structured metrics.

    Published Date not suppliedChecked

Cite this record

For factual claims, cite the primary sources above; cite KEVWire for its compilation, dates, and classifications.

APA

KEVWire. (2026, October 30). Forge: Prototype Pollution in forge.http cookie handling via a malicious Set-Cookie (CVE-2026-118777). https://kevwire.com/record/CVE-2026-118777

MLA

"Forge: Prototype Pollution in forge.http cookie handling via a malicious Set-Cookie (CVE-2026-118777)." KEVWire, 30 Oct. 2026, kevwire.com/record/CVE-2026-118777.

Chicago

KEVWire. "Forge: Prototype Pollution in forge.http cookie handling via a malicious Set-Cookie (CVE-2026-118777)." Last modified October 30, 2026. https://kevwire.com/record/CVE-2026-118777.

Evidence summary (plain text)

Forge: Prototype Pollution in forge.http cookie handling via a malicious Set-Cookie (Oct 30, 2026).
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.

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).
CVSS 4.8 (version 3.1; evidence as of Oct 30, 2026; https://github.com/advisories/GHSA-6wvx-3r32-xmcg).
Sources:
GitHub-reviewed advisory GHSA-6wvx-3r32-xmcg: https://github.com/advisories/GHSA-6wvx-3r32-xmcg
GitHub public advisory API page: https://api.github.com/advisories?type=reviewed&per_page=100&sort=updated&direction=desc
Record ID: CVE-2026-118777.
Record origin: Ingested record.
AI evidence: Not assessed.
Known exploitation: Not assessed.
Zero-day status: Not assessed. KEV membership alone does not establish zero-day status.
About this data

This record was ingested from a data source. Retrieved: Oct 31, 2026, 00:50 UTC. Ingestion is not an independent editorial investigation.

A CISA KEV listing documents known exploitation, not necessarily a zero-day; absence from the catalog does not prove a vulnerability has never been exploited.

Technology tags indicate possible relevance, not verified exposure. Confirm the affected product, version, and configuration against your own inventory; KEVWire does not scan your systems.

A personal reading checklist on this device, not verified remediation.

Record JSON

Your account

Email alerts

Email alerts are coming as part of KEVWire Premium: join the waitlist. To follow your stack today, use its RSS feed, which honors your filters, or connect an AI agent through the API.

Suggest an improvement

Ideas, missing sources, corrections, and bugs are all welcome. No account needed. Suggestions are reviewed by a person before anything changes.

Record details

Record detail