The pattern shows up wherever an interpreter reads a stream that mixes sources. A shell executes what its user types. A template engine substitutes variables and also evaluates expressions. A SQL query combines structure and values. A PDF renderer follows document instructions and user preferences. An LLM reads its prompt and also any text that happens to be in the prompt.
Each of these systems assumes a boundary: the command part is trusted, the content part is data. Attacks on this pattern do not break the interpreter. They exploit the ambiguity at the boundary. The attacker embeds instructions inside content the interpreter was supposed to treat as inert, and the interpreter, doing exactly what its spec says, does the wrong thing.
What distinguishes content-is-command from ordinary injection is the CONTENT source. Classical injection comes from an input channel the designer already knew was hostile: HTTP parameters, form fields, URL query strings. The defense is input validation at the boundary. Content-is-command comes from channels the designer treated as content: documents, emails, webpages, PDFs, support tickets, database fields populated long ago by someone else. The defense is harder because there is no clean boundary to validate. The content and the command arrive on the same wire, in the same format, routed by the same parser.