What is Command Injection?

A command injection vulnerability exists when an application inserts untrusted input into an operating-system command. Attackers can add shell metacharacters or arguments and make the system execute commands that the developer never intended. Depending on the service account, this may expose files, alter data or lead to complete server compromise.

The flaw is often found in features that call external tools: image conversion, archive handling, network diagnostics or administrative scripts. It is related to remote code execution, but the terms are not identical. Command injection is one specific route to executing code.

How can command injection be prevented?

• - Avoid shell commands where a native library or a narrowly scoped API is available.
• - Pass arguments through safe process APIs instead of building a command string.
• - Validate input against a strict allowlist and reject unexpected options or control characters.
• - Run the application with minimal operating-system privileges and isolate risky processing.

Code example: shell string or safe process arguments

Vulnerable:

$host = $_POST['host'];
$result = shell_exec('ping -c 1 ' . $host);

Safer approach with Symfony Process:

$host = filter_var($_POST['host'], FILTER_VALIDATE_IP);
if ($host === false) {
    throw new InvalidArgumentException('Invalid IP address');
}

$process = new Process(['/bin/ping', '-c', '1', $host]);
$process->setTimeout(3);
$process->run();

The argument array bypasses the shell. Type validation also prevents option injection, such as values beginning with a dash. A native networking library is preferable where available.

Why is escaping alone fragile?

Escaping rules differ between shells, operating systems and argument contexts. A filter that blocks a few familiar characters is therefore easy to get wrong. Removing the shell from the data path is considerably safer than trying to recognize every dangerous input.

What does a typical attack look like?

1. The attacker finds a parameter that appears to reach a system tool, such as an IP address passed to ping or a file name used for conversion.
2. Harmless metacharacters, extra options or time delays reveal whether input can change the command structure.
3. After a successful proof, the attacker examines the process privileges, readable files, environment variables and network access.
4. Stolen credentials or a downloaded reverse shell can turn the initial flaw into persistent compromise.

Command injection or argument injection?

Classic command injection adds a new command or shell construct. With argument injection, the application still starts the intended program but gives it attacker-controlled options. This can be just as serious: some tools can read arbitrary files, write output to a chosen location or open network connections through command-line switches. A process API that avoids a shell blocks shell syntax, but does not make dangerous program arguments safe. Allowed options and values therefore need their own strict validation.

How is the weakness tested and detected?

Testing covers query parameters, forms, JSON, headers and stored values that background jobs process later. Time-based proofs or controlled DNS callbacks are normally safer than commands that change files. Source review focuses on string construction around functions such as exec, system and process builders. In production, unexpected child processes, unusual command lines and outbound connections from a web service are useful indicators.

What impact is realistic?

Initial access has the privileges of the affected process. Even a low-privileged web account can often read application configuration, API keys and database credentials. Root processes, mounted Docker sockets or broad cloud roles increase the impact significantly. Least privilege, isolated workers and narrow outbound access limit the blast radius, while the unsafe command construction still has to be fixed in the application.