GHSA-7XH3-MHG9-JCW8
Vulnerability from github – Published: 2026-06-16 19:07 – Updated: 2026-06-16 19:07Summary
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": [
{
"package": {
"ecosystem": "crates.io",
"name": "deno"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.7.10"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-49402"
],
"database_specific": {
"cwe_ids": [
"CWE-78"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-16T19:07:44Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "## Summary\n\nDeno\u0027s `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 `\u0026`, `|`, `\u003c`, `\u003e`, `^`, `!`, `(`, `)`, 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.\n\nThis was the Windows counterpart to CVE-2026-27190, which fixed the same class of bug in the Unix branch of `escapeShellArg`.\n\n## Details\n\nOn Windows, `child_process` with `shell: true` ran the command via `cmd.exe /d /s /c \"\u003ccommand line\u003e\"`. Deno assembled that command line by joining the program name and each argument through `escapeShellArg()`.\n\nThe vulnerable check was:\n\n```ts\n// If no special characters, return as-is\nif (!/[\\s\"\\\\]/.test(arg)) {\n return arg;\n}\n```\n\nThe 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 `\u0026`:\n\n```js\nimport { spawnSync } from \"node:child_process\";\n\nspawnSync(\"echo\", [\"test\u0026calc.exe\"], { shell: true, encoding: \"utf-8\" });\n```\n\nThe reporter confirmed this launched `calc.exe` on Windows 11 with Deno 2.7.5. The same shape worked for `|`, `\u003c`, `\u003e`, `^`, `!`, `(`, and `)`.\n\nA 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.\n\n## Proof of concept\n\nFrom the report, run on Windows with Deno `\u003c 2.7.10`:\n\n```js\nimport { spawnSync } from \"node:child_process\";\n\nconst maliciousInput = \"test\u0026calc.exe\";\nconst result = spawnSync(\"echo\", [maliciousInput], {\n shell: true,\n encoding: \"utf-8\",\n});\nconsole.log(result);\n```\n\nObserved: `calc.exe` launched as a side effect of the `echo` call.\n\n## Impact\n\nAny 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.\n\nNot affected:\n\n- Calls without `shell: true` (the default), which executed the program directly via `CreateProcess` without `cmd.exe` interpretation.\n- Unix platforms, which used the single-quote branch of `escapeShellArg` and were already fixed under CVE-2026-27190.\n- Callers that built command strings themselves and passed them as a single string with `shell: true` \u2014 those were the caller\u0027s responsibility and were never sanitized by Deno.\n\n## Workarounds\n\nUsers on unpatched versions could mitigate by:\n\n- Avoiding `shell: true` in `node:child_process` calls on Windows.\n- Building the argv directly and invoking the program without a shell.\n- Filtering or rejecting any externally-supplied argument values that contained `cmd.exe` metacharacters (`\u0026 | \u003c \u003e ^ ! ( ) %`) before passing them to `spawn` / `spawnSync` / `exec`.",
"id": "GHSA-7xh3-mhg9-jcw8",
"modified": "2026-06-16T19:07:44Z",
"published": "2026-06-16T19:07:44Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/denoland/deno/security/advisories/GHSA-7xh3-mhg9-jcw8"
},
{
"type": "PACKAGE",
"url": "https://github.com/denoland/deno"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Deno: Command Injection via spawnSync \u0026 spawn on Windows"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.