Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
36 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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. Details When establishing a client WebSocket connection, Deno read the Sec-WebSocket-Protocol and Sec-WebSocket-Extensions headers from the server's 101 Switching Protocols response and converted them to strings without handling the failure case. HeaderValue::tostr() returns an error for any value containing bytes outside the visible-ASCII range, so a header carrying such bytes triggered an unrecoverable error during conversion. Because the client initiates the outbound connection, the handshake response is fully controlled by the server. A server that returns bytes such as…
Recommended action: Upgrade to 2.7.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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, a script could still read the file by opening /secrets/passwo\u0308rter.txt (NFD instead of NFC), or /SECRETS/PASSWÖRTER.txt (different case, since default APFS volumes are case-insensitive). Other forms include ligature characters (fi vs fi, ff vs ff, …) and German ß vs ss. The denied path and the requested path differed at the byte level, so Deno's permission check passed; the kernel then resolved them to the same inode and served the file anyway. The same flaw affected --deny-write, --deny-run,…
Recommended action: Upgrade to 2.7.14 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When Deno was run in BYONM mode (nodeModulesDir: "manual"), the module resolver did not validate that a package's resolved entrypoint stayed within its nodemodules/<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 Deno.readTextFileSync(...) call would have been blocked from reading. Details In BYONM mode, Deno resolved npm packages directly from a user-managed nodemodules tree. Resolution of require("pkg") proceeded by reading pkg/package.json, taking the main field, joining it to the package directory, and loading the result as a module. The path joined from main was not constrained to the package root. A package.json such as: resolved to nodemodules/pkg/../../../secret.json, escaping nodemodules entirely. The BYONM permission check…
Recommended action: Upgrade to 2.7.12 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 not re-check after resolution. A caller could therefore pass a numeric alias of an IP address (for example the decimal integer 2130706433 or the hex form 0x7f000001, both of which resolve to 127.0.0.1) and reach the denied destination through node:net.connect or node:http.request's { host, port } options form. The native Deno.connect(), fetch(), and URL-string variants of node:http.request("http://...") were not affected, because they either re-checked permissions after resolution or normalized the hostname…
Recommended action: Upgrade to 2.8.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 true ("probably prime"). The same divergence affected the lower-level opnodecheckprime / opnodecheckprimebytes paths that the polyfill calls into. Node.js itself does not have this problem: it forwards checks = 0 to OpenSSL's BNcheckprime, which substitutes a sensible default number of rounds based on the candidate's bit length (per FIPS 186-4 Appendix C.3 Table C.1). Deno's Rust implementation had no equivalent fallback, so count = 0 meant "skip the loop entirely." Affected APIs - crypto.checkPrime(candidate) (callback form,…
Recommended action: Upgrade to 2.8.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Deno's node:childprocess 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 inject arbitrary additional commands into the spawned cmd.exe invocation. This was the Windows counterpart to CVE-2026-27190, which fixed the same class of bug in the Unix branch of escapeShellArg. Details On Windows, childprocess with shell: true ran the command via cmd.exe /d /s /c "<command line". Deno assembled that command line by joining the program name and each argument through escapeShellArg(). The vulnerable check was: The regex covered only whitespace, double-quote, and backslash. Any argument containing cmd.exe-significant characters…
Recommended action: Upgrade to 2.7.10 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 in that file into the process environment — even when env access is denied. In effect, --allow-read plus a writable or attacker-controlled .env file is enough to defeat --deny-env. Am I affected? You are potentially affected if all of the following are true: 1. You run Deno v2.3.0 or newer. 2. Your program (or any dependency it imports) calls process.loadEnvFile() from node:process. 3. You rely on Deno's permission model — specifically --deny-env, an --allow-env=… allowlist, or running without granting env — as a security boundary.…
Recommended action: Upgrade to 2.8.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. Impact Code running under --deny-net could connect to hosts that the user intended to block. In practice this means network isolation rules — for example, blocking access to localhost or internal services — could be silently circumvented by a malicious or compromised dependency. Deno.connect and fetch() were not affected by this specific issue (a companion advisory covers fetch()). Who is affected Users who: - run untrusted or third-party code with deno run, and - rely on --deny-net to restrict which hosts that code can reach. If you do not use --deny-net, or if you only run fully trusted code, you are not affected. Workaround No…
Recommended action: Upgrade to 2.8.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. Impact Code running under --deny-net could reach hosts that the user intended to block. In practice this means network isolation rules — for example, blocking access to localhost or internal services — could be silently circumvented by a malicious or compromised dependency. A companion advisory covers the same class of issue in the WebSocket API. Who is affected Users who: - run untrusted or third-party code with deno run, and - rely on --deny-net to restrict which hosts that code can reach. If you do not use --deny-net, or if you only run fully trusted code, you are not affected. Workaround No workaround is available short of upgrading. If upgrading…
Recommended action: Upgrade to 2.8.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 the secureConnect event travelled over the network unencrypted. A network attacker positioned to cause the initial connection attempt to fail (for example, by dropping IPv6 traffic on a dual-stack host) could deterministically trigger the fallback path and observe or tamper with traffic that the application believed was TLS-protected. Affected APIs: Applications using Deno's node:tls or node:https surface with autoSelectFamily enabled (the default) that wrote to the socket before the secureConnect event. Proof of concept attacker.mjs…
Recommended action: Upgrade to 2.7.8 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A command injection vulnerability exists in Deno's node:childprocess 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 Details The two-stage argument sanitization in transformDenoShellCommand (ext/node/polyfills/internal/childprocess.ts) has a priority bug: when an argument contains a $VAR pattern, it is wrapped in double quotes (L1290) instead of single quotes (L1293). Double quotes in POSIX sh do not suppress backtick command substitution, allowing injected commands to execute. Attack chain: 1. escapeShellArg wraps the argument in single quotes (safe) 2. opnodeparseshellargs strips the single-quote delimiters during tokenization (raw argument exposed) 3. Re-quoting detects $VAR pattern → applies double quotes 4. Backtick payload inside double…
Recommended action: Upgrade to 2.7.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A command injection vulnerability exists in Deno's node:childprocess implementation. Reproduction Run: deno run --allow-all poc.mjs The file /tmp/rceproof is created, confirming arbitrary command execution. Mitigation All users need to update to the patched version (Deno v2.6.8).
Recommended action: Upgrade to 2.6.8 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.). POC This causes calc.exe to be launched; see the attached screenshot for evidence. Patched in CVE-2025-61787 — prevents execution of .bat and .cmd files: Bypass of the patched vulnerability: Impact The script launches calc.exe on Windows, demonstrating that passing user-controlled arguments to a spawned batch script can result in command-line injection. Mitigation Users should update to Deno v2.5.6 or newer.
Recommended action: Upgrade to 2.5.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. PoC Expected Output Actual Output Mitigations All users should upgrade to Deno v2.6.0 or newer.
Recommended action: Upgrade to 2.6.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Deno versions up to 2.5.1 are vulnerable to Command Line Injection attacks on Windows when batch files are executed. Details In Windows, CreateProcess() always implicitly spawns cmd.exe if a batch file (.bat, .cmd, etc.) is being executed even if the application does not specify it via the command line. This makes Deno vulnerable to a command injection attack on Windows as demonstrated by the two proves-of-concept below. PoC Using node:childprocess (with the env and run permissions): Using Deno.Command.spawn() (with the run permission): Impact Both of these scripts result in opening calc.exe on Windows, thus allowing a Command Line Injection attack when user-provided arguments are passed if the script being executed by the child process is a batch script.
Recommended action: Upgrade to 2.5.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 model. PoC Setup: - pocfile.stat.ts Output: - deno run --deny-read=./ --allow-write=./ pocfile.stat.ts 1 - deno run --deny-read=./ --allow-write=./ pocfile.stat.ts 2 - deno run --deny-read=./ --allow-write=./ pocfile.stat.ts 3 - deno run --deny-read=./ --allow-write=./ pocfile.stat.ts 4 Impact Permission model bypass
Recommended action: Upgrade to 2.5.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 opened, even with read only flags and deny-write permission, it's still possible to change the access (atime) and modification (mtime) times, and thus bypass the permission model. PoC Setup: Output: - deno run --allow-read=./ --deny-write=./ pocfile.utime.ts 1 - deno run --allow-read=./ --deny-write=./ pocfile.utime.ts 2 - deno run --allow-read=./ --deny-write=./ pocfile.utime.ts 3 - deno run --allow-read=./ --deny-write=./ pocfile.utime.ts 4 Impact Permission model bypass
Recommended action: Upgrade to 2.5.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Static imports are exempted from the network permission check. An attacker could exploit this to leak the password file on the network. Details Static imports in Deno are exempted from the network permission check. This can be exploited by attackers in multiple ways, when third-party code is directly/indirectly executed with deno run: 1. The simplest payload would be a tracking pixel-like import that attackers place in their code to find out when developers use the attacker-controlled code. 2. When --allow-write and --allow-read permissions are given, an attacker can perform a sophisticated two-steps attack: first, they generate a ts/js file containing a static import and in a second execution load this static file. PoC Executing a file containing this payload twice, with deno run --allow-read --allow-write would cause the password file to leak on the network, even though no network permission was granted. This vulnerability was fixed with the addition of the --allow-import…
Recommended action: Upgrade to 2.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
It is possible to bypass Deno's read/write permission checks by using ATTACH DATABASE statement. PoC
Recommended action: Upgrade to 2.2.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. PoC The first example using get exits with the following error: The second example using toObject prints all environment variables: Impact Software relying on the combination of both flags to allow access to most environment variables except a few sensitive ones will be vulnerable to malicious code trying to steal secrets using the Deno.env.toObject() method.
Recommended action: Upgrade to 2.2.13 or 2.1.13 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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-. Details Caused by the fast exit logic in #22894. PoC Run the above command expecting no permissions to be passed. Impact This only affects a nonsensical combination of flags, so there shouldn't be a real impact on the userbase.
Recommended action: Upgrade to 2.3.2, 2.2.13 or 2.1.13 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 setaad is also affected, as it is incorporated into the GCM hash (ghash) but this too is not validated, rendering AAD checks ineffective. PoC Impact While discovered through experimentation, authentication failures that should raise errors may be silently ignored.
Recommended action: Upgrade to 2.1.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. Details The right behavior would be to drop the Authorization header instead, in this scenario. The same is generally applied to Cookie and Proxy-Authorization headers, and is done for not only host changes, but also protocol/port changes. Generally referred to as "origin". The documentation states: Deno does not follow the same-origin policy, because the Deno user agent currently does not have the concept of origins, and it does not have a cookie jar. This means Deno does not need to protect against leaking authenticated data cross origin Reproduction
Recommended action: Upgrade to 2.1.2; some affected versions have no fix yet, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 not reflect that this practice should be undertaken to increase the strength of the security sandbox. Impact Users who run code with --allow-read or --allow-write may unexpectedly end up granting additional permissions via file-system operations. Patches Deno 1.43 and above require explicit --allow-all access to read or write /etc, /dev on unix platform (as well as /proc and /sys on linux platforms), and any path starting with \\ on Windows. Workarounds The security sandbox in previous versions of…
Recommended action: Upgrade to 1.43.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Use of raw file descriptors in opnodeipcpipe() leads to premature close of arbitrary file descriptors, allowing standard input to be re-opened as a different resource resulting in permission prompt bypass. Details Node childprocess IPC relies on the JS side to pass the raw IPC file descriptor to opnodeipcpipe(), which returns a IpcJsonStreamResource ID associated with the file descriptor. On closing the resource, the raw file descriptor is closed together. Although closing a file descriptor is seemingly a harmless task, this has been known to be exploitable: - With --allow-read and --allow-write permissions, one can open /dev/ptmx as stdin. This device happily accepts TTY ioctls and pipes anything written into it back to the reader. - This has been presented in a hacking competition (WACON 2023 Quals "dino jail"). - However, the precondition of this challenge was heavily contrived: fd 0 has manually been closed by FFI and setuid() was used to drop permissions and deny access…
Recommended action: Upgrade to 1.39.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.