GHSA-h46v-rmh6-fq4f

Dashboard / Vulnerabilities / GHSA-h46v-rmh6-fq4f

GHSA-h46v-rmh6-fq4f

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

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`: ```js 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.

References: https://github.com/digitalbazaar/forge/security/advisories/GHSA-h46v-rmh6-fq4f, https://nvd.nist.gov/vuln/detail/CVE-2026-119189, https://github.com/digitalbazaar/forge/commit/696db92348623e88cc63c35f0a89ede481d55ad0, https://github.com/digitalbazaar/forge, https://github.com/digitalbazaar/forge/releases/tag/v1.4.1