Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessConnect as malicious remote peer
-
DeliveryPresent certificate naming shared CA subject as issuer
-
ExploitverifyCertificateChain shifts same-subject certs out of CA store
-
ExecutionTrusted CA certificates removed from reused store
-
ImpactLater valid chains rejected (persistent verification DoS)
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A07:2025 - Authentication Failures
ASVS 5.0
V12 - Secure Communication Certificate validation
|
| Exploitation Conditions | Requires an application that creates a CA store with pki.createCaStore() containing two or more trusted certificates sharing the SAME subject name (e.g. re-keyed/renewed CAs that kept their name, or a CA alongside a cross-signed version of itself - chiefly private PKIs), AND that reuses that same long-lived store object across multiple pki.verifyCertificateChain() calls (including forge.tls clients passing the same caStore to several connections). A remote, unauthenticated peer then sends any certificate whose issuer field equals the shared subject name; its signature/key can be arbitrary. LIMITING FACTORS: stores WITHOUT duplicate subject names are not affected at all; a fresh store per call (or passing an array of certificates so forge builds a new store per connection) avoids the issue; no invalid chain is ever accepted (integrity is not compromised); impact is confined to availability of verification against those specific CA certificates and persists only until the store is recreated. |
| Impact | All severity signals point to a low real-world priority. The CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L = 3.7, Low) shows a network-reachable, unauthenticated flaw with no confidentiality or integrity impact and only a limited availability impact, and high attack complexity reflecting the non-default precondition (a reused CA store holding duplicate-subject certificates). The vuln.today decision label is 'monitor,' consistent with a Low rating. No CISA KEV listing is present and no EPSS score was supplied, so exploitation-probability data is MISSING and cannot be weighed. The GHSA advisory publishes an illustrative proof-of-concept, but the input does not flag it as confirmed working exploit code. One genuine tension exists: the advisory's informational CVSS 4.0 vector (AV:N/AC:L/AT:P/.../VA:L = 6.3, Moderate) rates this higher because 4.0 weights the attack precondition (AT:P) differently than 3.1 weights AC:H - the vendor explicitly keeps the 3.1 Low rating, and this analysis follows that. Net: a real but narrow, condition-dependent denial-of-service of certificate verification, not an emergency; patch on a normal maintenance cycle. |
| Exploit ScenarioDerived | An application reuses a long-lived node-forge CA store (via pki.createCaStore()) that holds two or more trusted CA certificates sharing the same subject name - typical of re-keyed/renewed or cross-signed CAs in private PKIs. A malicious TLS server, or a party submitting a signed document, presents a certificate naming that shared subject as its issuer; verification correctly fails but permanently shifts those CA certificates out of the store, so every later valid chain from those CAs is rejected until the store is recreated. A conceptual PoC demonstrating this is published in the GHSA advisory, though it is not verified as standalone working exploit code. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 29, 2026
Certificate chain verification in node-forge (Forge) before 1.4.1 can permanently delete trusted CA certificates from a reused pki.createCaStore() store when two or more of those certificates share a subject name, so a remote peer that sends any certificate naming that shared subject as its issuer can cause every later validation against those CAs to fail until the store is recreated. Only applications that keep one long-lived store containing duplicate-subject CA certificates and reuse it across pki.verifyCertificateChain() calls are exposed - chiefly private PKIs with re-keyed, renewed or cross-signed roots - and no invalid chain is ever accepted, so this is a persistent availability impact confined to those specific CAs. The flaw is fixed in 1.4.1, a public proof-of-concept is included in the vendor advisory, and the vendor rates it Low (CVSS 3.1: 3.7); there is no confirmation of active exploitation and the priority signal is monitor.
RemediationAI
Upgrade node-forge to version 1.4.1 (for example npm install node-forge@1.4.1), which is the vendor-released fix that makes pki.verifyCertificateChain() operate on a copy of the candidate issuer list instead of shifting entries out of the CA store; see the advisory at https://github.com/digitalbazaar/forge/security/advisories/GHSA-4487-j8r4-4g2f, the fix commit f6555609bd30f442fbfacd543155928ceccf98d0 and the release at https://github.com/digitalbazaar/forge/releases/tag/v1.4.1. If upgrading cannot be done immediately, the vendor documents two workarounds: pass a fresh CA store to each verification call (for example pki.createCaStore(trustedCerts)) or pass caStore to forge.tls.createConnection() as an array of certificates so forge builds a new store per connection - at the cost of re-creating store state on every call and losing any certificates added dynamically to a long-lived store; alternatively wrap the store so getIssuer() returns a copy (var getIssuer = caStore.getIssuer; caStore.getIssuer = function(cert) { var r = getIssuer(cert); return Array.isArray(r) ? r.slice() : r; }), which must be applied to every store instance created and can be bypassed by code that reads caStore.certs directly. Applications that do not hold duplicate-subject certificates in a reused store are unaffected and need no compensating control beyond the upgrade.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 2 packages in npm, euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
node-forge is a pure JavaScript implementation of TLS and PKI primitives (X.509, CMS, PKCS#1/7/12, TLS) used in Node.js and browser applications. pki.createCaStore() indexes trusted certificates by a hash of their subject name, storing an array of certificates under caStore.certs[hash]; getIssuer() returned that internal array directly to pki.verifyCertificateChain() in lib/x509.js, which then used it as the candidate parent list and called parents.shift() while trying each candidate. Because the array was the store's own data, every candidate tried - including the certificate that successfully validated the chain - was removed from the store; once empty, getIssuer() returned nothing, no candidate was tried, and verification failed with 'Certificate signature is invalid.'. The root cause is improper certificate validation (CWE-295), with the advisory additionally citing CWE-471 (modification of assumed-immutable data): RFC 5280 Section 6.1.1(d) treats trust anchor information as an input to path validation that validation must not consume. The trigger requires a store holding at least two trusted certificates with the identical subject plus reuse of that store object across verifications; a peer certificate merely needs an issuer field equal to that public subject name, with arbitrary signature and key, since each candidate is tried and shifted out and errors from parent.verify() are caught by the loop. The fix in commit f6555609 copies the array returned by getIssuer() (parent.slice()) before iteration, leaving getIssuer() itself unchanged.
Know when Forge gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L
Remote unauthenticated peer (AV:N, PR:N, UI:N), but exploitation needs a reused store holding duplicate-subject CAs (AC:H); only verification availability is affected (A:L), no C/I impact.
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
Lifecycle Timeline
2DescriptionCVE.org
Forge (also called node-forge) is a native implementation of Transport Layer Security in JavaScript. Prior to 1.4.1, the affected implementation used pki.verifyCertificateChain(), pki.createCaStore(), duplicate subject names to process the relevant input or security decision. node-forge modified the CA store while trying certificates that shared a subject name during pki.verifyCertificateChain(). A failed chain verification could permanently remove trusted CA certificates from the store, causing later valid chains to fail and creating a persistent availability impact for applications that reused the store. This issue is fixed in version 1.4.1.
Blast Radius
ecosystem impact- 6 npm packages depend on node-forge (3 direct, 3 indirect)
Ecosystem-wide dependent count for version 1.4.1.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
An interpretation-conflict (CWE-436) vulnerability in node-forge versions 1.3.1 and earlier enables unauthenticated atta
The package node-forge before 0.10.0 is vulnerable to Prototype Pollution via the util.setPath function. Rated high seve
RSA PKCS#1 v1.5 signature forgery in node-forge through v1.4.0 enables unauthenticated network attackers to craft signat
Forge (also called `node-forge`) is a native implementation of Transport Layer Security in JavaScript. Rated high severi
Regular expression denial of service in node-forge's pem.decode() allows remote, unauthenticated attackers to block the
Denial of service in node-forge (Forge) 1.3.2 through 1.4.0 lets remote, unauthenticated attackers exhaust CPU time and
Denial of service in node-forge's JavaScript TLS implementation: a connection created with forge.tls.createConnection()
Call stack exhaustion in node-forge's TLS record processing (all versions through 1.4.0) allows a remote peer to crash o
PKCS#12 MAC forgery and constant-key password-based decryption in node-forge 1.4.0 and earlier let anyone who does not k
Forge (also called `node-forge`) is a native implementation of Transport Layer Security in JavaScript. Rated high severi
Forge (also called `node-forge`) is a native implementation of Transport Layer Security in JavaScript. Rated high severi
Certificate chain validation in node-forge (Forge) through version 1.4.0 can be bypassed because the parser maps the dep
EUVD-2026-113338
GHSA-4487-j8r4-4g2f
NVD
CVE.org
EPSS
Exploit-DB