Command Injection is a security vulnerability that occurs when untrusted user input (e.g., from form fields, cookies, or HTTP headers) is passed to a system shell without proper validation or sanitization. This flaw allows attackers to execute arbitrary system commands on the host machine by injecting malicious input into the application’s execution context.

Why is Command Injection Considered a Critical Security Vulnerability?

Command Injection is considered critical because it allows attackers to interact with the host’s underlying operating system directly. Unlike many other vulnerabilities that only expose data or disrupt application logic, command injection can lead to full system compromise.

1. Remote Code Execution (RCE)

Attackers can run arbitrary commands on the target machine.
In many cases, this results in a complete takeover of the system.

2. Privilege Escalation

If the vulnerable application is running with elevated privileges (e.g., root or administrator), attackers can gain unrestricted control of the host.

3. Data Breach and Manipulation

Read, modify, or delete sensitive files.
Exfiltrate credentials, tokens, and configuration data.

4. Pivoting and Lateral Movement

Use the compromised system as a stepping stone to infiltrate other machines on the same network.

5. Service Disruption

Shut down services, terminate processes, or delete critical files to cause denial-of-service conditions.

6. Persistence

Install backdoors, create rogue user accounts, or schedule malicious tasks to maintain long-term unauthorized access.

Real-World Impact and Examples

Command Injection has caused some of the most severe security incidents in history. A well-known example is the Shellshock vulnerability (CVE-2014-6271), where attackers exploited Bash to execute arbitrary commands on millions of Linux-based systems, including web servers, routers, and IoT devices. This flaw allowed remote attackers to take full control of vulnerable machines.

Types of Command Injection

There are majorly two types of Command Injection:

1. Classic Command Injection

The application executes user input inside a system shell and returns the command output to the attacker.

Example effect: attacker appends ; whoami and sees the username in the response.

The application executes injected commands but does not return their output. The attacker detects success via side effects such as response delays, created files, or external callbacks (DNS/HTTP).

Example effect: attacker injects ; sleep 5 and notices a slower response.

Working of Command Injection

Given below the step by step working of Command Injection

User input enters the app: From a form, URL parameter, header, cookie, etc.
App builds a shell command: It concatenates that input into a command string (e.g., ping + userInput).
Command is sent to a shell: The app calls a shell (like /bin/sh or cmd.exe) to run the string.
Shell parses special characters: Metacharacters like ;, &&, |, `...`, or $(...) become control operators, not plain text.
Attacker injects extra commands: By including metacharacters the attacker appends or substitutes commands (e.g., 1.2.3.4; whoami).
Shell executes everything: The original command plus the injected commands run with the app’s privileges.
Attacker observes results or side-effects: Direct output, delays (sleep), or external callbacks (DNS/HTTP) confirm success.
Impact depends on privileges:` If the app runs as a high-privilege user, the attacker can fully compromise the host.

Tools of Command Injection

Here is a compact, useful list of tools commonly used to test for, exploit (in authorized tests), and defend against command injection

Automated/attack tools

Commix: Automated command injection and exploitation tool for web apps. Scans input points, identifies injectable parameters, and supports various payloads and shells. Good for quick discovery in authorized penetration tests.
sqlmap: Primarily an SQL injection tool, but has features to obtain an OS shell via database-backed injection vectors. Useful when DB-to-OS escalation is possible.
Metasploit Framework: Contains modules for exploiting command-injection-like vectors and for post-exploitation once a shell is obtained. Best used in controlled lab/authorized engagements.

Web application security proxies / scanners

Burp Suite: Intercept requests, fuzz parameters (Intruder), replay (Repeater), and use extensions to test command injection. Burp Collaborator can detect out-of-band callbacks.
OWASP ZAP: Open-source proxy/scanner similar to Burp with active scanning and scripting support for custom payloads.
Nikto: Web server scanner that can surface misconfigurations and plugins that sometimes reveal injection opportunities.

Network & reconnaissance tools

Nmap + NSE scripts: Nmap Scripting Engine includes scripts that can reveal vulnerable services or known command injection issues (e.g., some HTTP scripts). Good for initial surface mapping.
curl / wget / netcat (nc): Essential CLI tools to craft requests, test payloads, open reverse shells, or exfiltrate data during tests.

Commix

Commix is a free, open-source Python tool (GitHub) for detecting and exploiting command-/shell-injection flaws in web applications.
It runs on Kali (requires Python) and provides an easy interactive console for testing injectable parameters and executing payloads.
Use Commix only on systems you own or have explicit permission to test — it is designed for authorized security assessments and learning.

Working of Commix

Commix is an open-source tool designed to automate the detection and exploitation of OS command-injection flaws in web applications. It supports testing input vectors such as parameters, HTTP headers, cookies, and authentication fields, and provides a number of enumeration and testing options. Commix can be used to demonstrate two broad classes of command-injection behaviour: result-based (where command output is returned in responses) and blind techniques (where execution is inferred indirectly, for example via timing)

Result Based Command Injection: RBCI or Result Based Command Injection technique is a type of command injection technique in which all commands that the attacker fires in a web application will reflect back to the attacker.
Blind Command Injection Technique: BCIT is a command injection technique where the attacker has not received any reflection back from the browser.

Installation of the commix tool

Step 1: Open your kali Linux operating system and use the following command to install the tool.

cd Desktop
git clone https://github.com/commixproject/commix commix

Step 2: The tool has been installed successfully. Now use the following command to move into the directory of the tool.

cd commix
ls

Step 3: Now you are in the directory of the tool. Use the following command to run the tool.

python3 commix.py

The tool is running successfully. Now we will see examples to use the tool.

Usage

Example 1: Use the commix tool to find out if the domain has command injection vulnerability or not.

--url = URL    Here, the ‘URL’ is the target web address.

Example 2: Use the commix tool to find out if the domain has command injection vulnerability or not using batch flag.

python3 commix.py -u <url> --batch

Example 3: Use the commix tool to find out if the domain has command injection vulnerability or not using --all flag.

python3 commix.py -u <url> --all

Hands on of Command Injection

Below is a step-by-step, hands-on guide for testing and understanding Command Injection (for authorized lab environments only).

Step 1: Set up the environment

Open Burpsuite Community Edition

Step 2: Access the lab

Click on Access the lab in portswigger

IIn Burp Suite: choose the “Temporary in memory” option, then click Next to continue.
Configure FoxyProxy to send browser requests to Burp Suite.

In Burp Suite, open the Proxy tab, go to HTTP history, and find the request that was created when you performed the lab action.

Step 3: Create a baseline request/response

Click “View details” for any product, then forward the intercepted request in Burp.

Click on check stock

In Burp, locate the POST request, send it to Repeater, and you will see the full raw request available for editing and the server’s response panel.

productID=1&storeID=1

Step 4: Check the Vulnerability

Perform a controlled test to verify whether the application is vulnerable.

whoami #

copy the command and press ctrl+U to url encoded and hit send

See the result in response

The server returned “200 OK” and the response contains the test string we submitted. That means the application accepted and used our input , a strong sign of a vulnerability that requires developer remediation.
Turn Intercept off in Burp — the lab should then be marked as solved.

Command Injection