Forge: X.509 pathLenConstraint not enforced by verifyCertificateChain() for CA certificates without keyUsageGHSA-h46v-rmh6-fq4f
MEDIUMFix: digitalbazaar/forge@696db92GHSA-h46v-rmh6-fq4f is a medium-severity (CVSS 5.9) CWE-295 vulnerability in node-forge. A fix is available for node-forge — see the affected versions and patch details below.
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
Exploitation and automatability from CISA’s SSVC triage for GHSA-h46v-rmh6-fq4f.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
Where this sits among everything scored
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.
node-forgenpmDescription
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.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | node-forge | all versions | 1.4.1npm install node-forge@1.4.1 |
Affected Products
forgedigitalbazaarDetection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for node-forge, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update node-forge to 1.4.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-h46v-rmh6-fq4f is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
Frequently Asked Questions
Is GHSA-h46v-rmh6-fq4f in your dependencies?
Find it across npm, including transitive dependencies.