CVE-2026-118780

When a CA store created by pki.createCaStore() holds two or more certificates with the same subject name, pki.verifyCertificateChain() permanently removes those certificates from the store while trying each one as the issuer. A peer can send any certificate that names that subject as its issuer to make all later verifications against those CA certificates fail. Fixed in node-forge 1.4.1.

Details

pki.verifyCertificateChain() (lib/x509.js) asks the CA store for the issuer of each certificate with caStore.getIssuer(). When the store holds several certificates with the same subject, caStore.getIssuer() returns the store's own internal array of those certificates (caStore.certs[hash], built by addCertificate()). verifyCertificateChain() used that array directly as its list of candidate parents and called parents.shift() on it while trying each candidate. Every candidate it tried, including the one that finally verified the certificate, was removed from the store.

Once the array is empty, getIssuer() returns an empty list, no candidate is tried, and verification fails with "Certificate signature is invalid." hasCertificate() and listAllCertificates() no longer see the removed certificates. The store stays in this state for as long as the object is used.

The attacker's certificate only needs an issuer name equal to the shared subject name, which is public. Its signature and key can be arbitrary: every candidate is tried and shifted out because none verifies, and errors from parent.verify() are caught by the loop. Verification of the attacker's chain fails as expected. Verifying valid chains has a similar effect: the CA certificate that verified the chain and any tried before it are removed.

No chain is accepted that should be rejected. Removing candidates can only turn a success into a failure.

RFC 5280, Section 6.1.1(d) treats trust anchor information as an input to path validation. Validation should not consume it.

The fix copies the array returned by getIssuer() before iterating over it, so the CA store is no longer modified. getIssuer() itself is unchanged.

Workarounds

• Pass a fresh CA store to each pki.verifyCertificateChain() call (for example pki.createCaStore(trustedCerts)), or pass caStore to forge.tls.createConnection() as an array of certificates instead of a store object, so that forge creates a new store per connection.

• Or wrap the store so that getIssuer() returns a copy:

  var getIssuer = caStore.getIssuer;
  caStore.getIssuer = function(cert) {
    var r = getIssuer(cert);
    return Array.isArray(r) ? r.slice() : r;
  };
  

Proof of concept

Two trusted self-signed CA certificates, rootA and rootB, share the subject CN=Root. bogus is any certificate whose issuer is CN=Root, signed with an unrelated key. leafA is a valid certificate issued by rootA.

var caStore = forge.pki.createCaStore([rootA, rootB]);
caStore.listAllCertificates().length;  // 2
try { forge.pki.verifyCertificateChain(caStore, [bogus]); } catch(e) {}
// rejected as expected ("Certificate signature is invalid.")
caStore.listAllCertificates().length;  // 0: both CA certificates are gone
forge.pki.verifyCertificateChain(caStore, [leafA]);
// throws "Certificate signature is invalid." (valid chain now rejected)

Without the attacker certificate, verifying leafA twice against a fresh store gives the same result: the first call succeeds and removes rootA, the second fails. With the fix, the store keeps both certificates and every valid chain verifies. The regression tests are in tests/unit/x509.js ("CA store" section).