OS command injection is one of the highest-impact web vulnerabilities: a single unsanitised parameter can hand an attacker arbitrary command execution on the server. It sits under A03:2021 - Injection in the OWASP Top 10 (CWE-78).
Navigation note. This lesson requires DVWA as an external authorised lab. If DVWA is not yet set up, you can complete lessons 4–6 (SSTI, Path Traversal, and NoSQL Injection) first — they are intermediate, use the bundled NovaCart application, and require no additional tooling. Return here once you have DVWA running via the virtualization-lab-fundamentals lesson.How user input reaches a shell
A shell is the operating-system program that reads and executes commands — on Linux it is usually Bash; on Windows it is cmd.exe or PowerShell. Some web features shell out to operating-system tools — a network page that calls ping, an image feature that calls convert, a backup that calls tar. The flaw appears when the application builds the command as text and hands it to a shell interpreter, for example:
ping -c 1 <user input>If the user input is concatenated straight into that string, any shell metacharacter the user supplies is parsed as shell syntax, not as data. Vulnerable sinks include PHP system(), exec(), and backticks — the most common form in legacy web code. The same anti-pattern exists in Node (child_process.exec()), Python (os.system()), and other server-side languages. You do not need to know any of these languages — the key point is that every major server-side environment has a way to call OS commands, and all of them are vulnerable when user input is concatenated into the command string rather than passed as a separate, quoted argument.
Why the impact is maximal
Successful injection gives Remote Code Execution (RCE) — running arbitrary commands on the server — in the context of the web process: read and exfiltrate files, plant a reverse shell, or pivot (use the compromised server as a stepping stone to attack machines on the same internal network — machines that sit behind a firewall and are not directly reachable from the internet), and harvest credentials. This is why command injection is treated as a critical finding.
What you will do in this lesson
- Recognise how user input flows into a shell sink (the point in code where input meets a shell command).
- Learn the shell metacharacters and the difference between in-band and blind (time-based / out-of-band) detection.
- Locate an injectable parameter in your practice target and submit a working probe.
- Distinguish command injection from neighbouring RCE classes — including SSTI (covered in lesson 4 of this category) and deserialization-RCE — and learn the durable fix.
Prerequisites: linux-command-line-fundamentals (shell commands and metacharacters), sql-injection-data-extraction (injection concepts this lesson builds on directly), and intercepting-proxies (proxy skills for intercepting and modifying requests). You do not need deep programming knowledge, but you should be comfortable running commands in a terminal.
Required external lab. NovaCart has no classic command-injection challenge, so use the DVWA "Command Injection" module or the PortSwigger Web Security Academy OS command injection labs. If you do not already have DVWA, the virtualization-lab-fundamentals lesson shows how to run it in Docker alongside NovaCart — set it up before starting this step.
Estimated time: 10 to 15 minutes.
Scope reminder: practise payloads only in your DVWA lab or an authorised environment such as a PortSwigger Web Security Academy lab. Running command injection against a system you do not own constitutes unauthorised access and is illegal in most jurisdictions.
When you are ready, send the Continue signal.