
Loading

Loading
We use strictly necessary cookies to run this site, and analytics cookies to understand how it's used. See our Privacy Policy for details.
A GitHub-reviewed security advisory, not necessarily under active exploitation the way our CISA KEV advisories are, but a real, disclosed vulnerability in an open-source dependency.
Affected packages
Vulnerable: <= 1.4.0
Patched in 1.4.1
Details
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.
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).
Fixed in node-forge 1.4.1. pathLenConstraint is now enforced for CA certificates without a keyUsage extension.
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.
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.
@offset, @eddieran, also reported independently by Zion Boggan (@zionboggan) and @EchoSkorJjj.
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.
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.
EPSS, exploit probability
Low0.17%
estimated chance of real-world exploitation in the next 30 days, higher than 5.8% of every CVE FIRST.org scores
Refreshed 11/10/2026, via FIRST.org's EPSS model, not CVSS, this measures likelihood of exploitation, not how severe it would be.
More npm advisories
Talk to us about this
Find out whether this dependency (or others like it) is actually reachable in your codebase.
Get help patching, or building dependency-scanning into your pipeline going forward.
A secure code review or supply chain review finds this before an advisory does.