Cybersecurity glossary
What is OS Command Injection?
Learn what OS command injection is, how untrusted input reaches the operating-system command interpreter (CWE-78), how it differs from broader command and argument injection, and how to prevent it.
Definition
OS Command Injection is a vulnerability in which untrusted input is passed to an operating-system command interpreter—such as a Unix shell or Windows cmd/PowerShell—so attackers can execute additional OS commands with the privileges of the application process (commonly tracked as CWE-78).
Why OS command injection matters
When a web feature shells out to ping, convert, or a custom ops script, it crosses from application logic into the host’s command interpreter. If request data rides along in that string, the shell—not your validation—decides what runs. OS Command Injection (CWE-78) is the precise name for that interpreter-level failure.
It is narrower than the everyday phrase “command injection,” which can also mean unsafe command construction in general (CWE-77). The distinction matters for triage: CWE-78 means an OS shell or cmd interpreter executed attacker-controlled command text.
How OS command injection works
App invokes an OS interpreter
Code calls system, popen, shell=True, or sh -c / cmd /c with a constructed string.
User input enters the command line
A hostname, path, or id is concatenated into the string the interpreter will parse.
Shell grammar is hijacked
Metacharacters chain commands, pipe output, or perform substitution under the app user.
Host-level impact follows
File access, reverse shells, credential theft, or lateral movement from the server.
Surfaces that lead to CWE-78
Shell-string APIs
system(), popen(), and shell=True pass one string through bash/cmd for parsing.
Implicit shells
Some language wrappers still spawn sh -c even when developers thought they used argv.
Windows interpreters
cmd.exe and PowerShell metacharacters differ from Unix but yield the same OS RCE class.
Blind OS execution
No command output in HTTP—time delays, DNS, or outbound callbacks confirm success.
Prevention that works
| Control | Notes |
|---|---|
| Never spawn a shell | Use execve-style APIs / argv arrays; avoid system, popen, shell=True, sh -c |
| Fixed executable path | Hard-code the binary path; never take the program name from users |
| Strict allowlists | Validate hostnames, IDs, and enums before they reach process APIs |
| Prefer libraries | Replace CLI wrappers with native libraries when possible |
| Least privilege | Run the service as a non-root user with minimal filesystem and network rights |
| Watch for argument injection | Argv arrays stop CWE-78 but not CWE-88—still terminate options and reject leading dashes |
- Inventory every process spawn that reaches a shell or OS command interpreter.
- Eliminate system/popen/shell=True and explicit sh -c / cmd /c wrappers.
- Pass fixed binaries with explicit argv arrays for remaining process calls.
- Allowlist every user-influenced value that still reaches those APIs.
- Add tests for ; && | ` $() and Windows cmd metacharacter payloads.
- Drop unnecessary OS utilities from production images to reduce post-exploit tools.
- Alert on unexpected child shells (bash, sh, cmd, powershell) under the app user.
- Classify confirmed OS command injection as critical until containment is verified.
The practical takeaway
OS command injection is command injection that specifically reaches the operating-system interpreter (CWE-78). Do not build shell strings. Call fixed binaries with safe argv, allowlist inputs, and treat argument injection as a separate follow-on risk.
If a feature must run a host tool, design a constrained job with no shell—not a template for bash -c.
Related security terms
Command Injection
The broader injection class covering unsafe command construction and shell use.
Argument Injection
Abusing a child program’s option parser without necessarily injecting shell metacharacters.
Code Injection
Injection into the application language runtime rather than the OS interpreter.
Server-Side Include Injection (SSI)
Legacy SSI directives that can reach OS command execution on some servers.
Frequently asked questions
What is OS command injection in simple terms?
The application asks the operating system to run a command built partly from user input. An attacker adds shell syntax so the OS runs their commands with the app’s privileges.
How is OS command injection different from 'command injection'?
Command injection is the umbrella term (often CWE-77). OS command injection (CWE-78) specifically means the payload reaches an OS command interpreter—bash, cmd.exe, PowerShell—not merely a library API named 'command'.
How does it differ from argument injection?
Argument injection (CWE-88) abuses flags and argv parsing of a trusted binary without needing shell metacharacters. OS command injection changes what the shell executes—extra commands, pipelines, substitutions.
Which APIs commonly introduce this risk?
system(), popen(), Runtime.exec with a single string, ProcessBuilder misused with a shell, Python subprocess with shell=True, and any wrapper that runs sh -c or cmd /c on concatenated input.
What characters are dangerous?
Shell metacharacters vary by interpreter but commonly include ; | & $ ` ( ) < > and newlines. Blocklists of a few characters are unreliable across shells and encodings.
What is the primary defense?
Do not invoke a shell. Execute a fixed binary with an argv array, allowlist inputs, and prefer in-process libraries over CLI tools.
Do containers eliminate OS command injection?
No. They limit blast radius. Attackers can still steal secrets inside the container, reach internal networks, or abuse mounted credentials.
References
Explore authoritative guidance and frameworks related to os command injection.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.