Advisories for Cargo/Deno package

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 …