deno_runtime

A modern runtime for JavaScript and TypeScript.

View on Cargo

View on Github

Activity

Latest release: 1w ago
Total releases: 274
Cadence: ~7 days
Last 12 months: 39

Reach

Downloads: 645.2k
Stars: 108.8k

Details

License: MIT
First release: Dec 13, 2020

Releases

Version	Released
`0.268.0` minor	Oct 21, 2026
`0.267.0` minor	Sep 16, 2026
`0.266.0` minor	Aug 27, 2026
`0.265.0` minor	Aug 06, 2026
`0.264.0` unknown	Jul 23, 2026
`0.263.0` unknown	Jul 15, 2026
`0.262.0` unknown	Jul 08, 2026
`0.261.0` unknown	Jul 01, 2026
`0.260.0` unknown	Jun 25, 2026
`0.259.0` unknown	Jun 11, 2026
`0.258.0` unknown	Jun 03, 2026
`0.257.0` unknown	May 27, 2026
`0.256.0` unknown	May 22, 2026
`0.255.0` unknown	Apr 28, 2026
`0.254.0` unknown	Apr 22, 2026
`0.253.0` unknown	Apr 09, 2026
`0.252.0` unknown	Apr 01, 2026
`0.251.0` unknown	Mar 31, 2026
`0.250.0` unknown	Mar 27, 2026
`0.249.0` unknown	Mar 25, 2026
`0.248.0` unknown	Mar 19, 2026
`0.247.0` unknown	Mar 18, 2026
`0.246.0` unknown	Mar 11, 2026
`0.245.0` unknown	Mar 05, 2026
`0.244.0` unknown	Mar 04, 2026
`0.243.0` unknown	Mar 03, 2026
`0.242.0` unknown	Feb 25, 2026
`0.241.0` unknown	Feb 25, 2026
`0.240.0` unknown	Feb 17, 2026
`0.239.0` unknown	Feb 10, 2026
`0.238.0` unknown	Feb 02, 2026
`0.237.0` unknown	Jan 29, 2026
`0.236.0` unknown	Jan 22, 2026
`0.235.0` unknown	Jan 15, 2026
`0.234.0` unknown	Jan 05, 2026
`0.233.0` unknown	Dec 20, 2025
`0.232.0` unknown	Dec 19, 2025
`0.231.0` unknown	Dec 15, 2025
`0.230.0` unknown	Dec 10, 2025
`0.229.0` unknown	Oct 30, 2025
`0.228.0` unknown	Oct 28, 2025
`0.227.0` unknown	Oct 09, 2025
`0.226.0` unknown	Oct 03, 2025
`0.225.0` unknown	Sep 24, 2025
`0.224.0` unknown	Sep 17, 2025
`0.223.0` unknown	Sep 10, 2025
`0.222.0` unknown	Aug 21, 2025
`0.221.0` unknown	Aug 13, 2025
`0.220.0` unknown	Jul 31, 2025
`0.219.0` unknown	Jul 16, 2025

1–50 of 274

Repository

denoland/deno

Forks: 6.5k
Open issues: 1.3k
Language: Rust
: 5.4/ 10

deno
typescript
javascript
rust

Dependencies (69)

Depends on

0.268.0

Used by

Supply-chain exposure

41 tracked projects depend on this, <1% of every package we track.

A known CVE here directly exposes every one of them.

Known CVEs (6)

CVE-2025-48934 GHSA-7w8p-chxq-2789 Jun 04, 2025

Deno.env.toObject() ignores the variables listed in --deny-env and returns all environment variables

Medium
Network Low None None

Summary

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

export AWS_SECRET_ACCESS_KEY=my-secret-aws-key # Works as expected. The program stops with a "NotCapable" error message echo 'console.log(Deno.env.get("AWS_SECRET_ACCESS_KEY"));' | deno run \ --allow-env \ --deny-env=AWS_ACCESS_KEY_ID,AWS_SECRET_ACCESS_KEY - # All enviroment variables are printed and the --deny-env list is completely disregarded echo 'console.log(Deno.env.toObject());' | deno run \ --allow-env \ --deny-env=AWS_ACCESS_KEY_ID,AWS_SECRET_ACCESS_KEY -

The first example using get exits with the following error:

error: Uncaught (in promise) NotCapable: Requires env access to "AWS_SECRET_ACCESS_KEY", run again with the --allow-env flag console.log(Deno.env.get("AWS_SECRET_ACCESS_KEY")); ^ at Object.getEnv [as get] (ext:deno_os/30_os.js:124:10) at file:///$deno$stdin.mts:1:22

The second example using toObject prints all environment variables:

[Object: null prototype] { ... AWS_SECRET_ACCESS_KEY: "my-secret-aws-key", ... }

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.

Fixed in

0.212.0

References

https://github.com/denoland/deno/security/advisories/GHSA-7w8p-chxq-2789
https://nvd.nist.gov/vuln/detail/CVE-2025-48934
https://github.com/denoland/deno/pull/29079
https://github.com/denoland/deno/commit/2959e083912420988066a001c2b2d6732a1b562f
https://github.com/denoland/deno/commit/946ccda1aa19a00c478a5e6826b75053b050d753
https://docs.deno.com/api/deno/~/Deno.Env.toObject

Updated Sep 10, 2026 · Source: OSV.dev
CVE-2025-48888 GHSA-xqxc-x6p3-w683 Jun 04, 2025

Deno run with --allow-read and --deny-read flags results in allowed

Medium
Network Low None None

Summary

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.

Fixed in

0.212.0

References

https://github.com/denoland/deno/security/advisories/GHSA-xqxc-x6p3-w683
https://nvd.nist.gov/vuln/detail/CVE-2025-48888
https://github.com/denoland/deno/pull/22894
https://github.com/denoland/deno/pull/29213
https://github.com/denoland/deno/commit/2f0fae9d9071dcaf0a689bc7097584b1b9ebc8db
https://github.com/denoland/deno/commit/9d665572d3cd39f997e29e6daac7c1102fc5c04f

Updated Sep 10, 2026 · Source: OSV.dev
CVE-2024-27936 GHSA-m4pq-fv2w-6hrw Mar 05, 2024

Deno's deno_runtime vulnerable to interactive permission prompt spoofing via improper ANSI stripping

8.8 / 10
High
Network Low None Required Unchanged High High High

Summary

A maliciously crafted permission request can show the spoofed permission prompt by inserting a broken ANSI escape sequence into the request contents.

Details

In the patch for CVE-2023-28446, Deno is stripping any ANSI escape sequences from the permission prompt, but permissions given to the program are based on the contents that contain the ANSI escape sequences.

For example, requesting the read permission with /tmp/hello\u001b[/../../etc/hosts as a path will display the /tmp/hellotc/hosts in the permission prompt, but the actual permission given to the program is /tmp/hello\u001b[/../../etc/hosts, which is /etc/hosts after the normalization.

This difference allows a malicious Deno program to spoof the contents of the permission prompt.

PoC

Run the following JavaScript and observe that /tmp/hellotc/hosts is displayed in the permission prompt instead of /etc/hosts, although Deno gives access to /etc/hosts.

const permission = { name: "read", path: "/tmp/hello\u001b[/../../etc/hosts" }; await Deno.permissions.request(permission); console.log(await Deno.readTextFile("/etc/hosts"));

Expected prompt

┌ ⚠️ Deno requests read access to "/etc/hosts". ├ Requested by `Deno.permissions.query()` API ├ Run again with --allow-read to bypass this prompt. └ Allow? [y/n/A] (y = yes, allow; n = no, deny; A = allow all read permissions) >

Actual prompt

┌ ⚠️ Deno requests read access to "/tmp/hellotc/hosts". ├ Requested by `Deno.permissions.query()` API ├ Run again with --allow-read to bypass this prompt. └ Allow? [y/n/A] (y = yes, allow; n = no, deny; A = allow all read permissions) >

Impact

Any Deno program can spoof the content of the interactive permission prompt by inserting a broken ANSI code, which allows a malicious Deno program to display the wrong file path or program name to the user.

Fixed in

0.147.0

References

https://github.com/denoland/deno/security/advisories/GHSA-m4pq-fv2w-6hrw
https://nvd.nist.gov/vuln/detail/CVE-2024-27936
https://github.com/denoland/deno/commit/78d430103a8f6931154ddbbe19d36f3b8630286d
https://github.com/denoland/deno/commit/7e6b94231290020b55f1d08fb03ea8132781abc5
https://github.com/denoland/deno

Updated Sep 10, 2026 · Source: OSV.dev
CVE-2023-33966 GHSA-vc52-gwm3-8v2f May 31, 2023

Missing "--allow-net" permission check for built-in Node modules

8.6 / 10
High
Network Low None None Changed None High None

Impact

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.

Patches

This problem has been patched in Deno v1.34.1 and all users are recommended to update to this version.

Workarounds

No workaround is available for this issue.

Affected versions

0.114.0

Fixed in

0.115.0

References

https://github.com/denoland/deno/security/advisories/GHSA-vc52-gwm3-8v2f
https://nvd.nist.gov/vuln/detail/CVE-2023-33966
https://github.com/denoland/deno
https://github.com/denoland/deno/releases/tag/v1.34.1

Updated Sep 10, 2026 · Source: OSV.dev
CVE-2023-28446 GHSA-vq67-rp93-65qf Mar 24, 2023

Interactive `run` permission prompt spoofing via improper ANSI neutralization

8.8 / 10
High
Network Low None Required Unchanged High High High

Summary

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.

Details

The main entry point comes down to the ability to override what the API control says (40_process.js). Because of ANSI code's ability to clear lines, a malicious program can clear the last 2 lines of the prompt and put their own header. This also works in op_kill.

PoC

This PoC works on 1.31.1, but modified versions of it work on older versions.

Make a file, e.g. index.ts, that uses this vulnerability to spoof the op_spawn_child permission prompt

const boldANSI = "\u001b[1m" // bold const unboldANSI = "\u001b[22m" // unbold const prompt = `┌ ⚠️ ${boldANSI}Deno requests run access to "echo"${unboldANSI} ├ Requested by \`Deno.Command().output()` const moveANSIUp = "\u001b[1A" // moves to the start of the line const clearANSI = "\u001b[2K" // clears the line const moveANSIStart = "\u001b[1000D" // moves to the start of the line Deno[Object.getOwnPropertySymbols(Deno)[0]].core.ops.op_spawn_child({ cmd: "cat", args: ["/etc/passwd"], clearEnv: false, env: [], stdin: "null", stdout: "inherit", stderr: "piped" }, moveANSIUp + clearANSI + moveANSIStart + prompt)

Run the file with deno run index.ts.

Impact

Any Deno program is able to spoof the interactive permission prompt for the op_spawn_child or the op_kill action (which indirectly gives access to all run commands) by overriding the Requested by {message} API with their own ANSI codes, allowing them to clear the latter prompt and change it to whatever they needed:

// Expected Prompt ┌ ⚠️ Deno requests run access to "cat" ├ Requested by `Deno.Command().output()` API ├ Run again with --allow-run to bypass this prompt. └ Allow? [y/n/A] (y = yes, allow; n = no, deny; A = allow all run permissions) > // Actual Prompt ┌ ⚠️ Deno requests run access to "echo" ├ Requested by `Deno.Command().output()` API ├ Run again with --allow-run to bypass this prompt. └ Allow? [y/n/A] (y = yes, allow; n = no, deny; A = allow all run permissions) >

This works with any command on the respective platform, giving the program the full ability to choose what program they wanted to run.

This problem can not be exploited on systems that do not attach an interactive prompt (for example headless servers).

Before v1.31.0, this requires the --unstable flag.

Fixed in

1.31.2

References

https://github.com/denoland/deno/security/advisories/GHSA-vq67-rp93-65qf
https://nvd.nist.gov/vuln/detail/CVE-2023-28446
https://github.com/denoland/deno
https://github.com/denoland/deno/blob/7d13d65468c37022f003bb680dfbddd07ea72173/runtime/js/40_process.js#L175
https://github.com/denoland/deno/releases/tag/v1.31.2

Updated Sep 10, 2026 · Source: OSV.dev
CVE-2023-28445 GHSA-c25x-cm9x-qqgx Mar 23, 2023

Deno improperly handles resizable ArrayBuffer

9.9 / 10
Critical
Network Low Low None Changed High High High

Impact

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.

Patches

The problem has been resolved by disabling resizable ArrayBuffers temporarily in Deno 1.32.1. A future version of Deno will re-enable resizable ArrayBuffers with a proper fix.

Workarounds

Upgrade to Deno 1.32.1, or run with --v8-flags=--no-harmony-rab-gsab to disable resizable ArrayBuffers.

Affected versions

0.102.0

Fixed in

0.103.0

References

https://github.com/denoland/deno/security/advisories/GHSA-c25x-cm9x-qqgx
https://nvd.nist.gov/vuln/detail/CVE-2023-28445
https://github.com/denoland/deno/pull/18395
https://github.com/denoland/deno/pull/18452
https://github.com/denoland/deno
https://github.com/denoland/deno/releases/tag/v1.32.1

Updated Nov 08, 2023 · Source: OSV.dev

Insights

Releases per month

last 12 months

Release mix

minor 4
unknown 270

274 releases

Dependencies over time

per release

Release calendar

2026

Jan

Feb

Mar

Apr

May

Jun

Jul

Aug

Sep

Oct

Nov

Dec

Less More