Skynet just published an article: CWE-77: Improper Neutralization of Special Elements used in OS Command (Command Injection) – 7312.us and here’s my review of it.
Overall Assessment
Command injection is the easiest of the three topics to cover well because the right answer is structurally simple — don’t let user input touch a shell — and the author lands on that answer clearly and repeatedly. The piece correctly emphasizes argument arrays over string concatenation, calls out the shell-invoking APIs by name, and gets the “shell is an interpreter, not a function call” framing right. The weaknesses are around CWE precision (CWE-77 vs CWE-78), missing modern context (the parade of network appliance RCEs that defined 2023–2025), and oversimplified examples that hide real-world failure modes like argument injection within argv-mode calls.
What the Author Got Right
The central guidance is correct and emphasized strongly: never pass user input to a shell, use argument arrays instead of strings, and shell=False / execFile over system() / exec(). This is the single most important thing to communicate about command injection, and the article does it clearly. The shift from os.system("ping " + host) to subprocess.run(["ping", host], shell=False) is exactly the right pattern to internalize.
The “shell is a language interpreter, not a function call” framing is genuinely useful. This conceptual reframe is what separates developers who write secure code from those who keep getting bitten. The shell parses ;, &&, ||, $(), backticks, >, <, |, globs, brace expansion, parameter expansion, and command substitution — every one of those is a potential injection point if user data flows through it.
The identification of dangerous APIs is accurate: os.system(), subprocess.call(shell=True), backticks, and inline shell invocations. The author correctly notes that the danger is the shell layer, not the function itself.
The dismissal of denylist filtering is correct. Blocking ;, &, and | is a losing game — newlines, $(), backticks, ${IFS}, environment variable tricks, and dozens of other constructs defeat naive character filters. The article rightly points to allowlisting as the alternative.
The “use dedicated libraries instead of shell tools” advice is excellent. Calling an image processing library is structurally safer than shelling out to ImageMagick’s convert (which has its own history of vulnerabilities, e.g., ImageTragick / CVE-2016-3714). This is the architectural fix that eliminates the class of bug rather than mitigating it.
The blind command injection callout is appropriate. DNS callbacks, time-based detection (sleep 10), and outbound connection probes are exactly the techniques attackers use when stdout isn’t returned. This is often missed in beginner articles.
The least-privilege defense-in-depth recommendation is correct. Even if injection happens, a process running as a constrained user in a sandboxed container with read-only filesystem and no network egress to internal resources limits the blast radius significantly.
The PATH manipulation / binary substitution mention is correct and underappreciated. Calling subprocess.run(["ping", host]) without an absolute path can still be exploited if the attacker can control PATH (or if a writable directory appears early in PATH).
What the Author Got Wrong or Underdeveloped
The CWE-77 vs CWE-78 distinction is missing entirely. This is the most significant technical error. CWE-77 is the general “command injection” parent — it covers any context where commands are interpreted (shell, SQL command builders, LDAP query builders, etc.). CWE-78 is specifically “OS Command Injection,” which is what the article actually describes. The article uses the right title text (“OS Command”) but the wrong CWE number for that specific focus. In practice CWE-78 is what scanners, SAST tools, and bug bounty reports cite for the patterns shown here. An article whose entire content is about CWE-78 should not be titled CWE-77.
No real-world CVEs are cited. Command injection drove the most consequential security incidents of 2023–2025: Ivanti Connect Secure (CVE-2024-21887), Fortinet FortiOS, Cisco IOS XE, Palo Alto GlobalProtect, MOVEit, and a long list of network appliance and managed file transfer compromises. Many of these were exactly the pattern the article describes: web management interfaces shelling out to system utilities with user-controlled parameters. Grounding the abstract guidance in any of these would make it stick.
Argument injection within argv-mode calls is not addressed. This is the modern command-injection failure mode that breaks the article’s “Safer” example. execFile("convert", [filename, "output.png"]) looks safe — no shell — but if filename is -write /etc/passwd, convert happily interprets it as a flag. Same with git, curl, tar, find, rsync, ssh, and most CLI tools: they have flags that read files, write files, execute commands, or change behavior, and they can’t tell a flag from a filename without --. The correct pattern is to prefix arguments with -- where supported and to validate that arguments don’t start with -. CVE-2017-1000117 (Git) and CVE-2023-25652 (Git again) are canonical examples. Skipping this means the article’s “Safer” example is itself a vulnerability pattern in real codebases.
The article doesn’t mention specific high-risk tools. find -exec, xargs, tar with --checkpoint-action, rsync -e, ssh ProxyCommand, wget --use-askpass, curl -K, git with core.sshCommand, and PowerShell’s Invoke-Expression all have command-injection-like behaviors even when invoked with argv arrays. Developers who think “I used execFile, I’m safe” are not safe with these tools.
Windows command injection is ignored. The entire article assumes POSIX shell. Windows has different metacharacters (&, &&, ||, |, %var%, ^ for escaping in cmd; backtick, ;, &, |, $() in PowerShell), different quoting rules (CommandLineToArgvW edge cases), and CreateProcess-with-a-single-string parsing quirks that have caused real vulnerabilities (CVE-2024-3094-adjacent Windows argument parsing issues, the Node.js CVE-2024-27980 BatBadBut family). On Windows, even execFile-style APIs can be unsafe with .bat/.cmd files due to how cmd.exe re-parses arguments.
Language-specific landmines aren’t called out. PHP’s passthru, shell_exec, exec, system, backticks, and popen; Ruby’s backticks, system, %x{}, Kernel#exec, and IO.popen (the array form is safe, the string form isn’t, and developers mix them); Python’s subprocess.Popen(shell=True) and the often-missed os.popen, commands.getoutput, and template string passing to subprocess with shell=True; Java’s Runtime.exec(String) which tokenizes weirdly versus Runtime.exec(String[]) which doesn’t; Node.js’s child_process.exec (unsafe, uses shell) vs child_process.execFile/spawn (safer). The article gives generic advice but developers need the language-specific traps.
Containerization and sandboxing get one sentence. In 2026, the right way to run user-influenced subprocesses is in a tight sandbox: a separate container with seccomp filters, no network access, read-only root filesystem, dropped capabilities, and a non-root user. This is the layer that turns “RCE” into “the attacker escaped a sandbox to nothing useful.” The article mentions “isolate execution” once without saying how.
SAST/detection guidance is missing. Semgrep, CodeQL, and similar tools have well-tuned rules for shell=True, string concatenation into exec calls, and template strings flowing to subprocess. A practical article would point readers at concrete tooling to catch this in CI rather than relying on review discipline.
Indirect command injection isn’t mentioned. Sometimes input doesn’t directly reach a shell but reaches a config file, environment variable, or data file that another process later executes. Git hooks, Makefiles, CI YAML, .bashrc-style files, and crontabs all execute attacker-controlled content if you let attackers write to them. This is the pattern behind many supply-chain and CI/CD exploits.
Recommendations for Developers
Building on the article’s correct foundation, here is what I’d add for practitioners:
Default to no subprocess at all. Before reaching for subprocess or child_process, check whether there’s a library that does the job in-process. Image manipulation (Pillow, sharp, Skia) instead of convert. Archive extraction (zipfile, tar libraries) instead of tar. PDF generation (ReportLab, Puppeteer with safe inputs) instead of wkhtmltopdf. Git operations (libgit2 bindings, isomorphic-git) instead of shelling to git. Network operations (HTTP clients) instead of curl. Eliminating the subprocess eliminates the entire class of bug.
When you must shell out, use the argv-array form and never compose a command string. In Python: subprocess.run([...], shell=False). In Node: child_process.execFile or spawn with array arguments, never exec. In Ruby: system("cmd", "arg1", "arg2") with multiple arguments, never the single-string form. In Go: exec.Command("cmd", "arg1", "arg2"). In Java: ProcessBuilder(List<String>). Make this a lint rule.
Defend against argument injection, not just shell injection. Even with argv arrays, user-controlled values that start with - are interpreted as flags. For each subprocess call: validate that user-controlled arguments don’t start with -, use -- to terminate option parsing where the tool supports it, and prefer tools with explicit “this is a filename, not a flag” syntax. This is the trap that bites teams who think they’re done after switching to execFile.
Use absolute paths to binaries. /usr/bin/ping instead of ping. This prevents PATH-based binary substitution. In containers, this also documents your runtime dependencies explicitly.
Sanitize the environment passed to subprocesses. Pass an explicit minimal env={} (or equivalent) rather than inheriting the parent environment. Many tools read environment variables that change behavior (GIT_*, LD_PRELOAD, PYTHONPATH, PERL5OPT, IFS), and these are part of the attack surface.
Strictly allowlist user inputs that reach subprocesses. If the input is supposed to be a hostname, validate it against a hostname regex and reject anything starting with -. If it’s a filename, resolve it against an expected directory and verify the resolved path stays within bounds (this also kills path traversal, CWE-22). If it’s an enum, validate against the enum. Never trust a denylist.
Sandbox subprocesses aggressively. Run with a non-root user. Use seccomp profiles to deny syscalls the tool doesn’t need. Drop all Linux capabilities. Use read-only filesystems with explicit writable tmpfs mounts for scratch space. Deny network access unless the tool needs it. If you can, run the subprocess in a separate, ephemeral container or microVM (Firecracker, gVisor). The goal: even if an attacker achieves command execution, they execute commands in a box with nothing valuable in it.
Treat Windows as its own problem. On Windows, prefer PowerShell’s & operator with arrays over cmd.exe. Be aware that calling .bat or .cmd files re-invokes cmd.exe parsing on the arguments — patch to Node.js 20.12.2+ / 18.20.2+ if you ship Node on Windows. Don’t assume POSIX guidance covers you.
Add CI controls. Semgrep rules for shell=True, child_process.exec, string concatenation into subprocess calls, and template strings flowing to exec. CodeQL command-injection queries on every PR. Fail the build on findings until they’re explicitly reviewed and waived.
Monitor for unexpected process trees. Web application processes spawning /bin/sh, bash, cmd.exe, powershell.exe, or python is almost always either intentional (and should be in an allowlist) or a compromise. eBPF-based runtime monitoring (Falco, Tetragon) or EDR can catch this in production.
Threat-model every subprocess call. For each call site, ask: where does each argument come from, what happens if it’s -flag, what happens if it contains shell metacharacters, what happens if it’s /dev/stdin, what happens if it’s a symlink, what happens if it’s empty? Most command-injection vulns are caught at this stage if anyone bothers to ask.
Bottom Line
The article is conceptually accurate, well-emphasized on the main fix (no shell, argv arrays), and clearer than the previous two pieces in the series. Its main flaws are the CWE numbering error (CWE-77 vs CWE-78), the absence of argument-injection coverage (which leaves its own “Safer” example as a vulnerability template), and the lack of OS-specific and language-specific landmines. It’s a fine introduction; it’s not enough to ship secure code against. Pair it with the OWASP Command Injection Prevention Cheat Sheet, the CERT secure coding rules for the relevant language, and a careful read of how git, find, tar, and curl interpret arguments — because the next command-injection CVE you read about is more likely to be argument injection than classical shell metacharacter injection.
