Command Injection

Command injection happens when an app builds an OS shell command from untrusted input, so that input runs as commands on the server instead of staying data — full remote code execution. It shares the exact root cause of SQL injection: data treated as code by an interpreter that can’t tell the difference. Attackers frequently reach a vulnerable shell call via SSRF or by dropping a payload through an unrestricted file upload first.

Common Techniques

• Shell metacharacters — ;, |, and ` chain or substitute an extra command onto the intended one.
• Command substitution — $() injects a nested command whose output gets used inline.
• Blind / time-based — no output is shown, so confirm execution with a delay like sleep.
• Out-of-band exfiltration — trigger a DNS or HTTP callback to extract data when there’s no visible output.
• Argument injection — smuggle extra flags into a command the app assembles from parts.
• Chaining to a reverse shell — a working injection point becomes an interactive foothold.

Want to save time on reporting?

Let PentestPad generate, track, and export your reports - automatically.

Book a Demo

Testing

Append shell metacharacter payloads to suspect parameters and watch for delay or output:

; sleep 5
| id

A five-second response delay confirms blind execution; visible uid=... output confirms direct execution. Try both time-based and output-based probes across every parameter that could plausibly reach a shell call, and log the exact payload and evidence in the pentest report.

Remediation

Avoid the shell entirely — call parameterized process APIs directly (execve with an argv array) instead of building a command string, and never pass shell=true-style flags with untrusted input. Strictly allowlist any input that must reach a system call, run the service under a least-privilege account, and disable or remove dangerous binaries the app doesn’t need.