Description

resolveWindowsConsoleEncoding() executes cmd.exe using a non-absolute executable name and without a timeout/maxBuffer.

Impacts:

• Binary planting / search-order hijack (RCE): On Windows, CreateProcess resolves cmd.exe via the standard search order (application directory, current working directory, system directories, then PATH). If an attacker can influence the working directory or place a malicious cmd.exe earlier in the search order, the library may execute attacker-controlled code.
• Denial of service: spawnSync() is blocking. If the resolved cmd.exe (or chcp) hangs (e.g., via malicious binary, policy restrictions, or environmental issues), the process can block indefinitely because no timeout is set.

Vulnerable code:

const result = spawnSync("cmd.exe", ["/d", "/s", "/c", "chcp"], {
  windowsHide: true,
  encoding: "utf8",
  stdio: ["ignore", "pipe", "pipe"],
});

Recommendation

Avoid search-order resolution and add a bounded execution time.

• Prefer an absolute path to cmd.exe (e.g. via process.env.ComSpec with validation, or %SystemRoot%\\System32\\cmd.exe).
• Add a timeout and a conservative maxBuffer.

Example fix:

import path from "node:path";

function getSystemCmdExe(): string {
  const systemRoot = process.env.SystemRoot || process.env.windir;
  if (systemRoot) {
    return path.join(systemRoot, "System32", "cmd.exe");
  }
  ​// Fallback (still better than relying on CWD); consider hard-failing if missing.
  return process.env.ComSpec || "cmd.exe";
}

const result = spawnSync(getSystemCmdExe(), ["/d", "/s", "/c", "chcp"], {
  windowsHide: true,
  encoding: "utf8",
  stdio: ["ignore", "pipe", "pipe"],
  timeout: 2000,
  maxBuffer: 64 * 1024,
});

If this code can run in elevated/service contexts, consider also setting a safe cwd and sanitizing PATH for this specific call.

Description

The runCommandWithTimeout() helper accumulates all child process stdout/stderr into in-memory Buffer[] arrays and concatenates them at process completion.

• The child output is appended without any size limit (stdoutChunks.push(...), stderrChunks.push(...)).
• On completion, Buffer.concat(stdoutChunks) and Buffer.concat(stderrChunks) allocate contiguous buffers sized to the entire output.
• There is no maxBuffer/output cap, truncation, or early termination when output grows too large.

If an attacker can influence the executed command (or cause a spawned tool/plugin to emit大量 output), they can produce arbitrarily large stdout/stderr quickly and trigger high memory usage / out-of-memory termination (denial of service).

Vulnerable code:

child.stdout?.on("data", (d) => {
  stdoutChunks.push(Buffer.isBuffer(d) ? d : Buffer.from(d));
});
...
stdout: decodeWindowsOutputBuffer({
  buffer: Buffer.concat(stdoutChunks),
  windowsEncoding,
}),

Recommendation

Introduce an explicit output cap (similar to Node's execFile maxBuffer) and stop buffering once the limit is exceeded.

Example approach:

const maxBuffer = options.maxBuffer ?? 1024 * 1024; // 1 MiB default (pick an appropriate default)
let stdoutLen = 0;
let stderrLen = 0;

child.stdout?.on("data", (d: Buffer) => {
  const b = Buffer.isBuffer(d) ? d : Buffer.from(d);
  stdoutLen += b.length;
  if (stdoutLen > maxBuffer) {
    child.kill("SIGKILL");
    return;
  }
  stdoutChunks.push(b);
});

child.stderr?.on("data", (d: Buffer) => {
  const b = Buffer.isBuffer(d) ? d : Buffer.from(d);
  stderrLen += b.length;
  if (stderrLen > maxBuffer) {
    child.kill("SIGKILL");
    return;
  }
  stderrChunks.push(b);
});

Alternatively, stream output to a temporary file or expose a streaming API/callback instead of buffering all output in memory.

Description

The runExec function logs decoded stdout/stderr from executed commands directly when verbose logging is enabled. After this change, output is decoded using Windows code pages (e.g., GBK/Shift-JIS) via decodeWindowsOutputBuffer, which can turn previously-invalid UTF-8 byte sequences into valid text that includes control characters.

This allows a child process (or any untrusted command being executed) to inject:

• ANSI escape sequences (e.g., \x1b]... / \x1b[...m) that may manipulate the terminal (clear screen, move cursor, change colors, set window title, etc.)
• Control characters/newlines that can forge/mislead log output (log injection)

Vulnerable code paths:

• decodedStdout/decodedStderr are derived from raw command output buffers
• Values are passed to logDebug / logError without neutralizing control characters

Vulnerable code:

const decodedStdout = decodeWindowsOutputBuffer({ buffer: stdout, windowsEncoding });
const decodedStderr = decodeWindowsOutputBuffer({ buffer: stderr, windowsEncoding });
if (shouldLogVerbose()) {
  if (decodedStdout.trim()) {
    logDebug(decodedStdout.trim());
  }
  if (decodedStderr.trim()) {
    logError(decodedStderr.trim());
  }
}

Recommendation

Neutralize control characters / ANSI escape sequences before emitting child-process output to terminals or persistent logs.

Option A (safe-by-default for logs): escape non-printables and newlines.

function sanitizeForLog(s: string): string {
  ​// Remove ANSI escapes and other C0 controls except \n/\t if desired.
  ​// Consider a well-tested lib like `strip-ansi` for ANSI removal.
  const withoutAnsi = s.replace(/\x1B\[[0-?]*[ -/]*[@-~]/g, "");
  ​// Replace other control chars (including CR) to prevent log forging.
  return withoutAnsi.replace(/[\x00-\x08\x0B\x0C\x0E-\x1F\x7F\r]/g, (c) =>
    `\\x${c.charCodeAt(0).toString(16).padStart(2, "0")}`,
  );
}

logDebug(sanitizeForLog(decodedStdout.trim()));
logError(sanitizeForLog(decodedStderr.trim()));

Option B (terminal-focused): strip ANSI escapes and disallow OSC sequences too (window-title, hyperlinks), then emit.

Also consider logging output with clear delimiters (prefix each line) to mitigate log forging.