Commix is capable of detecting and exploiting a wide range of command injection vulnerabilities across various scenarios. These techniques are broadly categorized based on how command execution results are observed by the attacker.

In results-based command injection attacks, the response from the target application directly includes the output generated by the injected command. This immediate reflection of execution results makes these attacks the most straightforward to detect and verify, allowing attackers to receive instant feedback and iterate payloads rapidly. The visible output not only confirms successful injection but often reveals valuable system information, aiding further exploitation.

These techniques are particularly highly effective under the following conditions:

• The application echoes or displays command output verbatim within the HTTP response, providing a clear channel for feedback.
• There is little to no output filtering, sanitization, or encoding that could alter or obscure the injected command’s output, ensuring the attacker receives accurate data.
• The vulnerable injection point is embedded within a system command execution context, where user input is directly passed to shell commands or system calls without adequate validation or escaping.

Under these circumstances, results-based injections enable attackers to execute arbitrary commands with confidence and precision, making them a primary target during penetration testing and automated exploitation efforts.

The classic technique is the most common and direct method of exploiting command injection. It involves injecting malicious payloads using common shell metacharacters such as:

• ; (command separator)
• && (execute next only if previous succeeds)
• || (execute next only if previous fails)
• | (pipe output from one command into another)

These operators allow the attacker to either chain commands after legitimate ones or bypass the original command altogether. When the output is reflected in the web response, the attacker can confirm successful execution immediately.

?id=1;id
?id=1&&whoami
?id=1|uname -a

The Dynamic Code Evaluation technique targets applications that unsafely execute user-supplied input by leveraging built-in language functions designed to evaluate or execute code strings at runtime. Common functions vulnerable to this abuse include eval(), assert(), exec(), and others that parse and run code dynamically within the application’s interpreter environment.

When user input is passed directly and unsafely to these functions without proper validation or sanitization, it allows attackers to inject and execute arbitrary code, leading to full control over the application’s runtime behavior. Unlike traditional command injection, which relies on shell metacharacters and external shell command execution, this technique operates within the language interpreter itself, often bypassing standard command parsing and escaping mechanisms.

Because the injected payload runs inline in the application’s process, typical shell-based delimiters (;, &&, |) are usually unnecessary, enabling more concise and stealthy injections. Additionally, this method can sometimes circumvent common filtering or sanitization techniques aimed at blocking shell metacharacters, making it especially dangerous.

This vulnerability is prevalent in dynamic languages such as PHP, Python, Ruby, and Perl, especially when developers inadvertently pass raw user input to code evaluation functions. The impact ranges from simple command execution to complete remote code execution (RCE), depending on the context and privileges of the vulnerable application.

<?php
  $input = $_GET['cmd'];
  eval($input);  // Unsafe: Directly evaluates user input
?>

Example Payloads

?cmd=system('id')
?cmd=echo shell_exec('uname -a')
?cmd=file_put_contents('/tmp/owned.txt','pwned')

If the output generated by these dynamic evaluation functions is directly echoed or included in the application’s HTTP response, the attacker can immediately observe the results of their injected code execution. This direct feedback loop classifies the attack as a results-based technique, allowing the attacker to quickly verify successful exploitation and iteratively refine payloads for deeper system compromise.

This technique uniquely combines elements of both command injection and code injection. Instead of merely injecting shell commands, the attacker injects code that is executed within the application’s own runtime environment, granting access not only to system-level commands but also to the internal logic and state of the application. This deeper integration significantly increases the attacker’s potential control, enabling them to manipulate application behavior, access sensitive data, or escalate privileges.

This technique blends command injection with aspects of code injection, and when exploited successfully, can offer the attacker significant control over the target system.

When successfully exploited, dynamic code evaluation vulnerabilities can provide attackers with a powerful foothold on the target system, often leading to remote code execution (RCE) and full compromise, depending on the environment’s configuration and security controls.

The well-known Shellshock vulnerability (CVE-2014-6271) affects the Bash shell used by many Unix-like systems.

Shellshock allows remote attackers to execute arbitrary commands by injecting malicious function definitions into environment variables, such as:

• User-Agent
• Referer
• Cookie
• Host

When vulnerable CGI scripts or other Bash-executing services process these headers, the injected commands get executed.

User-Agent: () { :; }; /bin/bash -c 'id'

This technique can lead to unauthenticated remote command execution (RCE) and is especially dangerous in web server environments where Bash is exposed via CGI.

In blind command injection scenarios, the target server executes the injected commands, but does not include the output of those commands in the HTTP response. As a result, attackers receive no direct feedback or visible confirmation of successful execution. Instead, they must rely on indirect inference techniques, such as analyzing differences in response times, application behavior, or side effects caused by the injected commands. This lack of explicit output makes blind injections more challenging to exploit, often requiring creative and time-consuming methods to confirm and extract information from the target system.

This method involves injecting delay-inducing commands (e.g., sleep, timeout) and measuring the server's response time.

If the server response is significantly delayed, it indicates successful command execution. This technique is useful for:

• Evaluating true/false conditions
• Extracting information bit-by-bit using conditional logic
• Bypassing output filtering or logging

; sleep 5

Although slower due to its indirect nature, this technique is effective in highly restrictive environments where output channels are blocked or sanitized.

Semi-blind command injections represent a middle ground between classic results-based and blind injection techniques. In these scenarios, the command output is not directly returned in the HTTP response, but attackers find alternative ways to retrieve or infer the results.

This approach involves redirecting the output of injected commands to a file on the server’s filesystem. The attacker then attempts to access this file through the web server or other available means. This technique is effective when the application suppresses direct output but allows writing files to a location served by the web server.

; whoami > /var/www/html/output.txt

If the file is served by the web server, the attacker can retrieve it with:

http://target/output.txt

This technique bridges the gap between blind and classic injections and is useful when:

• Output is suppressed in the HTTP response
• Filesystem write access is available
• Static file retrieval is possible

When the web root (e.g., /var/www/) is not writable, the attacker can use temporary directories like:

• /tmp
• /var/tmp

These directories are usually writable by the web server user (e.g., www-data), allowing attackers to store output there.

However, since these files may not be directly accessible via the web interface, the attacker can combine this method with a time-based readout to infer the contents.

1. Write output to a random temp file:

; whoami > /tmp/X7s9o.txt

2. Check file size via a time-based condition:

; [ $(wc -c < /tmp/X7s9o.txt) -eq 5 ] && sleep 5

By adjusting the length comparison and measuring delays, attackers can extract the contents character-by-character or bit-by-bit, even when they cannot access the file directly.