Threat Intelligence Database

Deno is a JavaScript, TypeScript, and WebAssembly runtime. Prior to 2.7.5, 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. This vulnerability is fixed in 2.7.5.

Deno is a JavaScript, TypeScript, and WebAssembly runtime. Prior to 2.8.1, 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. This vulnerability is fixed in 2.8.1.

Deno is a JavaScript, TypeScript, and WebAssembly runtime. Prior to 2.8.1, 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. This vulnerability is fixed in 2.8.1.

Deno versions prior to 2.8.1 contain a vulnerability where the fetch() function enforces network restrictions based on hostname checks but fails to verify the resolved IP addresses against deny-net rules. This allows an attacker to bypass network restrictions by using a domain name that passes hostname validation but resolves to a denied IP address. The issue is fixed in version 2.8.1.

Deno versions prior to 2.8.1 contain a vulnerability in the node:crypto.checkPrime and crypto.checkPrimeSync functions where no Miller-Rabin primality test rounds are performed if the options.checks parameter is left at its default of 0. This causes certain composite numbers with large prime factors to be incorrectly identified as prime. The issue is fixed in version 2.8.1.

Deno versions prior to 2.8.0 contain an improper access control vulnerability in the Node.js compatibility TCP path. The permission check was performed on the original hostname string before DNS resolution but not after, allowing a caller to bypass restrictions by using numeric IP address aliases. This could enable unauthorized connections to otherwise denied destinations. The issue is fixed in version 2.8.0.

Deno is a JavaScript, TypeScript, and WebAssembly runtime. Prior to 2.7.12, 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 Deno.readTextFileSync(...) call would have been blocked from reading. This vulnerability is fixed in 2.7.12.

Deno is a JavaScript, TypeScript, and WebAssembly runtime. Prior to 2.7.10, 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 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 vulnerability is fixed in 2.7.10.

Deno is a JavaScript, TypeScript, and WebAssembly runtime. Prior to 2.7.14, 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. This vulnerability is fixed in 2.7.14.

Deno versions from 2.0.0 up to but not including 2.7.8 contain a vulnerability in the Node.js TLS compatibility layer. This flaw can cause a TLS client to send application data in plaintext after a connection retry when autoSelectFamily is enabled and the first address-family attempt fails. The issue arises because the socket reinitialization reuses a stale TLS upgrade hook, resulting in the replacement TCP connection not being upgraded to TLS. Consequently, data sent before the secureConnect event is transmitted unencrypted, exposing it to network attackers who can cause the initial connection to fail. This vulnerability is fixed in version 2.7.8.