GHSA-h46v-rmh6-fq4f

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.