Deno CVE-2025-61786

Requires executing code inside the Deno runtime (versions < 2.5.3 on the 2.5.x line or < 2.2.15 on the 2.2.x line) under a permission configuration that denies read but grants write - specifically a file opened via Deno.open/openSync with write:true and read:false while --deny-read (or absence of --allow-read) is in effect; the stat bypass works through Deno.FsFile.prototype.stat and statSync (note Deno.stat/statSync are NOT affected, as they correctly enforce allow-read). Limiting factors that reduce real-world risk: the attacker must already have local code execution within the sandbox (AV:L) with at least write permission (PR:L), the leak is confined to file metadata/stats rather than file contents (C:L, I:N, A:N), and it only matters where Deno's --deny-read permission model is relied on as a boundary against untrusted code.

This is a genuinely low-severity issue despite being a security advisory, and the multiple signals agree rather than conflict. The CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N = 3.3 Low) describes a local, low-privilege flaw with only limited confidentiality impact and no integrity or availability impact - consistent with the GHSA description of a metadata-only permission bypass. EPSS reinforces low real-world urgency at 0.19% (8th percentile), and the vulnerability is NOT on the CISA KEV list, so there is no evidence of active exploitation. A public PoC does exist (published in the GHSA advisory itself), but PoC availability is not the same as exploitation in the wild and should not be conflated with it. The attack vector is local (AV:L): exploitation requires already running code inside the Deno runtime, so this is a sandbox/permission-model weakness exploitable only by code the operator chose to execute under a specific restrictive permission set, not a remotely reachable flaw. Net assessment: low priority for most defenders - it matters chiefly to those who rely on Deno's --deny-read permission model as a hard security boundary for untrusted code, where even file-metadata leakage is a trust-boundary violation worth patching.

An operator runs untrusted or semi-trusted third-party code under Deno with write access but read explicitly denied (e.g. --deny-read=./ --allow-write=./), expecting the script cannot learn anything about files it may not read. The malicious script opens a target file for write-only via Deno.open and then calls file.stat()/file.statSync(), retrieving metadata (existence, size, timestamps, file type) despite the deny-read policy. A public PoC demonstrating exactly this is included in the GitHub Security Advisory GHSA-qq26-84mh-26j9.