Executive Summary

After pre-announcing this security release late last year and postponing the disclosure three times, the Node.js team released a security patch addressing eight vulnerabilities (3 high severity, 4 medium, 1 low) across all active release lines. They represent four denial of service (DoS) vulnerabilities (CVE-2025-59464, CVE-2025-59465, CVE-2025-59466, CVE-2026-21637), three bypasses of the the newly-introduced permission system (CVE-2025-55132, CVE-2026-21636, CVE-2025-55130), and one memory exposure vulnerability (CVE-2025-55131).

Since Node.js is used in a variety of use cases, with fundamentally different threat models, it is not trivial to assess the potential impact of these vulnerabilities. We believe that most of the disclosed issues (with one potential exception) have limited real-world exploitability for Internet-facing web applications, due to restrictive prerequisites. However, they might affect other use cases like executing AI-generated code or running portable desktop applications.

The permission model issues require applications to explicitly enable Node.js's `--permission` flag, which we believe is not widely adopted in production environments. This permission system was introduced in early 2023 (in v20.0.0), but marked as experimental until one year ago (in v23.5.0). Similarly, the memory exposure vulnerability only affects applications using the `vm` module with timeout options, a configuration that Node.js maintainers have repeatedly warned against for processing untrusted code. The other vulnerabilities are DoS ones with specific prerequisites—CVE-2025-59466 requires async_hooks to be enabled, CVE-2025-59464 affects applications processing TLS client certificates, and CVE-2026-21637 only impacts servers using PSK or ALPN callbacks.

Thus, the disclosed vulnerabilities affect Node.js  users of the `vm` module, specific uses of the TLS API, and the newly-introduced permission system. Nonetheless, we recommend all Node.js users to update to the latest version: Even if you are not using these APIs directly, one of your dependencies might, so it is safer to update the underlying Node.js instance. This being said, we believe that the likelihood of large-scale exploitation of web servers similar to recent widespread attacks like React2Shell is low in this case. One notable exception might be CVE-2025-59465, which we break down below.

Affected versions

‍

Out of the eight vulnerabilities, three affect the permission system and one the HTTP/2 handling, both being relatively new features in Node.js. Hence, older EOL versions of the runtime might not be affected simply because they do not have these features. However, we do not advise using such old software in production, under any circumstances.

What happened

Node.js released a security patch addressing eight vulnerabilities: four denial of service ones that lead to crashes or memory leaks, including a high-severity vulnerability that can take down Node.js instances with a single malformed request. Three vulnerabilities allow bypassing Node.js's experimental permission system via symbolic links and Unix Domain Sockets, while one high-severity issue exposes uninitialized memory, potentially containing secrets through a race condition in buffer allocation when using the vm module.

‍Node.js powers server-side processing with frameworks like Express or Next.js, cross-OS desktop applications with Electron, and modern AI usages with Antrophic SDK. Thus, when assessing the impact of the disclosed vulnerability all these different threat models need to be considered. Concretely, the four denial of service vulnerabilities only affect outside-facing applications that the attacker can take down. The permission system-based ones are more interesting for AI or desktop applications, where users might want to restrict the capabilities of the executed code directly. Finally, the memory exposure vulnerability mainly affects shared-execution environments where attackers can directly execute code, e.g., inside a sandbox. One such example are automation frameworks like Zapier, n8n, or activepieces.

Technical analysis

We deep dive below into the three most important vulnerabilities disclosed in Node.js, one per vulnerability class.

CVE-2025-55131: Timeout-based race conditions make Uint8Array/Buffer.alloc non-zerofilled

A race condition in Node.js’s buffer allocation logic allows the zero-fill toggle to remain disabled when `vm` module timeouts interrupt execution. This can expose uninitialized heap memory containing sensitive data such as passwords, API tokens, or other sensitive data utilized in memory. When a `vm` timeout interrupts execution between disabling and re-enabling the toggle, subsequent `Buffer.alloc()` calls intended to be zero-filled return uninitialized memory.

function createUnsafeBuffer(size) { 
    zeroFill[0] = 0; // Step 1: Disable zero-fill via shared memory 
    try { 
        return new FastBuffer(size); // Step 2: Allocate buffer 
        } finally { zeroFill[0] = 1; // Step 3: Re-enable zero-fill 
    } 
}

‍

The patch removes the shared toggle mechanism entirely and introduces a dedicated API, `createUnsafeArrayBuffer` that explicitly creates uninitialized buffers per-call.

function createUnsafeBuffer(size) {
    if (size <= 64) {
        return new FastBuffer(size);
    }
    // Explicit call to create uninitialized buffer
    return new FastBuffer(createUnsafeArrayBuffer(size));
}

‍

It is worth noting that Node.js maintainers have long stated that the `vm` module is not a security boundary and should not be used to run untrusted code: https://nodejs.org/api/vm.html#vm-executing-javascript. Thus, the exploitable conditions for this vulnerability are not advised or supported by the Node.js maintainers and go against best practices.

CVE-2025-59465: HTTP/2 TLSSocket Unhandled Error DoS

HTTP/2 enabled connections to Node.js servers are vulnerable to DoS via malformed HPACK header data. This is a result of improper error handling within the internal TLSSocket functionality, specifically the lack of a default error event handler. Node.js relies on the `nghttp2` library written in C to handle HTTP/2 connections. When `nghttp2` resets the connection due to compression errors, the resulting `ECONNRESET` (“Connection reset by peer”) event is passed to the TLSSocket, treating it as a reset connection. The TLSSocket then triggers an error event that is not properly interpreted by the `tlsConnectionListener` function, causing the process to crash. The `tlsConnectionListener` function attached handlers for close and _tlsError socket events but not the standard error event:

socket.on('close', onSocketClose);
socket.on('_tlsError', onSocketTLSError);

‍

The patch added a single line to the `tlsConnectionListener` function to properly handle incoming generic error events, effectively addressing the implemented issue:

socket.on('error', onSocketTLSError);

CVE-2025-55130: Permission Model Symlink Bypass

The permission model's symlink restrictions could be bypassed through various edge cases. The previous implementation only blocked relative symlinks but allowed absolute symlinks that could still circumvent path restrictions through path traversal. The patch now in place requires full `fs.read` and `fs.write` permissions to utilize the `fs.symlink` API within the enabled permission model. Similar vulnerabilities were reported by us in the past https://www.ndss-symposium.org/wp-content/uploads/2025-284-paper.pdf for Deno, a JavaScript runtime that popularized permissions in this domain.

We have noted previously that configuring the Node.js permission system correctly is tricky since broad permissions might invalidate the security control:

https://www.endorlabs.com/learn/cve-2025-68428-critical-path-traversal-in-jspdf. This vulnerability further supports that idea where if an attacker has full control of a specific part of the file system, the permission system becomes ineffective. That is, if an attacker is able to create a relative symlink within the filesystem, they would gain read and write access over arbitrary files on the disk.

Mitigation

• The Node.js permission system is a great starting point, but it is not enough. One needs to supplement it with more sturdy security controls like containers, OS-level file system permissions, or network-level restrictions.
• If you are using the vm module to run untrusted code, do not - it is very dangerous. Node.js maintainers agree that it should never be used to run untrusted code https://github.com/nodejs/node/issues/40718 but rather to support benign use cases like unit testing. If you are using this module in production, in Internet-facing web servers, you might have bigger problems than uninitialized memory exposure (CVE-2025-55131). The `vm` module directly caused many sandbox-escape vulnerabilities, e.g., CVE-2021-23555 or https://www.endorlabs.com/learn/happier-doms-the-perils-of-running-untrusted-javascript-code-outside-of-a-web-browser,  and it might allow attackers to execute remote code execution on your machine.
• Closely monitor Node.js instances for any availability problems: unusual crashes, unexpectedly high memory consumption.
• Configure your IDS to restrict the header size for HTTP/2 requests and to limit their volume.

References

• Blog post describing the Node.js security patch: https://nodejs.org/en/blog/vulnerability/december-2025-security-releases‍
• Node.js’ permission system: https://nodejs.org/api/permissions.html

‍