node-forge EUVD-2026-113366

Requires all of the following per the advisory: an application using node-forge <=1.4.0 that calls forge.pki.verifyCertificateChain() (including TLS peer verification via forge.tls); a CA certificate carrying basicConstraints with a pathLenConstraint and NO keyUsage extension that chains to a root the application trusts; and an attacker who either holds that CA's private key or has obtained a subordinate CA certificate issued by it, enabling creation of further sub-CAs. Key LIMITING factors: public web PKI CA certificates normally include keyUsage and are therefore not affected - only private PKIs whose CA certificates were created without keyUsage are exposed; the attacker must already possess trusted CA signing capability, which bounds who can exploit this. Documented workarounds are an options.verify/verify callback that rejects a CA at depth d whose pathLenConstraint < d-1, or re-issuing the constrained CA with a keyUsage extension including keyCertSign; node-forge itself offers no workaround and the complete fix is upgrading to 1.4.1.

This is a moderate, highly conditional trust-boundary flaw rather than a broadly exploitable emergency. The CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N, 5.9) correctly captures the shape: network-reachable and requiring no privileges on the verifying application, but with high attack complexity and impact limited to integrity (C:N/A:N) - the flaw lets a certificate chain exceeding its declared pathLenConstraint pass pki.verifyCertificateChain(). The AC:H reflects the substantial precondition stated in the advisory: the attacker must hold the private key of a path-length-constrained CA that lacks a keyUsage extension and chains to a root the application trusts, or obtain a subordinate CA certificate from it. The vendor also published an informational CVSS 4.0 vector (8.2) that scores higher because 4.0 reweights the attack preconditions as AT:P with AC:L; the advisory explicitly states the severity rating follows the 3.1 score of Moderate. No EPSS score was provided in the input, so exploitation-probability cannot be compared against the other signals - this gap should be noted rather than assumed low. This vulnerability is NOT in CISA KEV and there is no indication of active exploitation; a proof-of-concept is public (see exploit scenario). The vuln.today priority is 'this_month', consistent with a real but non-emergency issue. Net: prioritize patching for anyone operating a private PKI whose CA certificates were minted without keyUsage, but realistic widespread exploitation is constrained by the requirement that the attacker already control a trusted, suitably-malformed CA.

In an organization running a private PKI, an intermediate CA was issued with basicConstraints pathLenConstraint=0 but no keyUsage extension and chains to a root trusted by an application that uses node-forge (<=1.4.0) for chain or TLS peer verification. An attacker holding that intermediate's key - or one issued a subordinate CA certificate by it - mints an unauthorized sub-CA and then a leaf certificate for an identity they do not control (e.g. evil.example.com), and node-forge accepts the full chain despite the pathLen=0 violation. A working proof-of-concept is public: it is published in the GHSA-h46v-rmh6-fq4f advisory and committed to the fix as a regression test (tests/pocs/ghsa-h46v-rmh6-fq4f.js), so it is demonstration code rather than verified weaponized tooling.