OS Command Injection

Command injection takes you straight from web parameter to shell prompt. There is no chaining required, no second-stage payload, no privilege escalation gymnastics — the moment the attacker controls part of a command line that gets handed to a shell, the shell does what shells do. They cluster around image processing, PDF generation, format conversion, ping/whois utilities, and anywhere a developer thought 'I'll just shell out for this one quick thing.' The fix is structural and well-understood, but the bugs persist because shelling out *feels* easier than reaching for a proper library. The attacker, who is fluent in shell metacharacters, disagrees.

OS command injection appears when request input reaches an operating-system command boundary without strict separation between command and data. Severe cases let attackers influence server-side process execution.

Remote code execution as the application user. From there: read every file the user can read (env vars, secrets files, database credentials), exfiltrate over a reverse shell, plant a persistent backdoor, pivot to adjacent services, or — if the host runs unpatched — local privilege escalation to root. On serverless platforms the blast radius is smaller (ephemeral function invocation) but still includes every secret in the function's environment. Ransomware operators love this class of bug because it's a one-shot pivot from public web to internal lateral movement.

Don't shell out at all when a library can do the job. ImageMagick has bindings for every language; same for ffmpeg, pdf-lib, and the rest. Calling out to the shell for `convert` or `gs` is rarely the right shape. When you must execute a binary, pass arguments as an array — `child_process.execFile(cmd, [arg1, arg2])` in Node, `subprocess.run([cmd, arg1, arg2], shell=False)` in Python — never construct a command string. The arguments-as-array form bypasses the shell entirely; the binary's argv parser is far less expressive than `/bin/sh`. As a second layer, validate inputs against a strict allowlist before they reach any subprocess code path. As a third layer, run the subprocess in a least-privileged sandbox — separate Linux user, no shell access, no network egress, read-only filesystem mounts where possible. SELinux / AppArmor profiles cost nothing once you have them. The principle: assume command injection will eventually happen and limit the damage from the inside.

Command injection is one of the few bug classes where 'do it the right way' is shorter to write than 'do it the wrong way safely.' Pass argv arrays. Skip the shell. Treat user input that touches a subprocess as radioactive.