Command injection, usually referring to OS command injection, is a security vulnerability in which attacker-controlled input changes an operating-system command executed by an application, allowing unintended command behavior or additional commands to run with the application’s privileges, The core trust boundary is straightforward: the attacker influences data, the application turns that data into part of a command or process invocation, and the operating system executes the resulting behavior. The danger comes from mixing untrusted data with command syntax or executable arguments without keeping the two safely separated, This guide treats command injection as a specific command-execution weakness rather than a generic label for every vulnerability that can lead to code execution. It covers OS command injection, shell and argument boundaries, direct and blind execution, second-order behavior, detection evidence, scanner limitations, and prevention.
Classification noteMITRE classifies OS command injection as CWE-78, a child of the broader CWE-77 Command Injection category. The OWASP Top 10:2025 maps command injection, OS command injection, and argument injection under A05: Injection.
What Is Command Injection?
Command injection is a vulnerability where untrusted input changes a command that an application sends to another command-processing component, most commonly the operating system or a system shell.
In web applications, the most important form is OS command injection. It appears when data from a request, API parameter, form field, header, file, integration, or another untrusted source becomes part of an operating-system command without sufficient separation and validation.
Successful command injection can let an attacker execute actions with the privileges of the vulnerable application process. The attacker does not automatically receive administrator or root privileges; the impact depends heavily on what the application account can read, modify, execute, and reach.
| Entity | Role in Command Injection |
|---|---|
| Untrusted input | Data an attacker can influence |
| Command construction | Application logic combines fixed command syntax with variable data |
| Process execution API | Starts a program or sends a command for execution |
| Shell or command interpreter | May interpret separators, substitutions, redirection, and other command syntax |
| Application privileges | Define what injected commands can access or modify |
The terms command injection, OS command injection, and shell injection are often used interchangeably in security discussions, but the formal CWE model is broader. CWE-77 is the parent command-injection category, while CWE-78 specifically concerns OS commands and CWE-88 covers argument injection.
Is Command Injection in the OWASP Top 10?
Yes. Command injection is included in the OWASP Top 10:2025 under A05: Injection. OWASP maps CWE-77 Command Injection, CWE-78 OS Command Injection, and CWE-88 Argument Injection to the current Injection category.
This matters because older articles may still refer to A03:2021 Injection. In the current 2025 list, Injection moved to A05, so security reports and educational content should use the current category when discussing OWASP Top 10:2025.
How Does Command Injection Work?
Command injection works when attacker-controlled data reaches command-construction logic and changes how the operating system, shell, or invoked program interprets the intended operation.
- The application receives untrusted input: A request parameter, form value, API field, header, uploaded filename, integration response, or another external value enters the application.
- The application builds a command or process invocation: The application uses the value as part of a command string, executable selection, argument list, or option set.
- The input is not safely separated from control syntax: The application allows the supplied value to influence command structure, command selection, options, or argument boundaries.
- A process or command interpreter executes the result: The vulnerable application launches the command using its own operating-system identity and environment.
- The unintended behavior becomes observable: The effect may appear directly in the response, through a file or application side effect, as a timing difference, or through an authorized out-of-band callback.
Command injection trust boundaryAttacker-controlled data → command construction → process or interpreter → application privileges → unintended operating-system behavior.
A shell is common in command injection, but it is not the only relevant boundary. An application can also become vulnerable when it launches a fixed executable but lets untrusted data change arguments or options in a security-sensitive way.
What Causes Command Injection Vulnerabilities?
Command injection is caused by allowing untrusted data to influence command syntax, executable selection, or security-sensitive arguments without preserving a strict separation between code and data.
The most common design mistake is building a single command string by concatenating trusted command text with untrusted input. Risk also appears when an application invokes a shell unnecessarily, accepts attacker-controlled executable names, or passes unvalidated values into command-line options that change the behavior of the intended program.
Input validation can reduce exposure, but the safest design is to remove the command-processing boundary where possible. If the application can perform the task with a language or framework library instead of an external operating-system command, that removes an entire class of command-parsing risk.
Command Injection Example
A command injection vulnerability can appear when an application concatenates a user-controlled value into a command string and sends that string to a shell or command-execution function.
A simplified vulnerable pattern looks like this:
userValue = request.input
command = "diagnostic-tool " + userValue
runThroughShell(command)The intended behavior is to pass userValue as data to a fixed diagnostic utility. The vulnerability appears if the shell can instead interpret part of that value as command syntax.
A safer design keeps the executable and arguments separate:
validatedValue = validateExpectedFormat(request.input)
runProcess("diagnostic-tool", [validatedValue])The exact secure API depends on the programming language and operating system, but the principle is the same: do not construct a shell command by mixing command syntax with untrusted data.
Why this distinction mattersPassing an argument array can remove shell parsing, but it does not automatically make every argument safe. The invoked program may itself treat attacker-controlled values as options or switches, which is why argument validation still matters.
Where Can Command Injection Vulnerabilities Appear?
Command injection can appear anywhere an application launches operating-system programs or shell commands using data that an attacker can influence.
| Attack Surface | Why Command Execution May Be Used |
|---|---|
| Network diagnostics | Applications may invoke system networking utilities for connectivity or DNS checks |
| File conversion | Backend services may call document, image, video, or media conversion tools |
| Archive processing | Applications may launch compression or extraction programs with user-influenced filenames or options |
| Backup and maintenance features | Administrative functions may wrap operating-system tools or scripts |
| API endpoints | Parameters may flow into process execution, especially in automation or integration services |
| Developer and operations tooling | Build, deployment, CI/CD, monitoring, or support utilities may execute local commands |
| Third-party integrations | Data from another service may reach command-building logic even if it did not originate from a browser request |
| Environment and configuration values | Environment variables, executable paths, configuration values, or stored settings may influence which command or program an application executes |
API security testing should therefore include command-execution paths, not only database and authentication checks. ScanTitan’s guide on how to scan an API for vulnerabilities includes OS command injection as part of payload and injection testing.
What Is the Risk of Command Injection?
The risk of command injection is unauthorized operating-system behavior executed with the privileges of the vulnerable application, which can lead to data exposure, file modification, service disruption, lateral movement, or remote code execution.
| Impact | What Can Happen |
|---|---|
| Unauthorized command execution | The application performs operating-system actions outside the intended feature |
| File access | Commands may read files available to the application process |
| File modification | Writable files or application data may be changed or deleted |
| Service disruption | Processes may be stopped, resources exhausted, or application availability affected |
| Network access | The compromised process may connect to systems reachable from the application environment |
| Remote code execution | A remotely reachable injection point may provide the practical capability to execute commands on the server |
The impact is amplified when the vulnerable process has excessive privileges. This is why least privilege does not fix command injection itself, but it can substantially limit what a successful exploit can do.
CISA and the FBI have specifically warned software manufacturers that OS command injection remains a preventable vulnerability class and cited exploitation of command-injection defects in network edge products as a reason to eliminate the weakness during design and development.
Types of Command Injection
Command injection is commonly described by how execution becomes observable: direct or in-band injection returns visible output, while blind variants require indirect evidence such as timing changes, side effects, or out-of-band interactions.
Direct / In-Band Command Injection
Direct command injection occurs when the effect or output of the unintended command is visible in the application’s normal response. This produces the clearest runtime evidence because the command result is directly associated with the request.
Blind Command Injection
Blind command injection occurs when the command executes but its output is not returned in the normal response. Confirmation requires indirect evidence rather than visible command output.
Second-Order Command Injection
Second-order command injection occurs when attacker-controlled data is stored first and reaches a vulnerable command-execution path later, during a different application process or workflow. The initial request may appear harmless because no command runs immediately. The vulnerability is triggered when a background job, administrative function, file processor, integration, or another component later uses the stored value to construct a command.
Time-Based Command Injection
Time-based command injection is a blind testing pattern where a controlled delay in server-side execution produces a repeatable response-time change. Timing evidence should be reproduced carefully because network latency and application load can otherwise create false positives.
Out-of-Band Command Injection
Out-of-band command injection is a blind pattern where successful execution causes a controlled DNS or HTTP interaction with authorized testing infrastructure. It is useful when execution occurs asynchronously or produces no useful response difference.
What Is Blind Command Injection?
Blind command injection is a command injection vulnerability where the application executes unintended command behavior but does not return the command output in its normal HTTP or API response.
The vulnerability can therefore exist even when the page looks unchanged. Detection focuses on effects that can be correlated with the tested input.
| Evidence | What It Can Show |
|---|---|
| Repeatable timing change | Execution may be affecting server-side processing time |
| Controlled application side effect | A predictable change may indicate that the process executed unintended behavior |
| Controlled DNS interaction | Strong evidence that the server executed behavior capable of making an external lookup |
| Controlled HTTP interaction | Strong evidence of out-of-band execution when the application response remains unchanged |
Out-of-band testing should use infrastructure controlled by the tester and only systems for which testing is authorized.
What Is Argument Injection?
Argument injection is a related command weakness where attacker-controlled input changes the arguments, options, or switches supplied to an intended executable rather than necessarily starting a second command.
MITRE classifies this as CWE-88: Improper Neutralization of Argument Delimiters in a Command. The distinction matters because removing shell metacharacters can prevent classic command chaining while still leaving the invoked program exposed to dangerous attacker-controlled options.
Escaping is not the whole fixKeeping input inside one shell argument can prevent it from becoming a second command, but the intended program may still interpret that argument as a powerful option. Validate arguments against the application’s expected values and use structured process APIs where possible.
Command Injection vs Code Injection: What Is the Difference?
Command injection changes operating-system command execution, while code injection causes attacker-influenced application-language code or code syntax to be interpreted and executed by the application’s runtime.
| Question | Command Injection | Code Injection |
|---|---|---|
| Main target | OS command or process execution | Application/runtime code execution |
| Typical interpreter | Shell, command processor, or invoked executable | Programming-language or dynamic code interpreter |
| Common CWE | CWE-78 for OS command injection | CWE-94 for code injection |
| Can lead to RCE? | Yes | Yes |
Both belong to the broader injection family, but they cross different interpreter boundaries and require different remediation.
Command Injection vs RCE: What Is the Difference?
Command injection is a vulnerability mechanism, while remote code execution (RCE) describes the resulting capability to execute code or commands on a remote system.
A command injection flaw exposed through a remotely accessible web application can therefore result in RCE. However, not every RCE vulnerability is command injection. Remote execution can also result from code injection, insecure deserialization, unsafe file execution, memory-safety flaws, template injection, or other vulnerability classes.
The relationship is:
Command injection vulnerability → successful remote exploitation → command execution capability → RCE outcome
Command Injection vs SQL Injection: What Is the Difference?
Command injection targets operating-system command execution, while SQL injection changes a database query interpreted by a database engine.
| Question | Command Injection | SQL Injection |
|---|---|---|
| Interpreter | Shell, command processor, or OS process boundary | SQL database engine |
| Primary control plane | OS commands and arguments | SQL query syntax |
| Typical impact | OS actions under application privileges | Unauthorized database reads, writes, or query behavior |
| Common CWE | CWE-78 | CWE-89 |
Both are injection vulnerabilities because attacker-controlled data crosses into an interpreter’s control syntax, but the affected interpreter and remediation strategy are different.
What Should a Complete Command Injection Analysis Cover?
A complete command injection analysis should define the vulnerability precisely, distinguish it from related injection classes, cover direct and blind execution paths, explain how second-order and argument injection differ, and separate detection signals from confirmed command execution.
Use the Correct Vulnerability Taxonomy
Command injection should be mapped to the correct security entities rather than treated as a catch-all term for any flaw that can eventually lead to code execution. CWE-77 is the broader command-injection category, CWE-78 covers OS command injection, CWE-88 covers argument injection, and the OWASP Top 10:2025 maps these weaknesses under A05: Injection.
Keep Command Injection Separate From Other Vulnerability Classes
XXE, server-side template injection, insecure deserialization, unsafe file upload, and memory-safety flaws can sometimes lead to command execution, but they are not types of command injection. Command injection specifically concerns untrusted data crossing into a command, process, argument, or operating-system execution boundary.
Cover More Than Visible Command Output
Command injection may be direct, blind, time-based, out-of-band, or second-order. A complete assessment therefore considers immediate response output as well as timing changes, controlled side effects, delayed execution, stored input, and authorized DNS or HTTP callbacks.
Keep the Analysis Focused on the Injection Mechanism
Persistence, privilege escalation, lateral movement, and broader post-exploitation activity are possible consequences after command execution, but they are not part of the vulnerability’s definition. Keeping the article centered on the command-execution boundary makes the cause, evidence, and remediation easier to understand.
Separate Scanner Signals From Confirmed Execution
A scanner should distinguish between attack surface, suspicious behavior, and evidence of actual command execution. A parameter reaching process-related functionality or changing an error is weaker evidence than controlled output, a repeatable timing effect, or a correlated out-of-band callback. This distinction reduces false positives and makes findings more useful for remediation.
How to Find Command Injection Vulnerabilities
Find command injection by identifying every place the application launches a process or shell command, tracing whether untrusted data reaches that execution boundary, and verifying whether controlled input can alter the intended behavior.
- Map process-execution features: Identify code paths that start operating-system programs, invoke shell commands, execute scripts, or wrap administrative utilities.
- Trace untrusted data: Review request fields, API parameters, headers, filenames, uploaded metadata, integration responses, queue messages, and stored values that can reach those code paths.
- Identify the execution model: Determine whether the application invokes a shell, launches a fixed executable directly, allows executable selection, or passes attacker-influenced options and arguments.
- Review separation and validation: Check whether executables and arguments are structurally separated and whether each attacker-influenced value is restricted to the expected format and business meaning.
- Test runtime behavior safely: In an authorized environment, use controlled non-destructive inputs to determine whether the process behavior, response, timing, or out-of-band interactions can be influenced.
- Review source and configuration: SAST, code review, and dependency review can identify risky process-execution APIs and data flows that may be difficult to reach dynamically.
Do not treat a shell-looking error or a slow response alone as confirmation. Strong findings correlate attacker-controlled input with repeatable command behavior or another controlled execution signal.
How to Prevent Command Injection
Prevent command injection by avoiding OS command execution wherever possible, using library APIs instead of shell commands, keeping executables separate from arguments, validating every attacker-influenced argument, and running the application with the least privileges required.
1. Avoid OS Commands Where Possible
Replacing an operating-system command with a language or framework API is the strongest prevention because it removes the command interpreter from the data path. For example, use filesystem, networking, archive, or image-processing libraries directly when they provide the required functionality instead of wrapping shell utilities.
2. Use Safe Library APIs
Prefer APIs that represent operations as typed function calls rather than command strings. Structured APIs reduce the chance that attacker-controlled text will be interpreted as command syntax.
3. Avoid Shell Execution
If an external program must run, invoke the executable directly rather than passing a constructed string through a shell. This removes shell-specific parsing of separators, substitutions, redirection, and related metacharacters.
4. Separate Executables From Arguments
Use process APIs that accept the executable and its arguments as separate values or arrays. Do not concatenate untrusted values into one command string. Structured argument handling is safer, but argument values still require validation because the target program may interpret them as options.
Where the target program supports it, an end-of-options delimiter such as -- can provide an additional safeguard by telling the program to treat following values as operands rather than command-line options. This is defense in depth and does not replace strict argument validation.
5. Allowlist Input
Validate each argument against the smallest set of values, formats, lengths, and characters the feature actually requires. Validation should express the business rule—for example, a hostname, identifier, filename, or predefined operation—not merely remove a list of suspicious characters.
6. Use Context-Specific Escaping Only When Necessary
Escaping should be a fallback when shell execution genuinely cannot be removed, not the first design choice. The correct escaping depends on the operating system, shell, and exact argument context, and escaping a shell argument does not automatically prevent dangerous argument injection into the intended executable.
7. Apply Least Privilege
Run the application under an account that can access only the files, commands, devices, and services it actually needs. Least privilege limits the blast radius if a command-execution bug survives other controls.
8. Restrict Filesystem and Network Access
Use operating-system permissions, containers, sandboxes, network segmentation, and outbound restrictions to limit what a compromised process can reach. These controls are defense in depth and do not replace fixing the injection point.
9. Test Command-Execution Paths
Review and test every feature that launches processes, including background jobs, APIs, file converters, integrations, administrative functions, and maintenance tooling. A safe public endpoint does not protect a separate worker or internal service that constructs commands differently.
Can a WAF Prevent Command Injection?
A WAF can block some recognizable command-injection payloads, but it should not be the primary fix for a command injection vulnerability.
WAF rules can provide useful defense in depth by detecting suspicious request patterns, blocking known metacharacter combinations, and reducing exposure while code is being remediated. However, a WAF does not understand every valid command argument, internal execution path, encoded input, stored value, or non-HTTP data source.
The durable fix is to remove unsafe command construction and preserve a strict separation between untrusted data and executable control syntax.
Can Vulnerability Scanners Detect Command Injection?
Yes. Vulnerability scanners can detect many command injection vulnerabilities when the execution path is reachable and produces observable evidence, while blind or context-dependent cases may require timing analysis, out-of-band monitoring, authenticated testing, SAST, or manual review.
| Detection Method | Best At | Main Limitation |
|---|---|---|
| DAST | Runtime command injection where a request produces direct or repeatable behavior | May miss unreachable, asynchronous, or deeply authenticated execution paths |
| Authenticated DAST | Administrative, account-only, and API features that launch processes | Coverage depends on reaching the relevant workflow |
| Timing analysis | Blind command injection with repeatable execution delays | Latency and application load can create false positives |
| OAST / OOB testing | Blind and asynchronous execution that can make controlled external interactions | Requires authorized callback infrastructure and reliable correlation |
| SAST / code review | Tracing untrusted input into shell or process-execution APIs | A suspicious data flow does not always prove runtime exploitability |
How Strong Is the Evidence for a Command Injection Finding?
| Observed Behavior | Interpretation |
|---|---|
| Parameter reaches command-related functionality | Attack surface only; not proof of injection |
| Shell-like input changes an error | Interesting signal, but not enough to confirm execution |
| Controlled marker appears in process output | Strong direct evidence of command influence or execution |
| Repeatable controlled delay occurs | Strong blind-execution evidence after timing noise is excluded |
| Controlled DNS or HTTP callback occurs | Strong out-of-band evidence that server-side command behavior was triggered |
| SAST shows untrusted input flowing into a process API | Potential vulnerability requiring contextual validation of execution and controls |
ScanTitan’s Website Vulnerability Scanner can test web applications and APIs for runtime injection weaknesses. For API-specific coverage, see the API security testing guide.
Frequently Asked Questions
What is command injection?
Command injection is a vulnerability where attacker-controlled input changes a command executed by an application, allowing unintended command behavior to run through an operating-system command or process-execution boundary.
What is OS command injection?
OS command injection is the form of command injection in which attacker-influenced data changes an operating-system command. MITRE classifies it as CWE-78.
Is command injection in the OWASP Top 10?
Yes. The OWASP Top 10:2025 includes command injection under A05: Injection and maps CWE-77, CWE-78, and CWE-88 to the category.
What causes command injection?
Command injection is usually caused by mixing untrusted input with command syntax, executable selection, or command-line arguments without keeping data and control information safely separated.
What is blind command injection?
Blind command injection occurs when unintended command behavior executes but its output is not returned in the normal application response. Timing changes, controlled side effects, or authorized out-of-band callbacks can provide evidence.
What is argument injection?
Argument injection occurs when attacker-controlled input changes the arguments, options, or switches supplied to an intended command. It may alter program behavior even when a second shell command cannot be started.
Is command injection the same as RCE?
No. Command injection is a vulnerability mechanism, while RCE describes the capability to execute code or commands on a remote system. A remotely exploitable command injection flaw can result in RCE, but RCE can also arise from other vulnerability classes.
How do you prevent command injection?
Avoid OS commands where possible, use safe library APIs, avoid shells, separate executables from arguments, allowlist expected input, apply least privilege, and test every process-execution path.
Can a WAF stop command injection?
A WAF can block some recognizable command-injection patterns, but it is defense in depth rather than the primary fix. The underlying code should stop mixing untrusted data with executable command syntax.
Can a vulnerability scanner detect command injection?
Yes. DAST can detect many direct command injection flaws, while blind cases may require timing or out-of-band evidence. Authenticated testing, SAST, and manual review can help cover hidden or context-dependent execution paths.
