KEVWire

Security intelligence, with context.

Response snapshot Oct 31, 2026, 01:26 UTC

Back to the wire
Permalink
VulnerabilityCVE-2026-118780

Forge: verifyCertificateChain() removes trusted CA certificates with the same subject from the CA store

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.

At a glance

Exploited
Not known
Severity
3.7 Low (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-4487-j8r4-4g2f (opens a new tab)

What happened

Summary

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.

Continue reading

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.

Patches

Fixed in node-forge 1.4.1. pki.verifyCertificateChain() now works on a copy of the candidate issuer list instead of shifting entries out of the CA store.

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

Impact

Applications that keep a long-lived CA store holding several trusted certificates with the same subject name, and that verify certificate chains received from other parties with pki.verifyCertificateChain(). This includes forge.tls clients that pass the same caStore object to several connections. Duplicate subject names occur with re-keyed or renewed CAs that kept their name, or a CA next to a cross-signed version of itself, mostly in private PKIs.

A remote, unauthenticated peer (for example a malicious TLS server or a party submitting a signed document) can send a certificate naming the shared subject as its issuer. This removes every certificate with that subject from the store, so later verifications of valid chains issued by those CA certificates fail until the store is recreated.

This is a persistent denial of service for certificate verification against those CA certificates. Verification against other trusted CAs keeps working, no invalid chain is accepted, and stores without duplicate subject names are not affected.

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

Scores and how they were measured

CVSS base severity

3.7

Version 3.1As of

CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/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-4487-j8r4-4g2f (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-4487-j8r4-4g2f, 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: verifyCertificateChain() removes trusted CA certificates with the same subject from the CA store (CVE-2026-118780). https://kevwire.com/record/CVE-2026-118780

MLA

"Forge: verifyCertificateChain() removes trusted CA certificates with the same subject from the CA store (CVE-2026-118780)." KEVWire, 30 Oct. 2026, kevwire.com/record/CVE-2026-118780.

Chicago

KEVWire. "Forge: verifyCertificateChain() removes trusted CA certificates with the same subject from the CA store (CVE-2026-118780)." Last modified October 30, 2026. https://kevwire.com/record/CVE-2026-118780.

Evidence summary (plain text)

Forge: verifyCertificateChain() removes trusted CA certificates with the same subject from the CA store (Oct 30, 2026).
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.

pki.verifyCertificateChain() (lib/x509.js) asks the CA store for the issuer of each certificate with caStore.getIssuer().
CVSS 3.7 (version 3.1; evidence as of Oct 30, 2026; https://github.com/advisories/GHSA-4487-j8r4-4g2f).
Sources:
GitHub-reviewed advisory GHSA-4487-j8r4-4g2f: https://github.com/advisories/GHSA-4487-j8r4-4g2f
GitHub public advisory API page: https://api.github.com/advisories?type=reviewed&per_page=100&sort=updated&direction=desc
Record ID: CVE-2026-118780.
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