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?
Affected package
- Affected
- <1.4.1
- Fixed in
- 1.4.1
npm install node-forge@1.4.1Details
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
References
Advisory data from OSV.dev (opens OSV.dev in a new tab), refreshed daily.