A Deno program that opens a client WebSocket connection could be crashed by the remote server. While handling the WebSocket handshake response, Deno parsed the Sec-WebSocket-Protocol and Sec-WebSocket-Extensions response headers in a way that assumed their bytes were always printable ASCII. A response header containing non-visible-ASCII bytes (0x80-0xFF) caused a panic that aborted the entire Deno process.
When a WebSocket connection was opened, Deno checked the destination hostname against –deny-net rules but did not re-check the IP addresses that hostname resolved to. An attacker-controlled script could use a specially crafted domain name that passes the hostname check yet resolves to a denied IP, bypassing the network restriction entirely.
In Deno, environment access is gated by the env permission. You can deny it with –deny-env, or restrict it to a specific allowlist with –allow-env=FOO,BAR. The expectation is that a program running without env permission cannot change process.env. process.loadEnvFile() (the Node-compatible API for loading variables from a .env file) does not honor this. It only checks that the program has read permission for the dotenv file, then writes every key …
Deno's permission system enforces filesystem and execution restrictions by comparing the requested path against the path supplied to –deny-read, –deny-write, –deny-run, or –deny-ffi. On macOS, that comparison was done at the raw-byte level while the APFS filesystem treats different Unicode spellings of the same name as the same file. That means a program could reach a denied path by spelling it differently than the deny rule. For example, with –deny-read=/secrets/passwörter.txt, …
Deno's network permission model is designed so that –deny-net rules apply to the resolved IP address of a destination, not just the literal string supplied by the caller. That means –deny-net=127.0.0.1 (or –deny-net=127.0.0.0/8) is expected to block any attempt to reach loopback, regardless of how the hostname is spelled. On affected versions, the Node.js compatibility TCP path checked the permission against the original hostname string before resolution and then did …
node:crypto.checkPrime(candidate[, options][, callback]) and crypto.checkPrimeSync(candidate[, options]) ran no Miller-Rabin rounds at all when the caller left options.checks at its default of 0. In that mode, the only test applied to the candidate was trial division by the primes up to 17,863. Any composite whose smallest prime factor exceeds that bound — for example the product of two primes just above it, such as 17,881 × 17,891 — was reported as …
Deno's node:child_process implementation provided an escapeShellArg() helper used when callers passed shell: true to spawn / spawnSync / exec and friends. On Windows, the helper failed to quote arguments that contained cmd.exe metacharacters such as &, |, <, >, ^, !, (, ), and did not neutralize % (which cmd.exe expands even inside double-quoted strings). An attacker who controlled any portion of an argument passed to such a call could …
When Deno was run in BYONM mode (nodeModulesDir: "manual"), the module resolver did not validate that a package's resolved entrypoint stayed within its node_modules/<pkg>/ directory. A malicious package.json whose main field contained .. segments was able to resolve to an arbitrary path on disk, and the resolver then read that file without consulting the –allow-read allowlist. This let a require("evil-pkg") call return the contents of a file that a direct …
When fetch() was called, Deno checked the destination hostname against –deny-net rules but did not re-check the IP addresses that hostname resolved to. An attacker-controlled script could use a specially crafted domain name that passes the hostname check yet resolves to a denied IP, bypassing the network restriction entirely.
A flaw in Deno's Node.js tls compatibility layer could cause a TLS client to transmit application data in plaintext after a connection retry. When `autoSelectFamily was enabled and the first address-family attempt failed, the socket reinitialization path reused a stale TLS upgrade hook that was bound to the original, failed handle. As a result, the replacement TCP connection was never upgraded to TLS, and any data the application wrote before …
A command injection vulnerability exists in Deno's node:child_process polyfill (shell: true mode) that bypasses the fix for CVE-2026-27190 (GHSA-hmh4-3xvx-q5hr). An attacker who controls arguments passed to spawnSync or spawn with shell: true can execute arbitrary OS commands, bypassing Deno's permission system. Affected versions: Deno v2.7.0, v2.7.1
A command injection vulnerability exists in Deno's node:child_process implementation.
The vulnerability allows an attacker to have infinite encryptions. This can lead to naive attempts at brute forcing, as well as more refined attacks with the goal to learn the server secrets.
A prior patch aimed to block spawning Windows batch/shell files by returning an error when a spawned path’s extension matched .bat or .cmd. That check performs a case-sensitive comparison against lowercase literals and therefore can be bypassed when the extension uses alternate casing (for example .BAT, .Bat, etc.).
Deno.FsFile.prototype.stat and Deno.FsFile.prototype.statSync are not limited by the permission model check –deny-read=./. It's possible to retrieve stats from files that the user do not have explicit read access to (the script is executed with –deny-read=./) Similar APIs like Deno.stat and Deno.statSync require allow-read permission, however, when a file is opened, even with file-write only flags and deny-read permission, it's still possible to retrieve file stats, and thus bypass the permission …
Deno versions up to 2.5.1 are vulnerable to Command Line Injection attacks on Windows when batch files are executed.
Deno.FsFile.prototype.utime and Deno.FsFile.prototype.utimeSync are not limited by the permission model check –deny-write=./. It's possible to change to change the access (atime) and modification (mtime) times on the file stream resource even when the file is opened with read only permission (and write: false) and file write operations are not allowed (the script is executed with –deny-write=./). Similar APIs like Deno.utime and Deno.utimeSync require allow-write permission, however, when a file is …
Static imports are exempted from the network permission check. An attacker could exploit this to leak the password file on the network.
This affects AES-256-GCM and AES-128-GCM in Deno, introduced by commit 0d1beed. Specifically, the authentication tag is not being validated. This means tampered ciphertexts or incorrect keys might not be detected, which breaks the guarantees expected from AES-GCM. Older versions of Deno correctly threw errors in such cases, as does Node.js. Without authentication tag verification, AES-GCM degrades to essentially CTR mode, removing integrity protection. Authenticated data set with set_aad is also …
The Deno.env.toObject method ignores any variables listed in the –deny-env option of the deno run command. When looking at the documentation of the –deny-env option this might lead to a false impression that variables listed in the option are impossible to read.
deno run –allow-read –deny-read main.ts results in allowed, even though 'deny' should be stronger. Same with all global unary permissions given as –allow-* –deny-*.
It is possible to bypass Deno's read/write permission checks by using ATTACH DATABASE statement.
When you send a request with the Authorization header to one domain, and the response asks to redirect to a different domain, Deno'sfetch() redirect handling creates a follow-up redirect request that keeps the original Authorization header, leaking its content to that second domain.
The Deno sandbox may be unexpectedly weakened by allowing file read/write access to privileged files in various locations on Unix and Windows platforms. For example, reading /proc/self/environ may provide access equivalent to –allow-env, and writing /proc/self/mem may provide access equivalent to –allow-all. Users who grant read and write access to the entire filesystem may not realize that these access to these files may have additional, unintended consequences. The documentation did …
Deno improperly checks that an import specifier's hostname is equal to or a child of a token's hostname, which can cause tokens to be sent to servers they shouldn't be sent to. An auth token intended for example.com may be sent to notexample.com.
Use of raw file descriptors in op_node_ipc_pipe() leads to premature close of arbitrary file descriptors, allowing standard input to be re-opened as a different resource resulting in permission prompt bypass.
Use of inherently unsafe *const c_void and ExternalPointer leads to use-after-free access of the underlying structure, resulting in arbitrary code execution.
Insufficient validation of parameters in Deno.makeTemp* APIs would allow for creation of files outside of the allowed directories. This may allow the user to overwrite important files on the system that may affect other systems. A user may provide a prefix or suffix to a Deno.makeTemp* API containing path traversal characters. The permission check would prompt for the base directory of the API, but the final file that was created …
A vulnerability in Deno's Node.js compatibility runtime allows for cross-session data contamination during simultaneous asynchronous reads from Node.js streams sourced from sockets or files. The issue arises from the re-use of a global buffer (BUF) in stream_wrap.ts used as a performance optimization to limit allocations during these asynchronous read operations. This can lead to data intended for one session being received by another session, potentially resulting in data corruption and …
A maliciously crafted permission request can show the spoofed permission prompt by inserting a broken ANSI escape sequence into the request contents.
Outbound HTTP requests made using the built-in "node:http" or "node:https" modules are incorrectly not checked against the network permission allow list (–allow-net). Dependencies relying on these built-in modules are subject to the vulnerability too. Users of Deno versions prior to 1.34.0 are unaffected. Deno Deploy users are unaffected.
Versions of the package deno before 1.31.0 are vulnerable to Regular Expression Denial of Service (ReDoS) due to the upgradeWebSocket function, which contains regexes in the form of /s*,s*/, used for splitting the Connection/Upgrade header. A specially crafted Connection/Upgrade header can be used to significantly slow down a web socket server.
Arbitrary program names without any ANSI filtering allows any malicious program to clear the first 2 lines of a op_spawn_child or op_kill prompt and replace it with any desired text.
Resizable ArrayBuffers passed to asynchronous native functions that are shrunk during the asynchronous operation could result in an out-of-bound read/write. It is unlikely that this has been exploited in the wild, as the only version affected is Deno 1.32.0. Deno Deploy users are not affected.
Duplicate Advisory This advisory has been withdrawn because it is a duplicate of GHSA-jc97-h3h9-7xh6. This link is maintained to preserve external references. Original Description Versions of the package deno before 1.31.0 are vulnerable to Regular Expression Denial of Service (ReDoS) due to the upgradeWebSocket function, which contains regexes in the form of /s*,s*/, used for splitting the Connection/Upgrade header. A specially crafted Connection/Upgrade header can be used to significantly slow …
Multi-threaded programs were able to spoof interactive permission prompt by rewriting the prompt to suggest that program is waiting on user confirmation to unrelated action. A malicious program could clear the terminal screen after permission prompt was shown and write a generic message like so: // Expected prompt ⚠️ ┌ Deno requests read access to "./log.txt". ├ Requested by Deno.open() API ├ Run again with –allow-read to bypass this prompt. …
Deno <=1.14.0 file sandbox does not handle symbolic links correctly. When running Deno with specific write access, the Deno.symlink method can be used to gain access to any directory.
The versions of Deno between release 1.18.0 and 1.20.2 (inclusive) are vulnerable to an attack where a malicious actor controlling the code executed in a Deno runtime could bypass permission checks and execute arbitrary shell code. There is no evidence that this vulnerability has been exploited in the wild. This vulnerability does not affect users of Deno Deploy.
Modules that are dynamically imported through import() or new Worker might have been able to bypass network and file system permission checks when statically importing other modules. In Deno 1.5.x and 1.6.x only programs dynamically importing (especially transitively) untrusted code are affected. In Deno 1.7.x all programs importing (especially transitively) untrusted code are affected. In effect an attacker in control of a (possibly remote) module in a programs module graph …