GHSA-7xh3-mhg9-jcw8
HIGHGHSA-7xh3-mhg9-jcw8 is a high-severity (CVSS 8.1) vulnerability in deno. O3 Security confirms whether GHSA-7xh3-mhg9-jcw8 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Deno: Command Injection via spawnSync & spawn on Windows
Real-World Exposure
denoReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects crates.io packages — download data is not available via public APIs for these ecosystems.
Description
Summary
Deno's node:child_process implementation provided an escapeShellArg() helper used when callers passed shell: true to spawn / spawnSync / exec and friends. On Windows, the helper failed to quote arguments that contained cmd.exe metacharacters such as &, |, <, >, ^, !, (, ), and did not neutralize % (which cmd.exe expands even inside double-quoted strings). An attacker who controlled any portion of an argument passed to such a call could inject arbitrary additional commands into the spawned cmd.exe invocation.
This was the Windows counterpart to CVE-2026-27190, which fixed the same class of bug in the Unix branch of escapeShellArg.
Details
On Windows, child_process with shell: true ran the command via cmd.exe /d /s /c "<command line>". Deno assembled that command line by joining the program name and each argument through escapeShellArg().
The vulnerable check was:
// If no special characters, return as-is
if (!/[\s"\\]/.test(arg)) {
return arg;
}
The regex covered only whitespace, double-quote, and backslash. Any argument containing cmd.exe-significant characters but none of those three was returned unquoted and therefore interpreted by the shell. The most straightforward exploit chained commands with &:
import { spawnSync } from "node:child_process";
spawnSync("echo", ["test&calc.exe"], { shell: true, encoding: "utf-8" });
The reporter confirmed this launched calc.exe on Windows 11 with Deno 2.7.5. The same shape worked for |, <, >, ^, !, (, and ).
A secondary defect existed even when arguments were quoted: cmd.exe expands %FOO% environment-variable references inside double-quoted strings. Without either doubling % or rejecting it, an argument like "%USERPROFILE%" leaked environment data into the command line.
Proof of concept
From the report, run on Windows with Deno < 2.7.10:
import { spawnSync } from "node:child_process";
const maliciousInput = "test&calc.exe";
const result = spawnSync("echo", [maliciousInput], {
shell: true,
encoding: "utf-8",
});
console.log(result);
Observed: calc.exe launched as a side effect of the echo call.
Impact
Any Deno program on Windows that called child_process.spawn / spawnSync / exec (or any shell helper that funneled through escapeShellArg) with shell: true and incorporated untrusted input into an argument was exposed to arbitrary command execution in the context of the Deno process. The CVSS vector treated this as network-reachable / high-complexity because the typical exposure path was a Deno service accepting external input and forwarding it to a shelled-out subprocess.
Not affected:
- Calls without
shell: true(the default), which executed the program directly viaCreateProcesswithoutcmd.exeinterpretation. - Unix platforms, which used the single-quote branch of
escapeShellArgand were already fixed under CVE-2026-27190. - Callers that built command strings themselves and passed them as a single string with
shell: true— those were the caller's responsibility and were never sanitized by Deno.
Workarounds
Users on unpatched versions could mitigate by:
- Avoiding
shell: trueinnode:child_processcalls on Windows. - Building the argv directly and invoking the program without a shell.
- Filtering or rejecting any externally-supplied argument values that contained
cmd.exemetacharacters (& | < > ^ ! ( ) %) before passing them tospawn/spawnSync/exec.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🦀crates.io | deno | all versions | 2.7.10 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for deno. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update deno to 2.7.10 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-7xh3-mhg9-jcw8 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-7xh3-mhg9-jcw8 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-7xh3-mhg9-jcw8. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-7xh3-mhg9-jcw8 in your dependencies?
O3 detects GHSA-7xh3-mhg9-jcw8 across crates.io dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.