Forge (also called node-forge) is a native implementation of Transport Layer Security in JavaScript. Prior to 1.4.1, the affected implementation used asn1.fromDer(), BIT STRING decoding, maxDepth to process the relevant input or security decision. node-forge decoded ASN.1 stored inside BIT STRING values without consistently applying 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(). This issue is fixed in version 1.4.1.

Summary

Connections created with forge.tls.createConnection() processed received TLS records recursively, one stack level per record. A peer can send one chunk of thousands of small records, such as heartbeat records, which are accepted before the handshake, and process() throws RangeError: Maximum call stack size exceeded, which terminates Node.js processes that use the documented socket wiring. Fixed in node-forge 1.4.1.

Details

In lib/tls.js, c.process() reads one record and passes it to update(), which calls the handler for the record type from ctTable. Every handler (tls.handleHeartbeat, tls.handleApplicationData, tls.handleHandshake for fragmented messages, tls.handleHelloRequest and the other handshake handlers) ends by calling c.process() again to continue with the next buffered record, or the next message in the same record. Each record therefore adds process → update → handler to the call stack. In Node.js 24, about 2,300 eight-byte records (under 20 KB) in one chunk are enough for process() to throw RangeError: Maximum call stack size exceeded.

ctTable maps heartbeat records to tls.handleHeartbeat in every client and server state, so heartbeat records are processed before the handshake without any extension negotiation. The attack needs no authentication and no valid handshake messages. Both server connections (attacked by a client) and client connections (attacked by the server they connect to) are affected. Other record types recurse the same way: a handshake message fragmented over many records, many HelloRequest messages in one record, or many application data records after the handshake.

node-forge reports TLS protocol errors through the error callback, so applications do not normally wrap process() in try/catch. When process() is called from a Node.js socket data handler, as in the documented usage, the exception is uncaught and terminates the process. If the exception is caught, the connection is left partially processed and should be discarded.

No specification is violated; this is an implementation flaw (uncontrolled recursion).

The fix makes c.process() iterative. The record-reading code moves into processRecord(), and c.process() runs it in a loop. A handler's call to c.process() without new data, made while records are being processed, now only flags that the loop should continue. Calls with new data are processed right away as before, so callback order and return values are unchanged.

Patches Fixed in node-forge 1.4.1. Records are now processed in a loop, so the stack depth no longer depends on the number of records.

Workarounds Wrap every call to connection.process() in try/catch, and on an exception close the connection (connection.close()) and destroy the underlying socket. This prevents the process crash but not the loss of the attacked connection.

Credits Reported jointly by Ziyue Wang, Chenchen, Strick Sheng, Liyi Zhou, and Maurice Ng.

Proof of concept

Input: one chunk of N identical heartbeat records, each 8 bytes:

18 03 01 00 03 01 00 00 (content type 24 = heartbeat, TLS 1.0, length 3, heartbeatrequest with a 0-byte payload)

// c = forge.tls.createConnection({server: true, ...}) var rec = forge.util.hexToBytes('1803010003010000'); c.process(new Array(5001).join(rec)); // 5,000 records, 40,000 bytes

On 1.4.0 (Node.js 24), process() throws RangeError: Maximum call stack size exceeded after about 2,300 records, before any handshake. The same happens for a client connection. In a Node.js server that calls c.process(data.toString('binary')) from socket.on('data', ...), a client sending these 40,000 bytes terminates the server process. On 1.4.1 all records are processed and the server keeps running.

Regression tests in tests/unit/tls.js, "record processing": 50,000 heartbeat records in one call in server and client mode, a handshake message fragmented over 50,000 records, many HelloRequest messages per record, and checks that byte-by-byte input and exceptions from callbacks behave as before.

Impact

Applications that use node-forge's TLS implementation: connections from forge.tls.createConnection(), including those created by forge.tls.wrapSocket() and the forge.http / forge.xhr TLS connections, which call process() on received data. Any peer that can connect to a forge TLS server, or any server a forge TLS client connects to, can send a small chunk of records (under 20 KB) without authentication. In Node.js applications using the documented usage, the uncaught exception terminates the process, which drops every connection it serves; repeated chunks keep it down. In browsers the impact is limited to the attacked connection. There is no confidentiality or integrity impact.

Summary The forge.http client stored cookies from Set-Cookie response headers in a plain object keyed by cookie name and path. A malicious server could use the cookie name proto to add properties to Object.prototype, use inherited names such as constructor to add properties to Object, and send an empty cookie value to delete Object.prototype properties. Fixed in node-forge 1.4.1.

Details client.setCookie() in lib/http.js stored a cookie with client.cookies[cookie.name][cookie.path] = cookie, creating client.cookies[cookie.name] only when !(cookie.name in client.cookies). Both values come from the server's Set-Cookie header via response.getCookies(). Because in also sees inherited properties:

- a cookie named proto skipped the initialization, client.cookies['proto'] returned Object.prototype, and the cookie path was written as a new Object.prototype property, visible on every object; - a cookie named constructor wrote onto the global Object function the same way; - a cookie with an empty value calls client.removeCookie(name, path), which used the same in checks and then delete client.cookies[name][path], so Set-Cookie: proto=; path=toString deleted Object.prototype.toString. This path skipped the cookie's secure-flag and domain checks, so it also worked for http:// clients.

forge.http is not loaded by require('node-forge'). It is included in the forge.all browser bundle and is used with a socket pool, for example by forge.xhr.

The fix uses own-property checks for the cookie store and ignores cookies named proto or with the path proto.

Patches Fixed in node-forge 1.4.1. Cookies from a server can no longer add or remove properties of Object.prototype or Object.

Workarounds Don't use forge.http or forge.xhr with servers that aren't trusted, or filter Set-Cookie headers named proto, constructor or other Object.prototype property names before they reach the client.

Credits Reported by @arunmozhivarman-dtx and @Dremig.

Proof of concept A server response for a forge.http client (http.createClient({url: 'https://...', socketPool: ...})) containing:

Set-Cookie: proto=evil; path=polluted

On 1.4.0, after the client processes the response, ({}).polluted is the cookie object. With Set-Cookie: proto=; path=toLocaleString, Object.prototype.toLocaleString is deleted (for http:// and https:// clients). On 1.4.1 these cookies are ignored and Object.prototype is unchanged.

Regression tests are in tests/security/ghsa-6wvx-3r32-xmcg.js.

Impact Applications that use the forge.http client (directly, or through forge.xhr in the forge.all browser bundle) against a server that can be malicious are affected. The server can add properties to Object.prototype and Object for the whole JavaScript realm, which can change application logic that reads properties from plain objects, and can delete built-in Object.prototype methods, breaking the page or process. Applications that don't use forge.http are not affected.

Forge (also called node-forge) is a native implementation of Transport Layer Security in JavaScript. Prior to 1.4.1, the affected implementation used decipher.finish(), CBC and ECB modes, PKCS#7 padding to process the relevant input or security decision. node-forge validated only the final byte of PKCS#7 padding during CBC and ECB decryption and accepted zero, oversized, or mismatched padding bytes. Malformed ciphertext could consequently be accepted and up to four plaintext blocks could be silently removed, causing an integrity failure in applications that treated successful decryption as proof of valid padding. This issue is fixed in version 1.4.1.

Summary

asn1.oidToDer() did not range-check the first two arcs of an OID string, so an OID such as 0.42.840.113549.1.1.1 or 4294977127.18.840.113549.1.1.1 was encoded as the DER of a different OID (here rsaEncryption, 1.2.840.113549.1.1.1). This is an incomplete fix of CVE-2025-66030. Fixed in node-forge 1.4.1.

Details

X.690 section 8.19 encodes the first two arcs of an OID as one subidentifier, 40 arc1 + arc2, where the first arc is 0, 1 or 2 and the second arc is at most 39 when the first is 0 or 1. asn1.oidToDer() in lib/asn1.js computed that value with no range check and wrote it with putByte(), which keeps only the low 16 bits. Out-of-range first arcs therefore produced the encoding of a different OID: 0.42.840.113549.1.1.1 gives 40 0 + 42 = 42 and 4294977127.18.840.113549.1.1.1 wraps to 42, both the first byte of rsaEncryption. The fix for CVE-2025-66030 (GHSA-65ch-62r8-g69g, node-forge 1.3.2) added a 32-bit check for the later arcs only.

A related encoding bug made valid OIDs with a first subidentifier above 127 (2.48 and higher, e.g. 2.999) encode and decode incorrectly, because the first subidentifier was always written and read as a single byte.

The fix rejects out-of-range first arcs and encodes and decodes the first subidentifier in base 128 like the others (the latter from public PR #1148).

Patches Fixed in node-forge 1.4.1. asn1.oidToDer() throws for OIDs with out-of-range first arcs, and the first subidentifier is encoded and decoded correctly.

Workarounds Validate OID strings from untrusted input before passing them to node-forge: the first arc must be 0, 1 or 2, and the second arc at most 39 when the first arc is 0 or 1.

Credits Reported by wzc. The first subidentifier encoding fix is from PR #1148 by @spokodev.

Proof of concept

var forge = require('node-forge'); var der = forge.asn1.oidToDer('0.42.840.113549.1.1.1'); console.log(der.toHex()); // 2a864886f70d010101 console.log(forge.asn1.derToOid(der)); // 1.2.840.113549.1.1.1

On 1.4.0 the out-of-range OID string encodes to exactly the DER of rsaEncryption (the same happens with 4294977127.18.840.113549.1.1.1). On 1.4.1 oidToDer() throws "Invalid OID; the first two arcs are out of range.".

Regression tests are in tests/unit/asn1.js ("should reject OIDs with out of range first arcs").

Impact

Applications that accept OID strings from untrusted input, check or authorize them as strings, and then encode them with node-forge (for example when building certificates, CSRs or other ASN.1 structures from user-supplied extension or attribute OIDs) can be made to emit a different, trusted OID than the one that was checked. Parsing DER is not affected. There is no confidentiality or availability impact.

Forge (also called node-forge) is a native implementation of Transport Layer Security in JavaScript. Prior to 1.4.1, the affected implementation used certificate.verify(child), verifySignature(), lib/x509.js to process the relevant input or security decision. node-forge selected RSA padding and RSASSA-PSS parameters from the issuer certificate rather than the child certificate being verified. A child labeled as RSASSA-PSS could therefore be accepted with a PKCS#1 v1.5 signature when the issuer used PKCS#1 v1.5. The signature still had to be produced with the trusted issuer's private key, so this did not permit certificate identity forgery, but it could bypass policies that require a declared signature scheme. This issue is fixed in version 1.4.1.