Command injection
In application security, command injection is a flaw where user-controlled input reaches a system shell and is interpreted as part of the command line rather than as data. The attacker appends their own instructions to one the application intended to run, and the operating system executes both.
How it works
An application needs something the language does not provide, so it builds a string and hands it to a shell: convert an image, ping a host, resolve a name, produce a PDF, read device status. If any part of that string comes from a request and is not neutralised, the shell metacharacters in it change the meaning of the line. A semicolon, a pipe, an ampersand, a newline or backticks all start a second command. The injected command runs as the account the service runs under.
The reliable fix is not filtering the characters. It is not using a shell at all: invoke the binary directly with its arguments as a list, so the operating system never parses a command line. Where a shell is unavoidable, the argument must be a value from a fixed allowed set, not a sanitised copy of what the user sent.
What goes wrong
Two things. The first is blocklisting. A filter that strips semicolons is defeated by a newline, a filter that strips both is defeated by command substitution, and a filter that catches all three is defeated by an argument that changes the behaviour of the intended binary without ever starting a second process. Passing an attacker-controlled string as a flag to a tool that can write files or load configuration is enough.
The second is where we find it. In web applications this bug has been squeezed out of mainstream frameworks and now lives in the seams: administrative endpoints, diagnostic pages, report generators and integrations with command line tools. In embedded devices it is still everywhere, because the web interface of a router or a camera is often a thin wrapper over shell scripts, which is why firmware analysis finds it so consistently and why it is a standing risk in OT and ICS environments.
Where this shows up in an audit
We look for it wherever a parameter looks like a hostname, a path, a filename or a format option, and we confirm it with a timing delay or an out-of-band callback rather than by reading output, because most instances are blind. The report gives the parameter, the payload, the evidence of execution, and the account the command ran as, which is usually the difference between a high finding and a critical one leading to remote code execution. This is part of how we test the places an application shells out.