Command injection is a cybersecurity vulnerability that allows an attacker to make an application execute unintended commands. The most common form is operating system command injection, in which unsafe user input reaches a system shell or command-line program.
A vulnerable application may intend to run one harmless system operation, such as checking a network address, resizing an image, or creating a file. If it combines that operation with untrusted input incorrectly, an attacker may be able to change the command or add another instruction.
Successful command injection can give an attacker significant control over the affected server. Depending on the application’s permissions, the attacker may steal data, modify files, install malware, interrupt services, create accounts, or move further into the network.
How Does Command Injection Work?
Applications sometimes call operating system utilities to perform tasks that are not handled directly by their programming language.
Examples include:
- Processing an uploaded image
- Converting a document
- Compressing a file
- Checking network connectivity
- Looking up a domain
- Creating a directory
- Running a backup
- Generating a report
- Managing system services
- Scanning a file
- Retrieving system information
The application may collect a value from a form, URL, API request, file, cookie, or HTTP header and include it in an operating system command.
If the application passes that value to a shell without keeping data separate from command syntax, specially constructed input may change how the shell interprets the instruction.
A typical attack follows this pattern:
- An application accepts user-controlled information.
- The application includes that information in a system command.
- The input is not safely separated from the command structure.
- The operating system interprets part of the input as an instruction.
- The command runs with the privileges of the vulnerable application.
- The attacker observes the output or another effect.
OWASP defines command injection as an attack intended to execute arbitrary commands on the host operating system through a vulnerable application. OWASP’s command injection overview notes that forms, cookies, headers, and other data sources can become injection paths.
Why Is Command Injection Dangerous?
Command injection reaches beyond the normal business logic of an application. Instead of interacting only with the intended feature, the attacker may gain access to the underlying operating system.
Possible consequences include:
- Reading sensitive files
- Stealing application secrets
- Accessing environment variables
- Changing system configurations
- Modifying or deleting data
- Creating unauthorized users
- Installing malicious software
- Downloading additional attack tools
- Disabling security controls
- Interrupting application services
- Using the server to attack other systems
- Stealing cloud credentials
- Moving laterally through a network
- Gaining persistent access
The impact depends heavily on the account running the application. A service running with administrator or root privileges can cause much greater damage than a tightly restricted service account.
Common Types of Command Injection
Direct Command Injection
In a direct attack, the application includes user-controlled input in a system command, and the attacker changes the command’s meaning.
The resulting output may appear directly in the webpage, API response, report, or downloaded file.
Because the attacker receives visible feedback, direct command injection may be easier to identify and exploit.
Blind Command Injection
Blind command injection occurs when the application runs the unintended command but does not return its output.
An attacker may still infer success through:
- Changes in response time
- Application errors
- Outbound network activity
- Newly created or modified files
- Service disruption
- Calls to an external system
- Changes in later application behavior
Blind command injection can be as serious as direct injection even though the output is not displayed.
Argument Injection
Argument injection occurs when an attacker cannot necessarily add a separate command but can manipulate the arguments passed to the intended program.
A command-line option may cause a utility to:
- Read a different file
- Write to an unexpected location
- Change its output format
- Enable a dangerous feature
- Connect to another destination
- Load a configuration
- Overwrite existing information
Separating input into arguments is safer than constructing one shell string, but it does not remove the need to validate each argument.
MITRE tracks argument delimiter problems separately as CWE-88, while operating system command injection is commonly associated with CWE-78.
Second-Order Command Injection
Second-order command injection occurs when unsafe input is stored first and executed later.
For example, an application may save a user-controlled filename or device name. A scheduled job, reporting tool, or administrative function may later place that stored value into a shell command.
The delay between submission and execution can make the vulnerability difficult to identify.
Out-of-Band Command Injection
An out-of-band attack causes the compromised server to communicate through another channel.
The application may not show command output, but an unintended outbound connection can confirm that execution occurred or transfer information away from the system.
Restricting outbound network access can reduce this risk.
What Is the Difference Between Command Injection and Code Injection?
Command injection manipulates commands sent to an operating system shell or command-line utility.
Code injection inserts instructions interpreted by a programming language or runtime.
Both may lead to arbitrary execution, but the vulnerable interpreter is different. Security teams should identify the actual data flow and interpreter rather than treating all execution vulnerabilities as identical.
What Is the Difference Between Command Injection and SQL Injection?
SQL injection manipulates database queries. Command injection manipulates operating system commands.
The target of SQL injection is normally a database engine. The target of OS command injection is a shell or command-line program running on the server.
Both vulnerabilities result from mixing untrusted data with executable instructions. Their prevention strategies share one important principle: keep data separate from commands.
What Is the Difference Between Command Injection and Remote Code Execution?
Remote code execution, or RCE, describes an impact: an attacker can execute code or commands on a remote system.
Command injection is one vulnerability that may produce that impact. Other weaknesses—including unsafe deserialization, memory corruption, vulnerable file uploads, and template injection—may also lead to remote execution.
Not every command injection vulnerability is remotely accessible. Some require authentication, local access, or control over a specific file.
Where Do Command Injection Vulnerabilities Appear?
Common locations include:
- Network diagnostic pages
- Administrative dashboards
- File conversion tools
- Image processing services
- Backup systems
- Monitoring software
- Router interfaces
- Internet of Things devices
- Build and deployment pipelines
- Web hosting panels
- Security scanning tools
- Printer management systems
- Document generators
- Media-processing applications
- Cloud automation platforms
- API integrations
Legacy applications and embedded devices may be especially exposed when they rely heavily on shell commands and run with excessive privileges.
Warning Signs of Command Injection
Users may not notice the attack because execution occurs on the server.
Developers and security teams may observe:
- Unusual shell processes
- Unexpected child processes launched by the web server
- System utilities running under an application account
- Strange files in temporary directories
- Modified configuration files
- New scheduled tasks
- Unknown user accounts
- Outbound connections from the application server
- Requests containing shell-control characters
- Unexpectedly slow responses
- Sudden CPU or memory spikes
- Services stopping or restarting
- Security tools being disabled
- Commands in application or audit logs
- Unexplained file-permission changes
- Large data transfers
- New startup entries or persistence mechanisms
A single unusual process does not prove exploitation. Administrators should compare the event with the application’s normal behavior and investigate the complete activity chain.
What Causes Command Injection?
The root cause is usually unsafe interaction with a command interpreter.
Common development problems include:
- Building shell commands through string concatenation
- Passing raw user input to a shell
- Trusting filenames or stored values
- Incomplete validation
- Relying only on a character blocklist
- Incorrect escaping
- Allowing user-controlled command options
- Using dangerous process-execution functions
- Running services with excessive privileges
- Calling external commands when a library function exists
- Using untrusted environment variables
- Assuming internal users or services are safe
- Failing to review background jobs and scripts
CISA and the FBI have described OS command injection as a preventable vulnerability class and urge manufacturers to eliminate it through secure-by-design development. CISA’s Secure by Design alert explains why these flaws should be addressed at their source.
How Can Developers Prevent Command Injection?
Avoid Calling Operating System Commands
The best defense is to avoid invoking a shell or external command when a safe programming-language library can perform the same task.
For example, an application can use dedicated library functions to:
- Create files and directories
- Resize images
- Compress archives
- Resolve network names
- Manipulate documents
- Read system information
- Send network requests
A library usually exposes a specific operation rather than a general command interpreter. This sharply reduces the attacker’s ability to change what the application does.
OWASP identifies avoiding direct OS command calls as the primary defense. Its OS Command Injection Defense Cheat Sheet recommends built-in library functions wherever possible.
Do Not Invoke a Shell
If an external program must be used, call it through an API that accepts the executable and each argument separately.
Avoid creating a single command string that is then interpreted by a shell.
Removing the shell prevents many control characters from being treated as command separators. However, the application must still validate arguments because the called program may support dangerous options.
Use a Fixed Executable
The application should select the command or executable in server-side code. Users should never be able to choose an arbitrary program or command path.
Use:
- A fixed executable
- An explicit absolute path where appropriate
- A controlled environment
- A minimal set of arguments
- A restricted working directory
Do not search for executable programs using an attacker-influenced environment or path.
Allowlist Valid Inputs
Validate input against the smallest set of acceptable values.
Examples include:
- Converting a numeric value to an integer
- Selecting an operation from a server-side list
- Restricting a hostname to an approved format
- Mapping a user choice to a predefined argument
- Limiting filenames to generated identifiers
- Rejecting unexpected lengths and characters
When practical, the application should accept an identifier rather than a free-form command argument.
Prevent Argument Injection
Even when a shell is not used, an attacker may try to supply command-line options.
Developers should:
- Define the expected number of arguments
- Restrict each argument’s format
- Reject leading option characters when inappropriate
- Use end-of-options markers when the program supports them
- Avoid passing untrusted filenames directly
- Review the called program’s available options
- Use generated internal names
The behavior of the destination program matters as much as the process-launch API.
Apply Context-Specific Escaping Only When Necessary
Sometimes legacy constraints make shell use unavoidable. In those cases, values must be escaped using a trusted, operating-system-specific function.
Escaping should be treated as a less desirable fallback because:
- Shell rules vary by operating system
- Different shells interpret input differently
- Quoting rules are complex
- Character encodings can affect parsing
- Future code changes may break assumptions
- Argument injection may remain possible
Avoid custom escaping functions.
Use Least Privilege
The application should run under a dedicated account with only the permissions needed for its task.
A web service usually should not be able to:
- Install software
- Add system users
- Read all configuration files
- Access unrelated customer data
- Modify security settings
- Control other services
- Reach sensitive internal networks
Least privilege does not fix injection, but it can limit the consequences.
Isolate High-Risk Processing
File conversion, media processing, and other high-risk operations can run inside an isolated environment.
Useful controls include:
- Containers
- Sandboxes
- Restricted operating-system accounts
- Read-only filesystems
- Temporary working directories
- System-call filtering
- Resource limits
- Network isolation
- Short execution timeouts
The isolation boundary must be configured carefully and kept updated.
Restrict Outbound Network Access
A compromised command may attempt to download malware or send stolen data elsewhere.
Application servers should have only the outbound access required for their role. Egress firewalls, proxies, network policies, and segmentation can reduce the attacker’s options.
Control Environment Variables
Process behavior can be influenced by environment variables.
Applications should:
- Use a minimal environment
- Avoid inheriting unnecessary secrets
- Set safe executable search paths
- Prevent users from controlling process variables
- Keep credentials out of environments where possible
- Review locale and configuration variables
Apply Time and Resource Limits
External commands should have:
- Execution timeouts
- Memory limits
- CPU limits
- File-size limits
- Output-size limits
- Process-count limits
- Controlled working directories
These measures can reduce denial-of-service risks and prevent runaway processes.
Why Blocklists Are Not Reliable
A blocklist attempts to reject known dangerous characters or words. This approach is fragile because interpreters support many syntaxes, encodings, separators, substitutions, and environment-specific behaviors.
Blocking one character does not prove the remaining input is safe.
A safer design defines exactly what the application accepts and avoids passing the value through a shell.
Can a Web Application Firewall Prevent Command Injection?
A WAF may detect and block obvious attack patterns, but it cannot reliably understand every command context, encoding, operating system, or application workflow.
Attackers may disguise input or use a valid-looking value that becomes dangerous later.
A WAF is useful as an additional layer, especially during emergency containment, but the application code must be corrected.
How Should Command Injection Be Tested?
Testing must be performed only with authorization and in a controlled environment.
A security review should identify:
- Every process-execution function
- Every system-command call
- User-controlled values reaching those functions
- Background jobs and scheduled scripts
- File-processing pipelines
- Environment variables
- Command-line arguments
- Shell invocation
- Service-account privileges
- Network access available to the process
Static analysis can help trace input into dangerous execution functions. Dynamic testing can reveal behavior not obvious from source code.
Testing should use harmless verification methods and test accounts rather than commands that access sensitive data or disrupt systems.
How Can Organizations Detect Command Injection?
Security teams should monitor both application requests and operating system activity.
Useful controls include:
- Process creation logging
- Endpoint detection and response
- Application audit logs
- Web server logs
- File-integrity monitoring
- Network-flow monitoring
- Container runtime alerts
- Cloud audit logs
- Privilege-escalation detection
- Outbound DNS and proxy logs
High-value alerts include a web application process unexpectedly launching a shell, interpreter, network utility, account-management tool, or package manager.
What Should an Organization Do After Detecting Command Injection?
Isolate the Affected System
Remove the server or workload from untrusted network access. Preserve the ability to collect forensic evidence.
If the application is part of a cluster, prevent compromised instances from communicating with other internal systems.
Disable the Vulnerable Feature
Temporarily remove or restrict the affected endpoint until a proper fix is available.
A WAF or reverse-proxy rule may provide short-term containment, but it should not be treated as a permanent repair.
Preserve Evidence
Collect:
- Process execution records
- Application logs
- Web requests
- Authentication activity
- File changes
- Network connections
- Scheduled tasks
- Running processes
- Memory evidence where appropriate
- Cloud audit events
- Container and orchestration logs
Follow the organization’s incident-response and legal procedures.
Determine What Executed
Investigators should establish:
- Which commands ran
- Which account executed them
- What files were accessed
- Whether malware was installed
- Whether credentials were exposed
- Which systems were contacted
- Whether privileges were increased
- Whether persistence was established
- Whether data left the environment
The absence of visible output does not mean the attack failed.
Rotate Exposed Secrets
Assume that secrets accessible to the compromised process may have been exposed.
Rotate:
- Database passwords
- API tokens
- Cloud credentials
- Signing keys
- Service-account secrets
- Administrative credentials
- Deployment keys
Review the use of old credentials before disabling them where operational continuity requires careful sequencing.
Rebuild Compromised Systems When Necessary
If an attacker achieved operating system command execution, simply deleting one suspicious file may not restore trust.
Rebuild the affected system from a known-good image when integrity cannot be confidently verified. Restore required data from clean, tested backups.
Correct the Vulnerable Code
Replace shell commands with safe libraries whenever possible. If an external process is necessary, use a safe execution API, fixed executable, validated arguments, least privilege, isolation, and outbound restrictions.
Review similar functionality across the product.
Monitor for Continued Activity
After recovery, watch for:
- Reused credentials
- Unusual process execution
- New persistence
- Outbound connections
- Modified accounts
- Unexpected scheduled jobs
- Repeat requests to the vulnerable endpoint
- Movement into other systems
Can Command Injection Affect Cloud Applications?
Yes. A compromised cloud application may access:
- Workload identity credentials
- Cloud storage
- Secrets managers
- Databases
- Deployment systems
- Internal APIs
- Container platforms
The impact depends on the permissions granted to the workload. Cloud identities should follow least privilege, and sensitive administrative access should be separated from public-facing applications.
Does Input Sanitization Completely Prevent Command Injection?
No single sanitization rule works in every command context.
Input validation helps, but the safest approach is to avoid the command interpreter entirely. When that is impossible, applications need safe process APIs, strict allowlists, argument validation, context-specific escaping, least privilege, and isolation.
Can Command Injection Happen Without a Web Browser?
Yes. Any software that passes untrusted input to a command interpreter may be vulnerable.
Potential sources include:
- Desktop applications
- Mobile backends
- APIs
- Network services
- Automation scripts
- Build pipelines
- File processors
- Embedded devices
- Administrative tools
- Local command-line utilities
Is Command Injection the Same as Shell Injection?
The terms are often used interchangeably, but there is a subtle difference.
Shell injection specifically involves input interpreted by a system shell. Command injection can be used more broadly for situations where attackers influence executable commands or their arguments.
In practice, many security advisories use OS command injection for vulnerabilities classified as CWE-78. MITRE’s CWE-78 entry provides the formal weakness classification.
