Modification of Assumed-Immutable Data (MAID) Affecting node-forge package, versions <1.4.1
Threat Intelligence
Snyk has a proof-of-concept or detailed explanation of how to exploit this vulnerability.
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
Do your applications use this vulnerable package?
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applications- Snyk IDSNYK-JS-NODEFORGE-22113962
- published1 Nov 2026
- disclosed30 Oct 2026
- creditPanneerselvam
Introduced: 30 Oct 2026
NewCVE-2026-118780 (opens in a new tab)How to fix?
Upgrade node-forge to version 1.4.1 or higher.
Overview
node-forge is a JavaScript implementations of network transports, cryptography, ciphers, PKI, message digests, and various utilities.
Affected versions of this package are vulnerable to Modification of Assumed-Immutable Data (MAID) in the pki.verifyCertificateChain function in lib/x509.js. An attacker can permanently disable verification against an affected trusted CA by presenting a certificate whose issuer name matches a subject shared by two or more CAs in the store, because the function calls parents.shift() on the live array returned by caStore.getIssuer() (the store's internal caStore.certs[hash]), removing every candidate CA it examines, including the one that ultimately verifies the chain. Exploitation requires a long-lived CA store that holds two or more certificates with the same subject name and is reused across verifications, such as a forge.tls client sharing one caStore object across connections, a condition that mostly arises in private PKIs with re-keyed or renewed CAs that kept their name. The failure mode is availability only: subsequent valid chains under the drained CA are rejected, verification against other trusted CAs continues to work, and no invalid chain is ever accepted.
Workaround
This vulnerability can be avoided by using a fresh CA store for each verifyCertificateChain() call, or by passing the trusted certificates to forge.tls.createConnection() as an array rather than sharing a single long-lived caStore object across connections.