A flaw in Node.js Permission Model enforcement allows Bypass via process.report.writeReport() Path Misvalidation. This can lead to confidentiality impact or bypass of the intended security boundary under affected configurations. This vulnerability affects all supported release lines: Node.js 22, Node.js 24, and Node.js 26.
A flaw in Node.js HTTP request handling causes an uncaught TypeError when a request is received with a header named proto and the application accesses req.headersDistinct.
When this occurs, dest["proto"] resolves to Object.prototype rather than undefined, causing .push() to be called on a non-array. This exception is thrown synchronously inside a property getter and cannot be intercepted by error event listeners, meaning it cannot be handled without wrapping every req.headersDistinct access in a try/catch.
This vulnerability affects all Node.js HTTP servers on 20.x, 22.x, 24.x, and v25.x
A flaw in Node.js HMAC verification uses a non-constant-time comparison when validating user-provided signatures, potentially leaking timing information proportional to the number of matching bytes. Under certain threat models where high-resolution timing measurements are possible, this behavior could be exploited as a timing oracle to infer HMAC values.
Node.js already provides timing-safe comparison primitives used elsewhere in the codebase, indicating this is an oversight rather than an intentional design decision.
This vulnerability affects 20.x, 22.x, 24.x, and 25.x.
An incomplete fix for CVE-2024-36137 leaves FileHandle.chmod() and FileHandle.chown() in the promises API without the required permission checks, while their callback-based equivalents (fs.fchmod(), fs.fchown()) were correctly patched.
As a result, code running under --permission with restricted --allow-fs-write can still use promise-based FileHandle methods to modify file permissions and ownership on already-open file descriptors, bypassing the intended write restrictions.
This vulnerability affects 20.x, 22.x, 24.x, and 25.x processes using the Permission Model where --allow-fs-write is intentionally restricted.
A flaw in V8's string hashing mechanism causes integer-like strings to be hashed to their numeric value, making hash collisions trivially predictable. By crafting a request that causes many such collisions in V8's internal string table, an attacker can significantly degrade performance of the Node.js process.
The most common trigger is any endpoint that calls JSON.parse() on attacker-controlled input, as JSON parsing automatically internalizes short strings into the affected hash table.
This vulnerability affects 20.x, 22.x, 24.x, and 25.x.
A memory leak occurs in Node.js HTTP/2 servers when a client sends WINDOWUPDATE frames on stream 0 (connection-level) that cause the flow control window to exceed the maximum value of 2³¹-1. The server correctly sends a GOAWAY frame, but the Http2Session object is never cleaned up.
This vulnerability affects HTTP2 users on Node.js 20, 22, 24 and 25.
A flaw in Node.js Permission Model filesystem enforcement leaves fs.realpathSync.native() without the required read permission checks, while all comparable filesystem functions correctly enforce them.
As a result, code running under --permission with restricted --allow-fs-read can still use fs.realpathSync.native() to check file existence, resolve symlink targets, and enumerate filesystem paths outside of permitted directories.
This vulnerability affects 20.x, 22.x, 24.x, and 25.x processes using the Permission Model where --allow-fs-read is intentionally restricted.
A flaw in Node.js TLS error handling allows remote attackers to crash or exhaust resources of a TLS server when pskCallback or ALPNCallback are in use. Synchronous exceptions thrown during these callbacks bypass standard TLS error handling paths (tlsClientError and error), causing either immediate process termination or silent file descriptor leaks that eventually lead to denial of service. Because these callbacks process attacker-controlled input during the TLS handshake, a remote client can repeatedly trigger the issue. This vulnerability affects TLS servers using PSK or ALPN callbacks across Node.js versions where these callbacks throw without being safely wrapped.
We have identified a bug in Node.js error handling where "Maximum call stack size exceeded" errors become uncatchable when asynchooks.createHook() is enabled. Instead of reaching process.on('uncaughtException'), the process terminates, making the crash unrecoverable. Applications that rely on AsyncLocalStorage (v22, v20) or asynchooks.createHook() (v24, v22, v20) become vulnerable to denial-of-service crashes triggered by deep recursion under specific conditions.
A flaw in Node.js's permission model allows a file's access and modification timestamps to be changed via futimes() even when the process has only read permissions. Unlike utimes(), futimes() does not apply the expected write-permission checks, which means file metadata can be modified in read-only directories. This behavior could be used to alter timestamps in ways that obscure activity, reducing the reliability of logs. This vulnerability affects users of the permission model on Node.js v20, v22, v24, and v25.
A malformed HTTP/2 HEADERS frame with oversized, invalid HPACK data can cause Node.js to crash by triggering an unhandled TLSSocket error ECONNRESET. Instead of safely closing the connection, the process crashes, enabling a remote denial of service. This primarily affects applications that do not attach explicit error handlers to secure sockets, for example: server.on('secureConnection', socket => { socket.on('error', err => { console.log(err) }) })
A flaw in Node.js’s Permissions model allows attackers to bypass --allow-fs-read and --allow-fs-write restrictions using crafted relative symlink paths. By chaining directories and symlinks, a script granted access only to the current directory can escape the allowed path and read sensitive files. This breaks the expected isolation guarantees and enables arbitrary file read/write, leading to potential system compromise. This vulnerability affects users of the permission model on Node.js v20, v22, v24, and v25.