CVE-2026-118780

In node-forge prior to 1.4.1, ASN.1 decoding inside BIT STRING values did not consistently apply the configured maxDepth limit and recursively retained copies at each nesting level. Crafted DER containing nested BIT STRINGs could cause excessive recursion, CPU use, and quadratic memory consumption during asn1.fromDer().

In node-forge prior to 1.4.1, deprecated extension OIDs 2.5.29.10 and 2.5.29.13 were parsed as basicConstraints, and pki.verifyCertificateChain() used the first extension with that name. If a trusted CA issues a certificate carrying an attacker-supplied deprecated-OID extension before the genuine basicConstraints extension, the certificate holder could have the certificate accepted as a CA and issue certificates for arbitrary names.

Prior to 1.4.1, node-forge enforced an X.509 CA certificate's basicConstraints.pathLenConstraint only when the certificate also carried a keyUsage extension. An attacker holding that CA's private key or a subordinate CA certificate could construct a chain exceeding the declared path length that still passed pki.verifyCertificateChain(). This is fixed in version 1.4.1.

In node-forge prior to 1.4.1, forge.tls.createConnection() continued processing after a TLS record of another content type interrupted a fragmented handshake message. A remote peer could trigger an uncaught TypeError in process(), causing the connection or hosting process to fail.

In node-forge prior to 1.4.1, received TLS records were processed recursively, consuming one JavaScript stack frame per record in a single input chunk. A remote peer could send thousands of small records together and exhaust the call stack, causing an uncaught exception and denial of service.

Prior to 1.4.1, node-forge did not validate the AES-GCM tagLength option passed to start() during decryption via forge.cipher.createDecipher(). When an application derived tagLength from received data or used an unset or zero-like value, and the authentication tag was empty or missing, decipher.finish() accepted unauthenticated ciphertext. This is fixed in version 1.4.1.

In node-forge before 1.4.1, a PKCS#12 MAC or password-based encryption iteration count of zero or less was accepted. pki.pbe.generatePkcs12Key() then returned a constant key independent of password and salt, allowing crafted PKCS#12 input processed by forge.pkcs12.pkcs12FromAsn1() to bypass password-based integrity checks. Predictable encryption keys and IVs also affected PKCS#12 PBE using pbeWithSHAAnd3-KeyTripleDES-CBC or pbewithSHAAnd40BitRC2-CBC, including shrouded key bags, encrypted SafeContents, and PKCS#8 ENCRYPTED PRIVATE KEY input processed by forge.pki.decryptPrivateKeyInfo(). PBES2/PBKDF2-encrypted content is unaffected.

In node-forge before 1.4.1, the 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.

In node-forge before 1.4.1, pem.decode() in lib/pem.js used polynomial-time regular expressions, including when searching for a matching END line and parsing encapsulated headers. An unauthenticated attacker able to supply PEM input to any high-level parser could consume excessive CPU with a long malformed message and cause denial of service.

In node-forge before 1.4.1, the TLS client checked the wrong property when deciding whether a server certificate was missing. A malicious TLS server or on-path peer could omit the Certificate message and reach code that dereferenced the absent certificate, causing an uncaught exception and terminating the connection or process. This affects forge.tls.createConnection(), c.session.serverCertificate, and RSA key exchange.