CVE-2026-119190 in Forge
Summary
by MITRE • 10/29/2026
Forge (also called node-forge) is a native implementation of Transport Layer Security in JavaScript. Prior to 1.4.1, node-forge parsed deprecated extension OIDs 2.5.29.10 and 2.5.29.13 as basicConstraints, and pki.verifyCertificateChain() used the first extension with that name. Exploitation requires a CA trusted by the application to issue a certificate carrying an attacker-supplied deprecated-OID extension, commonly because the CA copies extensions from a certificate signing request. By placing a permissive deprecated extension before the genuine 2.5.29.19 basicConstraints extension, the certificate holder could have the certificate accepted as a CA and issue certificates for arbitrary names, enabling server or client impersonation. If the issuing CA adds a keyUsage extension without keyCertSign, node-forge rejects the chain. This issue is fixed in version 1.4.1.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/29/2026
The vulnerability identified in the Forge library, also known as node-forge, represents a critical flaw in how Transport Layer Security certificates are parsed and validated within JavaScript environments. As a native implementation of TLS, this library plays a pivotal role in establishing secure communications for numerous web applications and services that rely on Node.js or browser-based cryptographic operations. The core issue stems from the incorrect parsing logic applied to deprecated X.509 extension Object Identifiers (OIDs). Specifically, prior to version 1.4.1, the parser erroneously treated OIDs 2.5.29.10 and 2.5.29.13 as basicConstraints extensions rather than recognizing them for their intended purposes, which are typically subject alternative name or other certificate attribute definitions respectively. This misclassification creates a significant divergence between how node-forge interprets certificate data compared to standard-compliant parsers such as OpenSSL or BoringSSL, leading to inconsistent security postures across different implementations of TLS stacks.
The operational impact of this flaw is severe because it allows for the potential bypass of Certificate Authority validation checks through a technique known as extension confusion. An attacker can exploit this by obtaining a certificate from a trusted CA that includes these deprecated OIDs placed before the genuine basicConstraints extension, which corresponds to OID 2.5.29.19. Many CAs automatically copy extensions present in a Certificate Signing Request into the issued certificate without rigorous validation of their order or type. If an attacker submits a request containing a permissive version of one of these deprecated OIDs before the actual basicConstraints extension, node-forge will identify the first occurrence labeled as basicConstraints and accept it. This effectively grants the certificate holder CA privileges despite lacking the proper keyCertSign permission in the keyUsage extension, provided that such an extension is present but does not explicitly forbid signing certificates.
This misconfiguration enables server or client impersonation attacks where a malicious actor can issue valid-looking certificates for arbitrary domain names using their own private keys while maintaining trust within applications relying on node-forge. The attacker leverages the trusted CA's signature to validate these forged certificates, thereby deceiving clients into establishing encrypted connections with the adversary instead of the legitimate service host. This undermines the fundamental guarantees of confidentiality and integrity provided by TLS, allowing for man-in-the-middle attacks where sensitive data can be intercepted or modified without detection. It is important to note that this specific exploitation path requires the issuing CA to include a keyUsage extension; if such an extension exists but lacks the keyCertSign bit set, node-forge correctly rejects the chain, highlighting that the vulnerability relies on specific combinations of certificate attributes rather than a universal failure in all scenarios.
From a standards perspective, this flaw aligns with CWE-295 Improper Certificate Validation and CWE-613 Insufficient Session Expiration, as it involves mishandling critical security extensions within X.509 certificates. In the context of the MITRE ATT&CK framework, this vulnerability facilitates techniques associated with Initial Access or Defense Evasion by allowing attackers to create trusted identities that bypass standard authentication mechanisms. The root cause lies in a failure to strictly adhere to RFC 5280 regarding the parsing order and precedence of certificate extensions, particularly when dealing with legacy or deprecated identifiers. Developers must ensure that their cryptographic libraries correctly prioritize the basicConstraints extension regardless of its position within the extension list to prevent such confusion attacks.
To mitigate this risk, organizations utilizing node-forge for TLS operations should immediately upgrade to version 1.4.1 or later, where the parsing logic has been corrected to properly distinguish between deprecated OIDs and standard extensions like basicConstraints. Additionally, security teams should audit their certificate signing policies to ensure that CAs do not blindly copy all extensions from Certificate Signing Requests without validating their content and order. Implementing strict validation rules at both the CA level and the client library level provides defense in depth against extension confusion attacks. Regular updates of cryptographic dependencies are essential as TLS standards evolve, and relying on outdated or buggy implementations can expose infrastructure to sophisticated identity spoofing campaigns that exploit these subtle parsing discrepancies.