Deno

Skip to content What this pays This project runs no bounty of its own. sorona.xyz pays you directly on qualified, reproduced findings. Severity │ sorona.xyz pays Critical │ $1,500+ High │ $700+ Medium │ $300+ Low │ $100 / 1 month Claude Max Submit a vulnerability Separately, for a merged upstream patch : up to $5,000 Google Patch Rewards pays for a patch you get accepted upstream and that stays merged, without reverts, for one month, not for the report. Deno sits at Tier 2, where the panel grades a merged patch from $100 for a one-liner up to $5,000 for a complicated, high-impact improvement, entirely at its discretion, and no memory-safety multiplier applies at this tier. Privilege separation and sandboxing work is a named qualifying category, which maps unusually well onto this runtime. Patches must be at least one month and no more than twelve months old, maintainers hold a veto, and sanctions and territory exclusions apply. CVE history 17 Last 12 months 40 Lifetime Code execution 33 % Memory safety 24 % Access control 24 % Info disclosure 14 % Latest advisories Loading the feed Overview Deno is a JavaScript and TypeScript runtime built around a permission model: code gets no filesystem, network, environment or subprocess access unless the operator grants it explicitly. That grant is the product's central security claim. Deno runs untrusted and semi-trusted code precisely because the boundary is supposed to hold: build steps, plugins, user-supplied handlers, edge functions. A permission bypass here costs more than the same bug in a runtime that never promised anything. The project's 66-line security policy routes to a GitHub Security Advisory and carries no reward language of any kind, so sorona.xyz pays you directly on qualified, reproduced findings. In scope The project's security policy names one route, a GitHub Security Advisory on the repository, and draws no boundary narrower than the runtime itself; the patch pathway attaches to the repository the OSS-Fuzz integration names as main_repo The permission system that is the runtime's entire security claim: any path by which code reaches the filesystem, the network, the environment or a subprocess without the grant the operator actually gave The JavaScript and TypeScript execution boundary in full, covering any escape from script into host capability or host process control The Rust core and the ops layer that bridges V8 to the host, where memory-safety defects still appear despite the implementation language Module loading and the remote-import path, where the runtime fetches code over the network and then executes it The FFI and Node-compatibility surfaces, where the permission boundary is crossed deliberately and the checks around it have to be exactly right The standard library and the built-in runtime APIs that scripts call, since those are the code the permission checks sit behind The bundled tooling shipped in the same binary: the test runner, the bundler, the language server and the compile and install subcommands Out of scope V8 itself, which is a separate project already carrying its own funded programme Anything outside the repository the OSS-Fuzz integration names as main_repo : the Tier 2 scope line attaches to that repository and nothing else Findings that assume the operator already granted the permission being abused, which is a configuration choice rather than a bypass One-line fixes for non-exploitable crashes, which the Patch Rewards rules exclude by name along with resource-exhaustion denial of service A patch the maintainers decline, since the reward panel states it will not second-guess a maintainer's decision Most-valued findings A permission bypass that gives unprivileged script filesystem, network or subprocess access it was never granted. That failure voids the runtime's one distinguishing guarantee, and it sits at the top of both the code-execution and access-control classes here Sandbox escape from script into arbitrary host execution, the single highest-consequence outcome this architecture can produce and the largest class in the project's profile A structural hardening of the permission checks across the ops layer rather than a fix at one call site, since Patch Rewards pays most for improvements that prevent future vulnerabilities and names privilege separation and sandboxing as a qualifying category Memory-safety defects at the V8-to-host boundary and in unsafe blocks in the Rust core, at 24% a quarter of this project's history despite the language Abuse of the remote-import and module-loading path to get attacker-controlled code executed with the host's permission set Program rules Submit through sorona.xyz. This project runs no bounty of its own; we validate, coordinate disclosure with the maintainers, and pay you directly. Report through the repository's GitHub Security Advisory channel, which is the only route the project's security policy names and which pays nothing for the report itself Send a detailed, reproducible report with the script and the exact permission flags it was run under; if we can't reproduce it, it isn't eligible Show the bypass against a restrictive permission set. A finding that assumes the operator already granted the access is not a finding If you also want the Google patch money, land the fix upstream yourself and keep it merged without reverts for a month. That is a separate pathway with its own rules The Patch Rewards side is rate-limited to three submissions per person per month, requires patches at least one month and no more than twelve months old, and excludes researchers in sanctioned territories Disclosure Coordinated through a GitHub Security Advisory on the Deno repository, which produces a CVE and credits the reporter when the fix ships in a release. Hold the detail until that advisory publishes. Safe harbor Sorona will not pursue legal action against you for good-faith research submitted to us in line with this policy. We cannot speak for the upstream project, its vendor, or any third party, and we do not grant authorization on their behalf. You are responsible for understanding and following the laws that apply to you, wherever you are, and for staying within any scope the project has defined. Submit a vulnerability