Run external programs without command or argument injection

OS command injection (CWE-78) happens when part of a command line comes from input and a command interpreter parses it. os.system, subprocess.run(..., shell=True), child_process.exec, PHP's shell_exec and Ruby's backticks all pass one string to /bin/sh -c (or cmd.exe /c on Windows). The shell then gives meaning to ;, &&, |, $( ), backticks, redirections, globs and quotes, so a value such as HEAD; touch /tmp/x becomes two commands. The command runs with the application's privileges and environment, which usually means its credentials too.

Escaping the value for the shell can work, but it is fragile: the rules differ between sh, bash and cmd.exe, a value used twice may need escaping twice, and one forgotten call site undoes the rest. The robust fix removes the parser. Every mainstream language can start a program directly with an argument array, which the operating system passes to the program as separate strings that nothing re-parses on Linux and macOS.

The first question in a review is whether you need a program at all. An image library, an archive library, a Git library or a database driver does the work in-process with typed parameters and no command line. The OWASP OS Command Injection Defense Cheat Sheet makes this its primary defense. When you do need a program, the rest of this guide applies to every call. The Python listing below shows the vulnerable form next to the fixed one.

Each runtime has a shell form and an argument-array form. Treat the left column as a finding unless the whole command is a constant, and move to the right column. The argument-array forms do not search for or start a shell, so metacharacters in a value reach the program as literal text. They still resolve the executable through PATH unless you give an absolute path, which the environment section covers.

The fixed function below shows every control in this guide in one call: a value that must match a strict pattern, an absolute executable, --end-of-options and a trailing -- so Git reads the value only as a revision, an explicit environment, a timeout and no shell=True. The middle function is the trap: it uses a list, so ; is harmless, yet --output=<file> still makes Git write a file. The tests in the next section prove all three behaviors.

import re
import shutil
import subprocess

# Resolve the program once, at startup, from a fixed search path.
GIT = shutil.which("git", path="/usr/bin:/bin")
if GIT is None:
    raise RuntimeError("git not found in /usr/bin or /bin")

# A branch, tag or commit: no leading dash, no whitespace or shell syntax.
REV = re.compile(r"[A-Za-z0-9][A-Za-z0-9._/-]{0,99}")
CHILD_ENV = {"PATH": "/usr/bin:/bin", "LANG": "C.UTF-8", "GIT_TERMINAL_PROMPT": "0"}

def history_argv_only(repo: str, rev: str) -> str:
    # No shell, but rev can still be read as an option such as --output=<file>.
    return subprocess.run(
        [GIT, "-C", repo, "log", "--oneline", rev], capture_output=True, text=True
    ).stdout


def history(repo: str, rev: str) -> str:
    if not REV.fullmatch(rev):
        raise ValueError("invalid revision")
    result = subprocess.run(
        # --end-of-options: everything after it is a revision, never an option (Git 2.24+).
        # The trailing -- stops Git reading rev as a path.
        [GIT, "-C", repo, "log", "--oneline", "-n", "50", "--end-of-options", rev, "--"],
        capture_output=True,
        text=True,
        env=CHILD_ENV,
        timeout=10,
        check=False,
    )
    if result.returncode != 0:
        raise LookupError("unknown revision")
    return result.stdout

A command-injection test must check what happened, not what was returned: send payloads that would create a marker file, then assert that the file does not exist. Use one payload per class: command chaining (; touch), substitution ($(touch ...)) and an option-shaped value (--output=). Keep the vulnerable variant in the suite so you know the test can fail. Run it with python3 -m unittest -v test_history; all six tests pass on Python 3.14.8 with Git 2.54.0.

class HistoryTest(unittest.TestCase):
    def setUp(self):
        self.tmp, self.repo = make_repo()
        self.marker = os.path.join(self.tmp, "pwned")

    def test_vulnerable_runs_injected_command(self):
        history.history_vulnerable(self.repo, f"HEAD; touch {self.marker}")
        self.assertTrue(os.path.exists(self.marker))

    def test_argv_without_end_of_options_still_takes_an_option(self):
        history.history_argv_only(self.repo, f"--output={self.marker}")
        self.assertTrue(os.path.exists(self.marker))

    def test_fixed_rejects_shell_syntax(self):
        with self.assertRaises(ValueError):
            history.history(self.repo, f"HEAD; touch {self.marker}")
        self.assertFalse(os.path.exists(self.marker))

    def test_fixed_rejects_option_injection(self):
        with self.assertRaises(ValueError):
            history.history(self.repo, f"--output={self.marker}")
        self.assertFalse(os.path.exists(self.marker))

    def test_end_of_options_treats_dash_value_as_revision(self):
        # Even without the pattern check, --end-of-options makes Git refuse it as a revision.
        result = subprocess.run(
            [history.GIT, "-C", self.repo, "log", "--end-of-options", f"--output={self.marker}", "--"],
            capture_output=True, text=True,
        )
        self.assertNotEqual(result.returncode, 0)
        self.assertFalse(os.path.exists(self.marker))

    def test_fixed_returns_history(self):
        self.assertIn("first commit", history.history(self.repo, "HEAD"))


if __name__ == "__main__":
    unittest.main()

Argument injection (CWE-88) needs no shell. Most programs treat any argument that starts with - as an option, and many options run commands, write files or read configuration. CodeQL's js/second-order-command-line-injection query describes the classic case: git ls-remote with a user-supplied URL that starts with --upload-pack runs an arbitrary command, even through execFile with an array. The ruby-git gem had the same flaw in fetch (CVE-2022-25648, fixed in 1.11.0), where the remote name could add flags to git fetch.

Three controls work together. First, reject values that start with - and, better, match the whole value against what it should be: a revision name, a numeric ID, an https:// URL. Second, end option parsing before the first user value: POSIX.1-2024 utility syntax guideline 10 says the first -- marks the end of options and later arguments are operands even if they begin with -. Third, know the program. Git uses -- to separate revisions from paths in commands such as log and diff, so there -- before a revision changes its meaning; Git 2.24 added --end-of-options for this, and it acts as plain -- in commands that have no such distinction. Programs that parse arguments by hand may ignore -- altogether, which is why the pattern check comes first.

Even after --, an operand keeps its meaning to the program. The OWASP cheat sheet points out that every argument after -- is still a URL to curl, so it still fetches whatever the value names; validate the destination as you would for any server-side request (/domains/appsec/secure-features/ssrf-egress-boundaries/). File operands have the same issue: pass a path the server generated, or prefix relative names with ./ so a name such as -rf cannot be read as options by a program that ignores --.

exec and execSync always start a shell; the Node.js documentation says never to pass them unsanitized input. execFile and spawn start the program directly unless you set shell: true. When options.env is set, Node.js looks the program up through options.env.PATH, and with no PATH in that object Unix lookup falls back to /usr/bin:/bin; an absolute path avoids lookup altogether. timeout kills the child when it expires, and maxBuffer (1 MiB by default for execFile) bounds what it can return. Run the tests with node --test; all four pass on Node.js 26.11.1.

import {exec, execFile} from 'node:child_process';
import {promisify} from 'node:util';

const execAsync = promisify(exec);
const execFileAsync = promisify(execFile);

const GIT = '/usr/bin/git'; // absolute: no PATH lookup
const REV = /^[A-Za-z0-9][A-Za-z0-9._/-]{0,99}$/;
const CHILD_ENV = {PATH: '/usr/bin:/bin', LANG: 'C.UTF-8', GIT_TERMINAL_PROMPT: '0'};

// Vulnerable: exec() hands the whole string to /bin/sh.
export async function historyVulnerable(repo, rev) {
  const {stdout} = await execAsync(`git -C ${repo} log --oneline ${rev}`);
  return stdout;
}

export async function history(repo, rev) {
  if (!REV.test(rev)) throw new Error('invalid revision');
  // execFile() runs git directly with an argument array; no shell is involved.
  const {stdout} = await execFileAsync(
    GIT,
    ['-C', repo, 'log', '--oneline', '-n', '50', '--end-of-options', rev, '--'],
    {env: CHILD_ENV, timeout: 10_000, maxBuffer: 1024 * 1024},
  );
  return stdout;
}

Runtime.exec(String) does not start a shell; it splits the string on whitespace with StringTokenizer, so a value with a space becomes extra arguments, and it has been deprecated since Java 18. The usual mistake is worse: new ProcessBuilder("/bin/sh", "-c", cmd) brings the shell back. Build the command from a List, clear environment() and add only what the child needs, read a bounded amount of output and wait with a timeout. Compile and run HistoryTest with javac -d out History.java HistoryTest.java && java -cp out HistoryTest; all four checks pass on OpenJDK 21.0.12.

import java.io.IOException;
import java.nio.charset.StandardCharsets;
import java.nio.file.Path;
import java.util.List;
import java.util.Map;
import java.util.concurrent.TimeUnit;
import java.util.regex.Pattern;

final class History {
  private static final String GIT = "/usr/bin/git"; // absolute: no PATH lookup
  private static final Pattern REV = Pattern.compile("[A-Za-z0-9][A-Za-z0-9._/-]{0,99}");
  static String history(Path repo, String rev) throws IOException, InterruptedException {
    if (!REV.matcher(rev).matches()) throw new IllegalArgumentException("invalid revision");
    ProcessBuilder pb = new ProcessBuilder(List.of(
        GIT, "-C", repo.toString(), "log", "--oneline", "-n", "50", "--end-of-options", rev, "--"));
    Map<String, String> env = pb.environment();
    env.clear(); // start from nothing, then add only what git needs
    env.put("PATH", "/usr/bin:/bin");
    env.put("LANG", "C.UTF-8");
    env.put("GIT_TERMINAL_PROMPT", "0");
    pb.redirectError(ProcessBuilder.Redirect.DISCARD);
    Process p = pb.start();
    // Read a bounded amount of output: at most 1 MiB.
    byte[] out = p.getInputStream().readNBytes(1 << 20);
    if (!p.waitFor(10, TimeUnit.SECONDS)) {
      p.destroyForcibly();
      throw new IOException("git timed out");
    }
    if (p.exitValue() != 0) throw new IllegalArgumentException("unknown revision");
    return new String(out, StandardCharsets.UTF_8);
  }
}

ProcessStartInfo.Arguments is one string that the child parses, so a quote in a value can split it into extra arguments. ArgumentList takes each argument separately and escapes it; Microsoft's documentation says only one of the two may be used. UseShellExecute defaults to false on .NET Core and .NET 5 and later (it was true on .NET Framework), and in that mode the process starts directly from the executable. Clear Environment before adding variables, and kill the process tree on timeout. dotnet run runs the checks; all five pass on the .NET 10.0.112 SDK.

using System.Diagnostics;
using System.Text.RegularExpressions;

static partial class History
{
    const string Git = "/usr/bin/git"; // absolute: no PATH lookup

    [GeneratedRegex("^[A-Za-z0-9][A-Za-z0-9._/-]{0,99}$")]
    private static partial Regex Rev();
    public static async Task<string> HistoryAsync(string repo, string rev)
    {
        if (!Rev().IsMatch(rev)) throw new ArgumentException("invalid revision", nameof(rev));
        var psi = new ProcessStartInfo(Git)
        {
            RedirectStandardOutput = true,
            RedirectStandardError = true,
            UseShellExecute = false,
        };
        // ArgumentList escapes each element; never build the Arguments string from input.
        foreach (var arg in new[] { "-C", repo, "log", "--oneline", "-n", "50", "--end-of-options", rev, "--" })
            psi.ArgumentList.Add(arg);
        psi.Environment.Clear();
        psi.Environment["PATH"] = "/usr/bin:/bin";
        psi.Environment["LANG"] = "C.UTF-8";
        psi.Environment["GIT_TERMINAL_PROMPT"] = "0";

        using var p = Process.Start(psi)!;
        using var cts = new CancellationTokenSource(TimeSpan.FromSeconds(10));
        var stdout = p.StandardOutput.ReadToEndAsync(cts.Token);
        var stderr = p.StandardError.ReadToEndAsync(cts.Token);
        try { await p.WaitForExitAsync(cts.Token); }
        catch (OperationCanceledException) { p.Kill(entireProcessTree: true); throw new TimeoutException("git timed out"); }
        await stderr;
        if (p.ExitCode != 0) throw new ArgumentException("unknown revision", nameof(rev));
        return await stdout;
    }
}

Go's os/exec intentionally does not invoke the system shell or expand globs, so the only shell in a Go program is one you start with sh -c. Two details matter. A nil Cmd.Env gives the child the parent's whole environment, so set it. And since Go 1.19, exec.Command and LookPath no longer resolve a program through an implicit or explicit . entry in PATH; they return an error wrapping exec.ErrDot instead (GODEBUG=execerrdot=0 restores the old behavior, so don't set it). The Go version of the example, exec.CommandContext(ctx, "/usr/bin/git", "-C", repo, "log", "--oneline", "-n", "50", "--end-of-options", r, "--") with cmd.Env set, passed its tests in golang:1.27.2-trixie with --network=none.

An argument array decides how arguments are split, not which program runs or what it inherits. Resolve the executable once at startup from a fixed directory, or configure an absolute path; the Python documentation recommends a fully qualified path for maximum reliability and notes that lookup rules differ by platform. Never let a request choose the program, and never search the current directory: on Windows, CreateProcess looks in the application's directory and the parent's current directory before PATH when the name has no directory.

Pass the child an explicit environment. By default most APIs copy the parent's variables, which hands database passwords and cloud credentials to every tool you start, and lets anyone who can set a variable change what the child loads: LD_PRELOAD and LD_LIBRARY_PATH for the dynamic loader, NODE_OPTIONS for Node.js, PYTHONPATH for Python, BASH_ENV for non-interactive bash, and GIT_SSH_COMMAND or GIT_CONFIG_* for Git. Set PATH to fixed system directories, add the locale and only the variables the tool documents that it needs.

Set the working directory to a directory the application owns, give every call a timeout and an output limit, and kill the whole process tree when the timeout fires. Run tools that handle untrusted files as a separate low-privilege user or in a container with no network; the guide on untrusted documents (/domains/appsec/secure-features/untrusted-document-conversion/) shows the container flags.

Windows has no argument array at the system level: CreateProcess takes one command-line string, and each program splits it itself. Runtimes therefore rebuild a string from your array, quoting it the way the Microsoft C runtime parses arguments, which PHP's documentation states for proc_open arrays. Batch files break that assumption. CreateProcess cannot run a .bat or .cmd file directly, so it is run by cmd.exe, which applies its own parsing rules to the arguments.

In April 2024 CERT/CC published VU#123335: several language runtimes did not escape arguments correctly when the target was a batch file, so an argument could run commands even when the application used the argument-array API with the shell off. CERT/CC credits the report to RyotaK; Node.js's July 2024 advisory calls the issue BatBadBut. The CVE records and vendor advisories establish the fixes in the table. CERT/CC lists Go as not affected and records Erlang's statement that open_port with spawn must not get untrusted input; Python documents that batch files may be parsed by the shell without escaping.

The safe rule is simpler than any escaping: never pass untrusted arguments to a batch file. Replace the batch file with an executable, or pass data through a file or standard input that the script reads as data. Rust's fix shows the right failure mode: Command now returns an InvalidInput error when it cannot escape an argument safely, instead of guessing. Also give the extension explicitly, because a program name without one may resolve to a .bat or .cmd file.

Most features that start a program need a few choices from the user, not a free-form argument. Model them as an enumeration and map each choice to arguments the code owns: a request asks for format=webp, and the code adds -quality 80 -format webp. A value outside the map is rejected before any process starts. ASVS 5.0 V2.2.1 asks for exactly this positive validation, against an allowlist of values or an expected structure.

For identifiers and names, use a strict pattern anchored at both ends, with a length limit and no leading dash, like the revision pattern above, or better, look the identifier up and use the server's own path or ID for it. The OWASP cheat sheet's example pattern, ^[a-z0-9]{3,10}$, shows the shape: no metacharacters, no spaces and a bounded length. A blocklist of characters such as ; and | is not a fix: it misses newlines, $( ), % on Windows and option injection entirely.

ASVS 5.0 also names a related case in V1.2.8: LaTeX processors must not run with --shell-escape, because \write18 would let a document run commands. The same thinking applies to any tool with a scripting or plug-in feature, such as ImageMagick delegates or Ghostscript: switch the feature off in its configuration as well as controlling its arguments.

Search for the shell forms in the table, then confirm each takes only constants. Static analysis follows data from requests into process APIs: CodeQL's queries are py/command-line-injection, js/command-line-injection with js/second-order-command-line-injection for argument injection, java/command-line-injection, cs/command-line-injection, go/command-injection and rb/command-line-injection. Triage each result as the workflow at /domains/appsec/testing/sast-dast-workflow/ describes, and turn each confirmed one into a regression test like the one above.

The tested fix cards at /fix/command-injection/ show the same fix in six stacks (Express, Flask, Spring Boot, ASP.NET Core, Next.js and Go), each with a vulnerable, a fixed and a plausible wrong version and the tests that tell them apart. Shell injection in CI is a different sink: a GitHub Actions expression such as ${{ github.event.issue.title }} inside a run: script is pasted into the shell before it runs; see /domains/supply-chain/ci-cd/github-actions-hardening/. When the input is code rather than a command, as in eval or a template compiled from a string, read /domains/appsec/secure-coding/code-template-injection/.

• Retrying with shell=True when the argument-array call fails: the fallback brings back the injection.
• Building the array by splitting a string, such as cmd.split(" "): a value with a space becomes extra arguments, which is argument injection again.
• Putting -- before a Git revision: Git reads what follows as paths. Use --end-of-options.
• Validating a value and then passing a different, decoded or normalised copy of it to the process.
• Calling sh -c with a constant script and the value as $1: safe only if the script quotes "$1" everywhere, and easy to break in an edit; prefer no shell.
• Logging the full command line with secrets in it, or returning the tool's stderr to the client, which can leak paths and versions.
• Assuming a container makes injection harmless: the process still has the application's credentials and network unless you removed them.

Sources & further reading

The standards, specifications and documentation behind the guidance above. Each is the evidence for a claim on this page; consult it for detail beyond the defaults and versions listed here.

1. OWASP OS Command Injection Defense Cheat Sheet
2. OWASP WSTG: Testing for Command Injection (WSTG-INPV-12). Version 4.2.
3. OWASP ASVS 5.0.0: V1 Encoding and Sanitization. Version 5.0.0.
4. The Open Group Base Specifications: 12.2 Utility Syntax Guidelines. POSIX.1-2024 (IEEE Std 1003.1-2024).
5. Python documentation: subprocess, Security Considerations. Python 3 documentation.
6. Node.js documentation: Child process. Node.js v26.11.1.
7. PHP manual: proc_open
8. CERT/CC VU#123335: Multiple programming languages fail to escape arguments properly in Microsoft Windows. Revision 8, 13 May 2024.
9. Rust blog: Security advisory for the standard library (CVE-2024-24576). 9 April 2024.
10. Node.js: Wednesday, April 10, 2024 Security Releases (CVE-2024-27980). April 2024.
11. Node.js: Monday, July 8, 2024 Security Releases (CVE-2024-36138). July 2024.

Reference information

Checked with Python 3.14.8, Node.js 26.11.1, OpenJDK 21.0.12, .NET SDK 10.0.112, Go 1.27.2, PHP 8.5.11, Ruby 4.0.7 and Git 2.54.0. Windows behavior is from vendor advisories; it was not run.

Tags

InjectionInput validation and parsing

SDLC phase

Development

Role

Developers

ASVS 5.0.0 requirements

v5.0.0-1.2.5 · v5.0.0-1.2.8 · v5.0.0-2.2.1

CAPEC attack patterns

• CAPEC-88 at MITRE
• CAPEC-6 at MITRE
• CAPEC-248 at MITRE

OWASP WSTG v4.2 tests

WSTG-INPV-12

Download this guide as Markdown

Continue exploring