What Is Command Injection?

Command injection is a vulnerability that lets an attacker run operating system commands on a host by supplying input that an application passes to a system shell without separating that input from the command around it. The attacker's commands execute with whatever privileges the application holds.

Code injection, the nearest neighbour and the one it is most often confused with, introduces code that runs inside the application's own runtime, in the language the application is written in. SQL injection sends unintended instructions to a database engine. A command injection vulnerability reaches past the application entirely and issues instructions to the operating system.

How a Command Injection Attack Works

Applications shell out constantly, whether a backup feature calling a compression binary, a network appliance running a ping, or an image pipeline invoking a conversion tool. In each case, the program assembles a command as text and hands the finished string to a shell.

The shell then interprets that string, and it recognizes characters that mean something other than data. A semicolon ends one command and begins another, while a pipe sends the output of one into a second program. Dollar-parenthesis and backtick constructions run a command and substitute whatever it prints. When user-supplied text lands inside the string unescaped, those characters are read as instructions rather than as the hostname or filename the developer expected.

No unusual access is required, since any field that ends up inside a shell command will do, including ones the attacker cannot see, such as a filename recorded during an upload or a value read from a configuration file.

Often the attacker cannot see the result either. In blind command injection, the application returns nothing from the injected command, so confirmation comes indirectly, by making the host pause for a measurable interval or by causing it to resolve a domain the attacker controls. That the evidence has to be manufactured this way is also why the weakness passes functional testing, where a command that runs and returns nothing looks identical to one that never ran.

Command Injection, OS Command Injection, and Argument Injection

Three weakness identifiers cover neighboring cases, and CISA notes that CWE-78 is a child of CWE-77.

Argument injection is the one teams overlook, because separating a command from its arguments defeats CWE-78 while still leaving a program that accepts attacker-chosen flags, some of which change behavior enough to write files or execute a second binary.

How Common Is the Weakness

OS command injection ranks ninth in the 2025 CWE Top 25, which scores weaknesses on frequency as a root cause multiplied by average severity. Cross-site scripting, SQL injection, cross-site request forgery, missing authorization, path traversal, and three memory safety classes all place above it.

Exploitation data reorders that list, because MITRE publishes a count of entries in CISA's Known Exploited Vulnerabilities catalog alongside each weakness, and OS command injection carries 20, the highest figure of any entry in the Top 25. Cross-site scripting, ranked first, carries seven. Attackers pick this weakness far more often than its ranking suggests.

Why Network Edge Devices Keep Failing

CISA and the FBI devoted a Secure by Design Alert to this weakness in July 2024, prompted by campaigns against network edge devices. Three vulnerabilities drove it: in Cisco NX-OS, Palo Alto Networks PAN-OS, and Ivanti Connect Secure, and all three entered the Known Exploited Vulnerabilities catalog. Their access requirements differed more than the alert's summary suggests. The Palo Alto flaw was exploitable without authentication. The Ivanti one required an authenticated administrator on its own and was chained with a separate authentication bypass to remove that condition. The Cisco flaw needed valid administrator credentials outright, and state-linked operators used it anyway.

Edge devices concentrate the risk, since their administrative interfaces expose diagnostic features that wrap system utilities, they sit where they are reachable, and they run with high privilege by design. Their alert describes the cycle of detecting, mitigating, and patching vulnerabilities that have been understood for years as no lasting approach to security, given that mechanisms to prevent the whole class already exist. It sits alongside the other recurring categories in this overview of types of web application attacks.

How to Eliminate a Command Injection Vulnerability

Where a library function performs the task directly, call it and skip the shell entirely. The worked example in the CISA and FBI alert is directory creation in Python, where the language offers a function for the job and no command needs to run at all. Where the work genuinely requires a command, pass its arguments as separate values rather than assembling one string, validate the input before it reaches that call, and limit the user-controlled portion to the minimum the feature requires.

The agencies go further than advice and recommend enforcement at review time, with rules that reject risky invocations outright, including calls that pass a string rather than an array and calls that enable shell interpretation. Guidance a developer can ignore is not the same control as a check that blocks the merge.

Input filtering has a place as defense in depth, but it is the weaker control. Blocklists of dangerous characters are routinely bypassed through encoding, and they leave the unsafe construction in the code for the next developer to extend.

Command injection survives review because the shell call is often several layers below the input that reaches it, and the dangerous path may be one no test exercises. Raven Runtime Prevention judges code by what it does while executing, halting an attempt to spawn an unexpected process before the command runs. See it at Runtime Prevention.