Node-Forge's October 2026 Vulnerability Explained: When a Leaf Acts as a CA

Your code can trust a server or device that nobody authorised. That is the core of the node forge vulnerability fixed on 27 October 2026. A certificate that was only allowed to prove one identity could be treated as a signing authority.

A certificate is a signed file that ties a public key to a name, like a server name or a device ID. Some certificates may sign other certificates. Most may not, and one field says which kind it is.

Picture a common setup. A company runs a fleet of smart meters that connect to a Node.js gateway. Its own certificate service signs each meter's certificate, and the gateway checks every meter's chain with node-forge. The setup is made up, but the bug is real.

If one meter's certificate is wrongly treated as a signer, its owner could mint certificates for any other meter, and the gateway would accept them. That needs the certificate service to have copied a bad extension and added no keyUsage, as explained below. The second bug hits the same platform if it accepts password-protected key bundles from outside, such as from installers in the field.

Six terms carry the rest of the guide. Each keeps this name from here on, starting with the advisory summary below.

• Certificate authority (CA): a certificate allowed to sign other certificates. Your gateway trusts one or more CAs.
• Leaf certificate: the certificate at the bottom, for one server or one meter. It must not sign others.
• Chain: the list from the leaf up to a trusted CA. Each certificate is signed by the one above it.
• Extension: an extra labelled field inside a certificate. Each extension is labelled by an OID, a dotted number such as 2.5.29.19.
• basicConstraints: the extension with OID 2.5.29.19. Its cA flag says TRUE (may sign certificates) or FALSE. Its optional pathLenConstraint limits how many intermediate CAs may sit below it in a chain.
• Certificate signing request (CSR): the form a meter sends to ask a CA for a certificate. It can ask for extensions too.

It is a batch of security advisories against node-forge 1.4.0 and earlier, all fixed in 1.4.1. node-forge is a pure-JavaScript toolkit for TLS, certificates, keys and ciphers. Its certificate, TLS and PKCS#12 code is written in JavaScript rather than handed to OpenSSL, the C library behind Node.js's own crypto.

Each advisory has two IDs. A GHSA ID is GitHub's advisory number, and a CVE ID is the shared public number. Severity is a CVSS score out of 10; 7.0 to 8.9 is rated High.

Two of the High bugs published on 27 October break trust, which is why this guide focuses on them. Three more let an attacker crash or freeze a process. A separate High report from September, about RSA signatures, also clears with 1.4.1; engineers get the full list later.

A verifier walks up the chain and checks two things at each step. The signature must come from the certificate above, and that certificate must be a CA. RFC 5280, the internet standard for certificates, sets both rules.

RFC 5280 says that if basicConstraints is missing, or present without cA set, the key must not be used to verify certificate signatures. So a leaf with cA FALSE can sign nothing that a correct verifier accepts.

A picture for the CA check

Think of an office building where every staff badge has one printed line, May issue visitor passes, marked yes or no. The guard at the gate reads that line before honouring a pass a staff member wrote.

In the old badge design, the same line had a different form number. The guard was told to read the first line with that wording, whatever its form number. A badge with an old-form "yes" printed above the current "no" got waved through.

Mapped back: the badge is the certificate, the printed line is basicConstraints, the form number is the OID and the guard is verifyCertificateChain().

Where the picture breaks: nobody can print on a badge themselves. A certificate is signed, so the extra line only appears if a trusted CA puts it there. That is why the attack needs a trusted CA to include it, typically one that copies extensions from requests.

node-forge mapped three OIDs to the one name basicConstraints, and its chain check asked for that name. Its lookup function returns the first extension with a matching name, so the first of the three won.

We read this in the 1.4.0 and 1.4.1 tarballs from npm. In lib/oids.js, OIDs 2.5.29.10 and 2.5.29.13 carry the comment "deprecated use .19" but the same name. In lib/x509.js, any extension with that name gets its cA flag decoded.

Pause and predict: a certificate has an old-OID basicConstraints saying cA TRUE, followed by the real one saying cA FALSE. Which one does a first-match lookup return?

The old one, because it comes first. The advisory confirms that such a certificate was accepted as a CA. It also says a certificate with only the old-OID extension was accepted, and the same trick could hide a pathLenConstraint.

What just happened? The data was never ambiguous: every extension carries its exact OID. The code threw that precision away by matching on a friendly name that three different OIDs shared.

Why the March 2026 fix did not close it

In March 2026, GHSA-2328-f5f3-gj25 (CVE-2026-33896, fixed in 1.4.0) showed that an issuer with neither basicConstraints nor keyUsage was accepted as a CA. Version 1.4.0 added a check that rejects an issuer when basicConstraints is missing.

That new check still found the extension by name. The October advisory, titled a basicConstraints bypass, cites GHSA-2328 directly: an old-OID extension on its own satisfies the presence check added for it. The 1.3.3 to 1.4.1 diffs show the same.

Who could actually pull this off

The advisory rates attack complexity High for a reason. Someone must get a certificate signed by a CA you trust that contains the old-OID extension. The advisory's example is a CA that copies extensions from certificate signing requests, such as openssl x509 -req run with -copy_extensions copy.

The advisory also gives a limit. If the CA puts a keyUsage extension without keyCertSign on the certificate, node-forge rejects the chain anyway. We confirmed this in 1.4.0's lib/x509.js, where a keyUsage without keyCertSign fails before cA is read.

In our smart meter setup, the exposure is the internal certificate service, if it copies requested extensions and issues meter certificates with no keyUsage.

Run npm ls node-forge in the project folder. It prints every copy in your dependency tree, with its version and the package that pulled it in. Any version 1.4.0 or lower is affected.

Most apps never install node-forge by hand. It arrives as a transitive dependency, a package another package pulls in. For example, webpack-dev-server 5.2.2 depends on selfsigned ^2.4.1, which depends on node-forge ^1.

$ npm ls node-forge
[email protected] /app
`-- [email protected]
  `-- [email protected]

This output means the project is affected, because 1.4.0 is in the affected range. npm explain node-forge shows the same chain with the version range each parent asked for.

npm audit checks the tree against the GitHub Advisory Database. On a project locked to node-forge 1.4.0 on 1 November 2026, it listed 12 node-forge advisories. On 1.4.1 and 1.4.2 it printed found 0 vulnerabilities.

Exposure also depends on which functions run. The chain bug needs pki.verifyCertificateChain() or forge's own TLS client or server. Node's built-in tls and https modules are built on OpenSSL, so they do not run this code.

We read selfsigned 2.4.1's index.js: it calls verifyCertificateChain() only on the certificate it has just generated. A dev server using it has low exposure, but upgrade anyway, because scanners will keep flagging it.

Move every copy to 1.4.2, then confirm with npm ls and npm audit. We ran every command below on 1 November 2026 with Node.js 22.23.4 and npm 10.9.9.

1. 1

   Find every copy

   Run npm ls node-forge. Write down each version and the package above it.

2. 2

   Direct dependency

   If node-forge sits in your own package.json, run npm install [email protected].

3. 3

   Transitive dependency

   Run npm update node-forge. The parents we checked, selfsigned 2.4.1 and @expo/cli 58.1.18, ask for ^1 and ^1.4.0, which allow 1.4.2.

4. 4

   Check the lockfile moved

   Run npm ls node-forge again. In our test, a plain npm install kept the locked 1.4.0; npm update node-forge moved it to 1.4.2.

5. 5

   Run the audit

   Run npm audit. Expect no node-forge entries; on our test project it printed found 0 vulnerabilities.

6. 6

   Check the running build

   Inside the image you deploy, run npm ls node-forge again. Every copy should show 1.4.2, including nested ones.

7. 7

   Run your own checks

   Run the tests that verify chains and open bundles. Normal chains and normal bundles behaved the same on 1.4.0 and 1.4.2 in our checks.

If a parent pins an exact old version, update that parent. Only if that is impossible, add an npm override for node-forge in package.json, and remove it once the parent catches up.

$ npm update node-forge
$ npm ls node-forge
[email protected] /app
`-- [email protected]
  `-- [email protected]
$ npm audit
found 0 vulnerabilities

We ran this on a test project that pulled node-forge in through selfsigned 2.4.1, with the lockfile first held at 1.4.0. We renamed the project in the output to match the example.

Because with zero rounds, or a negative or empty count, the password is never hashed, so the key that checks the file does not depend on the password. Anyone can compute that key and stamp a valid-looking check on any contents.

A PKCS#12 file, also called a .p12 or PFX file, bundles a private key and its certificates under a password. It carries a MAC, a short code that proves the contents were not changed by someone without the password. node-forge checks it with HMAC, a MAC built from a hash function.

The MAC key comes from a key derivation function, or KDF. It mixes the password with a salt, random bytes stored in the file, and hashes the result again and again. The number of rounds is the iteration count, also stored in the file.

RFC 7292, the PKCS#12 standard, calls this count r and says the salt and iteration count slow down password-guessing attacks. More rounds make each guess cost more. node-forge writes 2048 rounds by default when it creates a file.

What the source shows

In 1.4.0's lib/pbe.js, generatePkcs12Key() hashes its input inside a loop that runs iter times. With iter 0, the loop never runs. The output then starts with a fixed block made from the key-purpose number, not from the password.

We read this in the source only; we did not run 1.4.0 with a zero count. The advisory states the result: a constant key, so a MAC computed with it verifies under any password.

The same function derives the decryption key for two old PKCS#12 ciphers, pbeWithSHAAnd3-KeyTripleDES-CBC and pbewithSHAAnd40BitRC2-CBC. Keys encrypted with PBES2, which uses PBKDF2, are not affected, per the advisory.

What the fix changed and what it does not mean

1.4.1 adds two guards that reject a count below 1. lib/pkcs12.js checks the MAC count before deriving the key. lib/pbe.js checks inside the KDF itself, so the old ciphers are covered too.

We called the KDF with a count of 0 on 1.4.1 and 1.4.2. Both threw the error PKCS#12 key derivation iteration count must be >= 1, word for word.

The attacker does not learn your password or your real private key. The advisory's risk is different: your app accepts attacker-chosen certificates and keys as if a trusted admin had uploaded them.

It fixed a regression in 1.4.1: PEM functions crashed when given a Buffer instead of a string. A Buffer is Node.js's type for raw bytes, which is what fs.readFileSync() returns without an encoding.

We compared the 1.4.1 and 1.4.2 tarballs. The only source change is one statement in lib/pem.js, plus the rebuilt browser bundles and the version number. pem.decode() now starts with str = String(str).

The cause sits in 1.4.1's ReDoS fix. ReDoS, regular expression denial of service, means input that makes a pattern match run for a very long time. 1.4.1 replaced the PEM regex with a hand-written scanner that calls string methods such as charAt.

A regex quietly turns a Buffer into a string; charAt does not exist on a Buffer. We passed a normal CA certificate as a Buffer to each version, and the results are below.

node-forge 1.4.0  certificateFromPem(Buffer): ok
node-forge 1.4.1  certificateFromPem(Buffer) threw: TypeError: str.charAt is not a function
node-forge 1.4.2  certificateFromPem(Buffer): ok

So pin 1.4.2, not 1.4.1. If you must stay on 1.4.1 for now, pass strings: read PEM files with fs.readFileSync(path, 'utf8').

Three more High advisories, all denial of service, and several Moderate and Low ones. Every advisory below lists 1.4.0 and earlier as affected; npm audit clears all of them on 1.4.1, as of 1 November 2026.

For the two TLS crash bugs, the advisories' stopgap is to wrap every call to connection.process() in try/catch, then drop the connection. The attacked connection is still lost; only the process survives. For PEM, reject untrusted input above a few kilobytes; the advisory says this only limits the delay.

npm audit also lists GHSA-86w9-cpqp-85rv as High, 7.5, against 1.4.0 and earlier (its GitHub page shows a CVSS v4 score of 8.7 and affected versions as Unknown). Published in September 2026, it reports forged RSA PKCS#1 v1.5 signatures when keys use a low public exponent.

That is a trust bug, not a crash. Its GitHub page was still unreviewed on 1 November 2026 and names no fixed version. 1.4.1 adds a strict DigestInfo check in lib/rsa.js, and npm audit clears the report on 1.4.1.

Two quieter changes in the chain check

The 1.4.1 diff of lib/x509.js has two more changes worth knowing. pathLenConstraint is now enforced whenever basicConstraints is present; before, it was checked only when keyUsage was also present.

Signature checks now take the padding scheme from the child certificate's signature algorithm, not the parent's. We found no advisory tied to that line as of 1 November 2026.

The source comments in 1.4.2 still list revocation and name constraints as TODO in verifyCertificateChain(). If you need those checks, node-forge does not do them for you.

Add a verify callback that demands the real basicConstraints on every issuer, and fix your CA if it copies extensions. The advisory suggests both.

verifyCertificateChain() accepts a verify option, a function called once for each certificate in the chain you pass, with its depth. An issuer found only in the CA store is not passed to it. Depth 0 is the leaf. This callback rejects any issuer that lacks OID 2.5.29.19 with cA TRUE.

function requireRealBasicConstraints(vfd, depth, certs) {
  if (vfd !== true) return vfd;            // keep forge's own verdict
  if (depth > 0) {                         // every issuer in the presented chain
    const bc = certs[depth].getExtension({ id: '2.5.29.19' });
    if (!bc || !bc.cA) {
      return { message: 'Issuer lacks basicConstraints 2.5.29.19 with cA TRUE.' };
    }
  }
  return true;
}

forge.pki.verifyCertificateChain(caStore, chain, { verify: requireRealBasicConstraints });

We ran it on 1.4.0 and 1.4.2 with normal chains only. A leaf plus intermediate, with and without the root, returned true. A leaf without its intermediate was still rejected with Certificate is not trusted.

We did not build a malicious certificate to test the rejection path. Treat this as a stopgap and keep the upgrade on your list. forge.tls.createConnection() takes a similar verify option, with the connection added as the first argument.

Fix the certificate authority side

If you run a private CA, do not copy unrecognised extensions from CSRs. Build each certificate from a fixed profile and set basicConstraints yourself.

To audit certificates you already issued, list each one's extension OIDs and look for 2.5.29.10 or 2.5.29.13. This script does that with node-forge for every certificate in a PEM file.

const forge = require('node-forge');
const fs = require('fs');
const pem = fs.readFileSync(process.argv[2], 'utf8');
for (const msg of forge.pem.decode(pem)) {
  if (msg.type !== 'CERTIFICATE') continue;
  const cert = forge.pki.certificateFromAsn1(forge.asn1.fromDer(msg.body));
  const ids = cert.extensions.map(e => e.id);
  const old = ids.filter(id => id === '2.5.29.10' || id === '2.5.29.13');
  const cn = (cert.subject.getField('CN') || {}).value || '(no CN)';
  console.log(cn, '|', ids.join(' '), '|', old.length ? 'DEPRECATED basicConstraints OID' : 'ok');
}

Run it as node ext_audit.js issued.pem. On our normal test CA it printed Test Root CA | 2.5.29.19 2.5.29.15 | ok. Any line that says DEPRECATED needs a closer look.

For PKCS#12, the advisory's stopgap is to check the MAC iteration count before calling pkcs12FromAsn1() and refuse anything below 1. Upgrading is simpler than writing that parser check yourself.

Match security fields by their exact identifier, and reject impossible parameters at the door. Both headline bugs come from code that was friendlier than the data it read.

• Names are for people, IDs are for checks. Three OIDs shared one name, and a security check used the name. Look up the exact OID, or reject duplicates.
• Input-controlled cost settings need floors. An iteration count or a tag length taken from a file or a message must have a minimum, or an attacker sets it to zero.
• A fix can leave a gap in the same check. The March fix added a presence test but kept the loose lookup. When you review a security fix, ask what else could satisfy the new test.
• Read the diff of security releases. The release notes said only "Release 1.4.1." The diff showed the fixes, and the next diff showed the Buffer regression.

Frame it as a trust-check bug in a shared library, then give the fix at three levels: code, dependencies and operations. The steps below take about two minutes to say.

1. 1

   State the impact

   A certificate that should only identify one device could act as a CA in node-forge 1.4.0 and earlier. With a CA that copies CSR extensions and adds no keyUsage, an attacker could impersonate any device.

2. 2

   Name the root cause

   The chain check found basicConstraints by name and took the first match. Two retired OIDs shared that name.

3. 3

   Give the code fix

   Look up OID 2.5.29.19 only. That is the change in node-forge 1.4.1.

4. 4

   Give the dependency fix

   Find every copy with npm ls, update to 1.4.2, and confirm with npm audit and npm ls node-forge inside the deployed image.

5. 5

   Give the operations fix

   Build certificates from fixed profiles on your CA, audit issued certificates for odd OIDs, and alert on new advisories for crypto libraries.

6. 6

   Mention the second bug

   PKCS#12 files with zero or fewer iterations passed the password check. Read cost parameters from untrusted input only with a lower bound.