Deno CVE-2025-61785

Exploitation requires attacker-controlled script code executing inside the Deno runtime with read permission (e.g. --allow-read=./) on the target file, even while --deny-write=./ is set and the file is opened with {read: true, write: false}. The exact trigger is calling Deno.FsFile.prototype.utime() or utimeSync() on the resulting file handle, which (unlike Deno.utime/utimeSync) skipped the write-permission check. Limiting factors: the attacker must already be running JavaScript/TypeScript within the Deno sandbox; impact is confined to modifying a file's atime/mtime (no content write, read, or deletion); the file must be openable for reading; and affected versions are only those prior to 2.5.3 and 2.2.15. There is no remote, network-facing, or unauthenticated path.

This is a genuinely low-priority issue, and all available signals agree. The CVSS 3.1 base score is 3.3 (Low) with vector AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N - local attack vector, low complexity, some privilege required, and only a Low integrity impact with no confidentiality or availability effect. EPSS reinforces this: 0.20% probability at the 9th percentile indicates negligible likelihood of broad exploitation. The vulnerability is NOT in CISA KEV (no active-exploitation signal), though publicly available exploit code exists in the form of the working PoC embedded in the GHSA-vg2r-rmgp-cgqj advisory. No SSVC decision data was provided in the input. The signals are consistent rather than conflicting: a published PoC exists but EPSS and the absence of KEV listing both point to this being a security-hardening fix rather than a weaponizable threat. The real-world impact is narrow - it permits altering a file's access/modification timestamps (atime/mtime) despite a --deny-write policy, i.e. a sandbox permission-model bypass (CWE-266, incorrect privilege assignment), not code execution or data disclosure. Note that CVSS PR:L reflects that exploitation presupposes the attacker is already executing script code inside the Deno runtime with read permission, which materially limits severity.

An operator runs an untrusted or semi-trusted Deno script under a hardened policy (--allow-read=./ --deny-write=./), expecting the deny-write flag to block all filesystem mutations. The script opens a file read-only via Deno.open and then calls file.utime()/utimeSync() to silently rewrite the file's atime and mtime, bypassing the permission model. A working PoC demonstrating exactly this is published in the vendor's GHSA advisory.