node-forge EUVD-2026-113347

Exploitation requires that the victim application verify certificate chains with forge.pki.verifyCertificateChain() (including TLS peer verification via forge.tls) on a vulnerable version (<= 1.4.0). The attacker must obtain, from a CA already trusted by that application, a certificate carrying an attacker-supplied deprecated-OID extension (2.5.29.10 or 2.5.29.13) encoding basicConstraints cA TRUE, placed before the genuine 2.5.29.19 cA:FALSE extension - in practice this means the CA copies extensions from certificate signing requests (e.g. openssl x509 -req -copy_extensions copy/copyall with basicConstraints=CA:FALSE and no keyUsage). Key limiting factors: the attack fails if the issuing CA adds a keyUsage extension without keyCertSign (node-forge then rejects the chain), and it depends entirely on the trusted CA's willingness to copy unrecognized/unvetted extensions, so CAs that strip or do not copy CSR extensions are not exploitable. No limitation from user interaction or victim-side authentication applies (PR:N/UI:N), but the CA-cooperation requirement is the dominant constraint.

This is a genuine but conditionally-gated certificate-validation flaw, not a trivially exploitable remote bug. The CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N, 7.4 High) correctly captures the tension: network-reachable and requiring no attacker privileges against the victim (PR:N), but high attack complexity (AC:H) because exploitation depends on a trusted CA being induced to issue the malicious certificate. The vendor's informational CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N, 9.1) scores higher only because 4.0 moves the precondition into the separate Attack Requirements metric (AT:P) rather than inflating complexity; the advisory explicitly states the official rating follows 3.1. No EPSS score and no KEV status were provided in the input, so there is no evidence of active exploitation - the vuln.today Decision label is 'this_week' (prioritized, but not act_now/emergency). A working proof-of-concept exists (the fix commit adds the reporter's PoC as tests/pocs/ghsa-5x38-2vff-x55p.js plus regression tests), which raises practical risk above a theoretical finding. Net: a real priority for anyone whose application verifies TLS/X.509 chains with node-forge, but the hard dependency on a cooperating/misconfigured CA that copies CSR extensions keeps real-world exploitation targeted rather than mass-scannable.

An attacker submits a CSR to a CA trusted by the victim application that copies unrecognized extensions from requests (e.g. OpenSSL with -copy_extensions copy), embedding a deprecated-OID (2.5.29.10 or 2.5.29.13) basicConstraints extension with cA TRUE before the genuine cA:FALSE extension and omitting keyUsage. node-forge's verifyCertificateChain() reads the first 'basicConstraints'-named extension and accepts the end-entity cert as a CA, so the attacker uses its key to mint certificates for any hostname and impersonate TLS servers or clients to intercept traffic. A working PoC is published in the advisory and committed as a regression test, so the technique is fully documented.