Deno CVE-2025-61787

Exploitation requires ALL of: (1) the target runs on Windows; (2) a Deno program spawns a batch file (.bat or .cmd) as a child process via Deno.Command or node:child_process; (3) the spawned process receives arguments derived from attacker-controlled input; and (4) the Deno program was granted the 'run' permission (the PoC also uses 'read'/'write' or 'env' as applicable). The root cause is Windows CreateProcess() implicitly invoking cmd.exe for batch files, so injected shell metacharacters in arguments are interpreted. Limiting factors: non-Windows platforms are entirely unaffected; applications that never execute .bat/.cmd files, or that do not pass untrusted data into child-process arguments, are not exploitable; and Deno's permission model must have granted run access.

Signals are mixed and point to a credible but conditional threat rather than a mass-exploitation emergency. The CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:N) yields 8.1 (High) with full C/I/A impact, reflecting that successful exploitation gives arbitrary command execution - but the AC:H explicitly encodes meaningful preconditions (Windows-only, the application must spawn a .bat/.cmd file with attacker-influenced arguments and hold Deno's run permission). A publicly available exploit exists (the GHSA advisory ships two working PoCs that launch calc.exe), which raises practical risk, but this is NOT the same as active exploitation: the CVE is not listed in CISA KEV, so per precision rules the status is 'publicly available exploit code exists,' not in-the-wild use. EPSS of 2.08% (81st percentile) is moderate - elevated relative to most CVEs (consistent with public PoC availability) yet far from the high-probability band, which aligns with the AC:H gating and the narrow Windows-plus-batch-file scope. SSVC framing: exploitation = PoC, technical impact = total, but automatable is questionable because exploitation depends on application-specific use of child-process spawning with untrusted args. Net: a real priority specifically for Windows services/CI that shell out to batch files with external input, but lower urgency for the broad Deno install base that never spawns .bat/.cmd files. One data tension to flag: the 'Microsoft' vendor tag is misleading - Deno is an independent open-source project (Deno Land), not a Microsoft product, even though the flaw is Windows-specific.

A Deno application running on Windows spawns a batch file (e.g. via new Deno.Command('./task.bat', { args: [...] }) or node:child_process spawn) and passes attacker-influenced values into its arguments. Because Windows CreateProcess() implicitly routes .bat/.cmd execution through cmd.exe, an argument such as '&calc.exe' is interpreted as a shell command, yielding arbitrary command execution. A public PoC in the GHSA advisory demonstrates this by launching calc.exe.