MediumGHSA-h46v-rmh6-fq4fCVE-2026-119189

Forge: X.509 pathLenConstraint not enforced by verifyCertificateChain() for CA certificates without keyUsage

Published 10 Nov 2026 · Updated 10 Nov 2026

Is your project on an affected node-forge?

Private repo? Upload its lockfile instead, or connect GitHub to check every repo.

Affected package

Affected
<1.4.1
Fixed in
1.4.1
Update to the fixed version for your release line, for example:npm install node-forge@1.4.1

Details

Summary

forge.pki.verifyCertificateChain() enforces the pathLenConstraint of a CA certificate's basicConstraints extension only when that certificate also has a keyUsage extension. For a CA certificate with a pathLenConstraint and no keyUsage, chains with more intermediate CA certificates below it than the constraint allows are accepted. Fixed in node-forge 1.4.1.

Details

In pki.verifyCertificateChain() (lib/x509.js), the path length check for a CA certificate was guarded by keyUsageExt !== null && 'pathLenConstraint' in bcExt. The keyUsage test was originally a proxy for "a basicConstraints extension exists". Since node-forge 1.4.0 (GHSA-2328-f5f3-gj25), basicConstraints is required for every certificate that reaches this check, so the only remaining effect of the guard is to skip pathLenConstraint enforcement for CA certificates without keyUsage.

RFC 5280 permits CA certificates without keyUsage, and path length processing in section 6.1.4 (l)-(m) does not depend on keyUsage; section 4.2.1.9 defines pathLenConstraint as part of basicConstraints only. For example, with a trusted root, an intermediate CA with pathLenConstraint=0 and no keyUsage, a sub-CA issued by that intermediate, and a leaf issued by the sub-CA, node-forge accepts the chain. It correctly rejects the same chain when the intermediate has keyUsage.

The fix checks pathLenConstraint whenever the basicConstraints extension is present, regardless of keyUsage (based on PR #1142).

Patches

Fixed in node-forge 1.4.1. pathLenConstraint is now enforced for CA certificates without a keyUsage extension.

Workarounds

None in node-forge itself. Applications that pass an options.verify callback to pki.verifyCertificateChain() (or verify to forge.tls.createConnection()) can reject chains in which a CA certificate at depth d has basicConstraints.pathLenConstraint < d - 1. Re-issuing constrained CA certificates with a keyUsage extension that includes keyCertSign also restores enforcement.

References

  • RFC 5280, sections 4.2.1.9 and 6.1.4: https://www.rfc-editor.org/rfc/rfc5280#section-6.1.4
  • Related: GHSA-2328-f5f3-gj25 / CVE-2026-33896 (basicConstraints bypass, fixed in 1.4.0)
  • https://github.com/digitalbazaar/forge/pull/1142

Severity

CVSS 3.1: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N (5.9, Moderate) CVSS 4.0 (informational): CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N (8.2) CVSS 4.0 weights the attack preconditions differently and scores this higher; the severity rating follows CVSS 3.1.

Credits

@offset, @eddieran, also reported independently by Zion Boggan (@zionboggan) and @EchoSkorJjj.

Proof of concept

Build the chain root <- int <- subCA <- leaf, where int has basicConstraints cA=true, pathLenConstraint=0 and no keyUsage, subCA is a CA certificate issued by int, and leaf is issued by subCA:

var caStore = forge.pki.createCaStore([root]);
forge.pki.verifyCertificateChain(caStore, [leaf, subCA, int]);
// <= 1.4.0: true (pathLenConstraint=0 ignored)
// 1.4.1: throws "Certificate basicConstraints pathLenConstraint violated."

The same chain is rejected on <= 1.4.0 when int also has a keyUsage extension with keyCertSign. The fix adds regression tests in tests/unit/x509.js and the reporter's PoC as tests/pocs/ghsa-h46v-rmh6-fq4f.js.

Impact

Applications that verify certificate chains with forge.pki.verifyCertificateChain(), including TLS peer certificate verification in forge.tls, are affected when a CA they trust (directly or through a chain) has a pathLenConstraint and no keyUsage extension.

Exploitation requires such a path-length-constrained CA certificate that chains to a root the application trusts. The attacker must either hold that CA's private key or obtain a CA certificate from it. That CA can then create subordinate CAs, and certificates issued by those subordinate CAs are accepted by pki.verifyCertificateChain(). Public web PKI CA certificates normally include keyUsage. Private PKIs whose CA certificates were created without keyUsage are most likely to be affected.

Is GHSA-h46v-rmh6-fq4f in any of your client repos?

Checking one package by hand is fine. Checking it across forty client projects is not. NPMscan reads the lockfiles in every GitHub repo you pick, finds each project with an affected node-forge, and gives you the command that fixes it.

More advisories for node-forge

  • LowCVE-2026-125335Forge: Ed25519 signature verification accepts small-order public keys · 10 Nov 2026
  • MediumCVE-2026-125332Forge: TLS client crash on an unsupported ServerHello compression method · 10 Nov 2026
  • MediumCVE-2026-125333Forge: ReDoS in forge.http response header and cookie trimming · 10 Nov 2026
  • MediumCVE-2026-125334Forge: TLS client crash on a handshake record received without a session · 10 Nov 2026
  • LowCVE-2026-118774Forge: Certificate signature verified with the issuer's RSA signature scheme · 10 Nov 2026
  • LowCVE-2026-118776Forge: Incomplete PKCS#7 padding validation in AES/DES CBC and ECB decryption · 10 Nov 2026
All 36 advisories for node-forge

References

Advisory data from OSV.dev (opens OSV.dev in a new tab), refreshed daily.