OS command and code injection

OS command injectionOS command injection: A weakness in which input becomes part of a command line that a shell or the operating system runs, so one value can start a command the author never wrote. MITRE files it as CWE-78. is ninth and code injectioncode injection: A weakness in which input becomes part of text that is compiled and run as code, through eval, new Function, a template built from input or a similar call. MITRE files it as CWE-94. tenth in MITRE’s 2025 CWE Top 25, and the OWASP Top 10:2025 uses a lookup tool as one of the three scenarios of A05 Injection: a domain request parameter pasted into a command line. When a shell reads that line, one value can start a second command that nobody wrote. The cure is the one this module keeps returning to, keeping data out of code: give a program its input as an argument listargument list: The separate arguments handed to a program when it is started, such as echo, checking and a host name. No shell reads them, so a space or a semicolon inside one is only a character in it. that no shell reads.

You will watch a shell split one string into two commands, see why a value that starts with a dash still becomes an option when no shell is involved, test a launcher against a fake shell, replace eval with a small evaluator, and limit what a program can do when it has to run.

A shell reads your string as a program, so pass an argument list

A diagnostics page lets staff type a host name and runs a lookup tool for it. The program below stands in for the tool with echo, so nothing it starts can do any harm. It tries two hosts: an ordinary one, and one followed by a semicolon and a marker, CANARY-2, which a lookup has no use for.

// The same lookup, written two ways, for a host name that staff type into a diagnostics page. echo stands in for the
// real lookup tool, so nothing started here can do any harm.
import { exec, execFile } from 'node:child_process';
import { promisify } from 'node:util';

const viaShell = promisify(exec);
const viaList = promisify(execFile);

const lines = (text) => text.trimEnd().split('\n');

async function lookupWithShellString(host) {
  const { stdout } = await viaShell('echo checking ' + host);
  return lines(stdout);
}

async function lookupWithArgumentList(host) {
  const { stdout } = await viaList('echo', ['checking', host]);
  return lines(stdout);
}

for (const host of ['example.org', 'example.org; echo CANARY-2']) {
  console.log(`host: ${host}`);
  for (const [name, lookup] of [['exec', lookupWithShellString], ['execFile', lookupWithArgumentList]]) {
    const out = await lookup(host);
    console.log(`  ${name.padEnd(8)} printed ${out.length} line${out.length === 1 ? '' : 's'}: ${JSON.stringify(out)}`);
  }
}

host: example.org
  exec     printed 1 line: ["checking example.org"]
  execFile printed 1 line: ["checking example.org"]
host: example.org; echo CANARY-2
  exec     printed 2 lines: ["checking example.org","CANARY-2"]
  execFile printed 1 line: ["checking example.org; echo CANARY-2"]

The ordinary host prints one line both ways. The second host made exec print two lines, checking example.org and then CANARY-2. That second line is OS command injection, which runs commands the author never wrote. Here exec gave the whole string to a shell, and a shell reads ; as the end of one command and the start of another. execFile starts the program itself and passes it two arguments, the second being the host exactly as typed, so the semicolon is only a character in a name. Node’s documentation warns against passing unsanitised input to exec, and gives the same warning for execFile and spawn when their shell option is on. Step through the difference:

A shell does much more than split at ;. It expands variables and wildcards, runs $(...) and backticks, redirects output with > and joins commands with &&, ||, | and line breaks, so no list of forbidden characters is ever complete. In code injection (CWE-94) the reader is not a shell but something that compiles and runs text, such as eval, new Function, or a template engine given a template made from input. It is the same mistake the module has followed since SQL injection, with a different reader at the end, and the defence is the same: do not build the text at all. Use a library call when one exists, and otherwise an argument list with no shell. ASVS 5.0.0 requirement 1.2.5 asks the same of operating system calls: parameterise them, or encode for the command line.

A value that starts with a dash is an option, even without a shell Pro: opens with a Pro, Premium or Ultimate pass