Cybersecurity glossary

What is Command Injection?

Learn what command injection is, how untrusted input alters shell or process execution, how it differs from argument injection, and how to prevent unsafe command construction in applications.

Application securityUpdated August 11, 2026
Also known asShell injectionOS command injectionCommand execution injection

Definition

Command Injection is a vulnerability in which untrusted input is incorporated into an operating-system command or shell invocation so that attackers can alter command structure—running additional commands, changing pipelines, or abusing shell metacharacters with the privileges of the application process.

Why command injection matters

Whenever an application asks the operating system to run a tool, it creates a trust boundary. If that command string includes request data, attackers can smuggle shell syntax and inherit the app’s privileges. Command Injection remains one of the fastest paths from a web parameter to a shell on the server.

Diagnostics pages, file converters, and automation hooks are frequent sources because they feel “ops-adjacent” rather than security-critical—until someone pipes curl to a reverse shell.

How command injection works

1

App builds a command string

User input is concatenated into a shell line or passed to an API that invokes a shell.

2

Attacker inserts shell syntax

Metacharacters split the intended command and append attacker-controlled commands.

3

Shell parses attacker logic

The interpreter executes both the original tool and the injected statements.

4

Host impact follows

Data theft, persistence, lateral movement, or full system compromise.

Injection patterns to recognize

Command chaining

Separators such as ; && || run additional commands after a legitimate tool.

Pipelines and substitution

|, backticks, and $() feed attacker output into other programs.

Out-of-band exfil

Injected curl/nslookup calls send results to attacker-controlled endpoints.

Blind variants

No stdout in the HTTP response—timing, DNS, or callbacks confirm execution.

Prevention that works

ControlNotes
No shell invocationUse execve-style APIs with argv arrays; avoid system/popen/shell=True
Fixed executable pathHard-code the binary; never take the program name from users
Strict allowlistsValidate hostnames, IDs, and enums before they reach any process API
Prefer librariesReplace CLI wrappers with native libraries when possible
Least privilegeRun the service as a non-root user with minimal filesystem rights
Egress controlsLimit outbound network use to reduce reverse-shell usefulness
  • Inventory all process-spawning call sites in application and worker code.
  • Eliminate shell=True / system() / backtick patterns in favor of argv arrays.
  • Allowlist every user-influenced value that still reaches a process API.
  • Add tests that attempt ; && | and substitution payloads on those fields.
  • Drop unnecessary OS tools from production images to reduce post-exploit utility.
  • Alert on unusual child processes spawned by the application user.
  • Review CI jobs and admin scripts—they often share the same anti-pattern.
  • Treat confirmed command injection as critical until proven contained.

The practical takeaway

Command injection happens when untrusted input reshapes a shell or OS command. Do not build command strings. Call fixed binaries with safe argv, allowlist inputs, and keep powerful tools off the application host when you can.

If a feature needs to “ping a host” or “convert a file,” design it as a constrained job—not a free-form shell template.

Related security terms

Frequently asked questions

What is command injection in simple terms?

The application builds a system command using user input. An attacker adds shell punctuation like ;, &&, or backticks so the system runs their commands too.

Is command injection the same as remote code execution?

Successful command injection often yields RCE on the host, but RCE can also come from other bugs (deserialization, code injection). Command injection specifically abuses command/shell construction.

Does using an argv array eliminate command injection?

It removes shell metacharacter risk if no shell is spawned. You can still face argument injection if the child program’s options are attacker-controlled.

Where do these bugs commonly appear?

Ping/traceroute diagnostics, image and document converters, backup jobs, git wrappers, email piping, and any 'run a tool on this user path' feature.

What characters are dangerous?

Shell metacharacters vary by shell but commonly include ; | & $ ` ( ) < > newline and quoted concatenations. Filters that block a short list are unreliable.

What is the primary defense?

Avoid shells. Call programs with fixed executables and explicit argv arrays, allowlist inputs, and prefer libraries over CLI tools.

Can chroot or containers fully fix it?

They limit damage but do not remove the vulnerability. Attackers may still steal app secrets, attack internal networks, or escape weaker sandboxes.

References

Explore authoritative guidance and frameworks related to command injection.

Explore every security definition

Return to the glossary to search by term, alias, starting letter, or security category.

Browse glossary