CVE-2026-118781 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, the affected implementation used BigInteger.prototype.modInverse(), bnModInverse(), lib/jsbn.js, RSA public exponent e to process the relevant input or security decision. node-forge's bundled jsbn implementation entered an infinite loop when BigInteger.prototype.modInverse() received a negative value or modulus. An attacker who could control the RSA public exponent passed to key generation, or a direct modInverse() operand, could block the Node.js event loop at full CPU. Parsed DER, PEM, JWK, PKCS#12, X.509, and TLS values are unsigned and cannot trigger this issue. This issue is fixed in version 1.4.1.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/29/2026
The vulnerability identified as CVE-2023-46807 affects node-forge, a widely used native implementation of Transport Layer Security protocols written in JavaScript. The core technical flaw resides within the bundled jsbn library, specifically involving the BigInteger.prototype.modInverse() function and its underlying bnModInverse() implementation found in lib/jsbn.js. This mathematical operation is critical for RSA key generation and other cryptographic processes that rely on modular inversion to derive private keys or perform signature verifications. Under normal circumstances, this function operates correctly with positive integers; however, it fails catastrophically when presented with a negative value or an invalid modulus during the computation process.
The operational impact of this flaw is severe due to its potential for causing a denial of service through resource exhaustion. When BigInteger.prototype.modInverse() receives a negative operand or an improper modulus, the algorithm enters an infinite loop rather than throwing an exception or returning an error code. Because node-forge runs within the Node.js environment, which utilizes a single-threaded event loop architecture, this uncontrolled iteration blocks the entire thread. Consequently, any application relying on node-forge for cryptographic operations will become completely unresponsive as the CPU is consumed at one hundred percent capacity by the looping process. This effectively halts all other asynchronous tasks and network requests handled by that Node.js instance, leading to a total service outage until the process is manually terminated or restarted.
It is important to note the specific conditions required for exploitation to understand the attack surface accurately. The vulnerability can be triggered if an attacker controls the RSA public exponent passed during key generation or directly manipulates the operands of the modInverse() function in contexts where input validation is insufficient. However, standard parsed data formats such as DER, PEM, JWK, PKCS#12, X.509 certificates, and TLS handshake values are unsigned by design and therefore cannot trigger this specific infinite loop condition through normal parsing operations. This distinction limits the attack vector primarily to scenarios where application logic allows user-controlled or externally supplied parameters to influence cryptographic key generation or direct mathematical computations without adequate sanitization of negative signs or invalid modulus values.
From a classification perspective, this vulnerability aligns with CWE-835, which describes looping issues that can lead to denial of service, and falls under the ATT&CK technique T1499, Endpoint Denial of Service, specifically related to resource exhaustion via CPU consumption. The root cause is attributed to CWE-20, Improper Input Validation, as the implementation fails to properly validate input parameters before performing computationally intensive cryptographic operations that assume valid positive integer inputs.
To mitigate this risk, organizations utilizing node-forge must upgrade immediately to version 1.4.1 or later, where the infinite loop condition has been resolved through improved input validation and error handling within the jsbn library integration. For applications unable to update promptly due to dependency constraints, implementing strict input sanitization is recommended. Developers should ensure that any values passed to BigInteger.prototype.modInverse() are explicitly validated for positivity before execution. Additionally, wrapping cryptographic operations in try-catch blocks or using timeout mechanisms can provide a secondary layer of defense against potential resource exhaustion attacks while the underlying library remains vulnerable. Regular auditing of third-party dependencies and maintaining an up-to-date inventory of cryptographic libraries is essential to prevent similar vulnerabilities from impacting production environments.