CVE-2026-119190: 
node-forge vulnerability analysis and mitigation

CVE-2026-119190 is an X.509 basicConstraints bypass vulnerability in node-forge (also called Forge), a native JavaScript implementation of Transport Layer Security. The flaw exists in all versions prior to 1.4.1 and allows an attacker — under specific conditions — to have a certificate accepted as a CA certificate and issue certificates for arbitrary names, enabling server or client impersonation. It was published on October 27, 2026, by the WorkOS Security Team and disclosed via GitHub Security Advisory GHSA-5x38-2vff-x55p. The vulnerability carries a CVSS v3.1 base score of 7.4 (High) (GitHub Advisory).

The root cause is classified as CWE-295 (Improper Certificate Validation) and CWE-436 (Interpretation Conflict). In lib/oids.js, node-forge maps the deprecated certificate extension OIDs 2.5.29.10 and 2.5.29.13 to the name basicConstraints — the same name used for the RFC 5280-compliant OID 2.5.29.19. Because cert.getExtension() returns the first extension matching a given name, and pki.verifyCertificateChain() looked up basicConstraints by name rather than by OID, an attacker could craft a certificate containing a deprecated-OID extension with cA TRUE placed before the genuine 2.5.29.19 extension with cA FALSE. This causes the chain verifier to treat a non-CA certificate as a CA, bypassing the constraint check. The same technique can also hide a pathLenConstraint. The fix (commit 58c06bc) changes chain verification to look up basicConstraints exclusively by OID 2.5.29.19 via cert.getExtension({id: '2.5.29.19'}) (GitHub Advisory, Fix Commit).

Successful exploitation allows the certificate holder to act as a rogue CA, issuing certificates for arbitrary hostnames that pki.verifyCertificateChain() will accept as valid. In forge's own TLS stack, this enables impersonation of servers (or clients where client certificates are verified) and interception of encrypted traffic, resulting in high confidentiality and integrity impact. Availability is not directly affected. The attack scope is limited to applications using forge.pki.verifyCertificateChain() or forge.tls, and exploitation requires a trusted CA that copies extensions from certificate signing requests (GitHub Advisory).

The vulnerability is classified as having a proof-of-concept (PoC) available; the reporter's PoC script (tests/pocs/ghsa-5x38-2vff-x55p.js) was added to the node-forge test suite as part of the fix commit, demonstrating the attack with a crafted certificate chain. There is no evidence of in-the-wild exploitation at this time. The EPSS score is 0.0, and the vulnerability is not listed in the CISA KEV catalog. Exploitation is not automatable and requires high attack complexity — specifically, a trusted CA that copies unrecognized extensions from CSRs (e.g., using openssl x509 -req -copy_extensions copy) (GitHub Advisory, Feedly).

1. Identify a vulnerable CA: Find a Certificate Authority trusted by the target application that copies extensions from certificate signing requests (e.g., one using openssl x509 -req -copy_extensions copy or copyall).
2. Craft a malicious CSR: Create a CSR that includes a deprecated OID extension (2.5.29.10 or 2.5.29.13) encoding BasicConstraints { cA TRUE } (DER: 30 03 01 01 FF) placed before any basicConstraints extension in the request.
3. Obtain a signed certificate: Submit the CSR to the trusted CA. If the CA copies extensions from the CSR and sets basicConstraints = CA:FALSE without adding a keyUsage extension containing keyCertSign, the resulting certificate will contain the forged deprecated-OID extension before the genuine 2.5.29.19 extension.
4. Issue a leaf certificate: Use the private key of the obtained certificate to sign a new leaf certificate for any target hostname (e.g., victim.example.com).
5. Present the forged chain: Present the chain [leaf, attackerCert] to a node-forge-based TLS verifier. On versions ≤ 1.4.0, pki.verifyCertificateChain() reads the deprecated-OID extension first, sees cA TRUE, and accepts the attacker's certificate as a CA, validating the forged leaf certificate.
6. Achieve impersonation: Use the accepted chain to impersonate the target server (or client) and intercept or manipulate TLS-protected communications (GitHub Advisory, Fix Commit).

• Certificate Artifacts: Certificates presented during TLS handshakes containing both a deprecated OID extension (2.5.29.10 or 2.5.29.13) with cA TRUE and a standard 2.5.29.19 basicConstraints extension with cA FALSE in the same certificate.
• Certificate Inspection: Intermediate certificates in a chain where cert.getExtension('basicConstraints') returns an extension with OID 2.5.29.10 or 2.5.29.13 rather than 2.5.29.19.
• Logs: Unexpected successful TLS handshakes with certificates issued by an intermediate CA that does not appear in the trusted CA store but whose issuer does; certificate transparency logs showing certificates with unusual deprecated OID extensions.
• Network: TLS sessions where the presented certificate chain includes a non-standard intermediate with no keyUsage extension and a deprecated basicConstraints OID (GitHub Advisory).

Upgrade node-forge to version 1.4.1 or later, which fixes the issue by changing pki.verifyCertificateChain() to look up basicConstraints exclusively by OID 2.5.29.19 (v1.4.1 Release). No in-library workaround exists for unpatched versions, but applications using an options.verify callback in pki.verifyCertificateChain() (or verify in forge.tls.createConnection()) can reject chains where a non-leaf certificate lacks a 2.5.29.19 extension with cA TRUE, checked via cert.getExtension({id: '2.5.29.19'}). Additionally, CA operators should avoid copying unrecognized extensions from certificate signing requests, and should add a keyUsage extension without keyCertSign to issued end-entity certificates, which causes node-forge to reject the forged chain even on unpatched versions (GitHub Advisory).

The vulnerability was reported by the WorkOS Security Team (@nickcollisson-workos) and published by maintainer davidlehn on October 27, 2026. The advisory notes it was submitted with AI assistance. No significant broader media coverage or notable community commentary beyond the GitHub advisory has been identified at this time (GitHub Advisory).