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-*.
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.
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.