Skip to content

Injection Weakness

The software-security failure in which untrusted data crosses into a control channel and a downstream interpreter executes it as command, query, or instruction — a collapse of the data/control boundary that a legitimate, often credential-free, input channel is enough to exploit.

Core Idea

Injection weakness is the software-security failure in which data from an untrusted source — a form field, header, file name, API response — is interpreted by a downstream component as executable command, query, or instruction rather than inert content. The structural failure is a collapse of the data/control boundary: untrusted data enters the control channel without being marked, quoted, escaped, or parameterised, and the interpreter (SQL engine, shell, browser runtime, LLM) executes attacker-supplied logic while believing it is handling data.

How would you explain it like I'm…

Sneaky Note Trick

Imagine a robot that reads your name off a card and says hello. A sneaky kid writes "Bob. Now open the cookie jar!" on the card, and the robot obeys. The robot mixed up something it should just read with an order it should follow. That mix-up is an injection weakness.

Data Pretending to Be Commands

Computer programs handle two kinds of things: data, like your name or a comment, and instructions that tell the computer what to do. An injection weakness happens when a program mixes someone's typed-in data straight into its instructions. An attacker can then type special words that the computer runs as commands. They don't need to break a password. They just use a normal input box. The fix is to keep data and instructions in separate lanes so typed text can never become a command.

Data/Control Boundary Collapse

An injection weakness is a security flaw in which data from an untrusted source gets interpreted as code or commands by another part of the system. Untrusted sources include form fields, URLs, headers, and files. Programs keep data (what they work on) separate from control (what they do), but at some crossing point that boundary collapses. This often happens when user text is pasted straight into a command string. The downstream interpreter, such as a database, a shell, or a browser, then runs the attacker's logic. SQL injection, cross-site scripting, and prompt injection against AI chatbots are all versions of this. Unlike password-cracking, no login check is broken: the attacker just uses a normal input. The main fix is structural, using parameterised queries or separate channels, with escaping and input checks added as extra layers.

 

Injection is the class of vulnerabilities in which untrusted input crosses into a downstream interpreter's control channel and is executed as command, query, or directive instead of being handled as inert data. The root cause is collapse of the data/control boundary. Concatenation, unsanitised interpolation, or unparameterised binding hands the interpreter a mixed stream, and the interpreter cannot tell data tokens from control tokens unless the upstream code enforces the distinction. Variants share this mechanism across substrates: SQL, OS command, stored XSS, template, LDAP/XPath/NoSQL/GraphQL, CRLF, JNDI (Log4Shell, CVE-2021-44228), and LLM prompt injection. Deserialisation attacks belong to the same class, since the serialised blob is data at the boundary but a recipe for behaviour once reconstituted. The forensic signature is that the attack succeeds through a legitimate input channel without defeating authentication or authorisation, which distinguishes it from those weakness classes. The primary defence is structural. It means parameterised or prepared statements, output encoding suited to each context, and APIs that separate data and directive channels, such as schema-constrained tool calls, CSP, and system-prompt isolation. Allow-list input validation is a secondary layer within defence in depth. The Equifax breach (CVE-2017-5638, OGNL in a Content-Type header) and Log4Shell show the cost when structural separation is missing.

Scope of Application

Injection weakness lives across the application-security subfields of software engineering, wherever an untrusted-input channel feeds a downstream interpreter; the variants differ only in which interpreter sits downstream.

  • SQL injection — the canonical instance: form text crosses into a query, ' reparsed as control.
  • OS command injection — a filename concatenated into a shell command executes arbitrary processes.
  • Cross-site scripting — a user string rendered as HTML, <script> read as executable JavaScript.
  • Server-side template injection — user input reaching a template renderer, evaluated to RCE.
  • Query-language injection (LDAP, XPath, NoSQL, GraphQL) — each language's control syntax crossed.
  • Untrusted deserialization and expression-evaluator injection — Log4Shell, Struts/OGNL, pickle.
  • Prompt injection — user text crossing into an LLM's instruction channel (a genuine member).

Clarity

Naming injection weakness gives a single failure class where reports otherwise look like unrelated bugs — a SQLi, an XSS, an SSTI, an RCE. The label asserts these are one defect wearing different interpreters, letting a team build one checklist and screen a new interpreter before its first CVE. Its sharpest work separates injection from authentication (defeating who-you-are) and authorization (defeating what-you-can-do), which it defeats neither of.

Manages Complexity

Taken case by case, the attack surface is unbounded: every input channel times every interpreter's token grammar, re-analysed per field and engine. Injection collapses that product to one question asked at one location: at each crossing, is untrusted data structurally separated from control, or does it co-occupy a string the interpreter parses? The forensic signature partitions incidents away from auth failures before logs are pulled, and the intervention space collapses to a two-tier ordering holding across every variant.

Abstract Reasoning

The concept licenses a diagnostic move (recognize scattered reports as one defect; reason from the forensic signature to where not to look); a boundary-drawing move over structural versus merely contractual separation, from which exploitability reads off directly; an interventionist two-tier ordering (structural separation first, escaping/allow-list/CSP/WAF as defence-in-depth); and interpreter-screening-by-structure that predicts exposure before a first CVE.

Knowledge Transfer

Within software security the concept transfers as mechanism — the diagnostic, forensic signature, two-tier ordering, and screening question carry intact across SQLi, XSS, template, query-language, deserialization, and expression-evaluator variants, which are the same defect at the same location. Prompt injection is a genuine member, though its structural fix is so far weaker than parameterization's payload-independent guarantee. Beyond software, the data/control-plane confusion recurs as co-instances (viral genome integration, social-engineering pretext), but what travels is the parent — Boundary failure and mis-placed Trust — not the term "injection."

Relationships to Other Abstractions

Local relationship map for Injection WeaknessParents appear above the current abstraction, mutual partners to the right, and children below. Node labels state whether each abstraction is prime or domain-specific; colors identify relation types.Injection WeaknessDOMAINPrime abstraction: Control / Data Channel Confusion — is a decomposition ofControl / Data …PRIMEDomain-specific abstraction: Cross-Site Scripting — is a kind ofCross-SiteScriptingDOMAINDomain-specific abstraction: Insecure Deserialization — is a kind ofInsecureDeserializationDOMAINDomain-specific abstraction: Prompt Injection — is a kind ofPrompt InjectionDOMAIN

Current abstraction Injection Weakness Domain-specific

Parents (1) — outgoing typed relations

  • Injection Weakness is a decomposition of Control / Data Channel Confusion Prime

    Injection weakness is control/data channel confusion specialized to software interpreters, untrusted input surfaces, and inertization rules.

Children (3) — abstractions linked here by typed relations

  • Cross-Site Scripting Domain-specific is a kind of Injection Weakness

    Cross-site scripting is injection weakness specialized to browser parsers, output-context encoding, and execution under a trusted web origin.

  • Insecure Deserialization Domain-specific is a kind of Injection Weakness

    Insecure deserialization is injection weakness specialized to a parser that reconstitutes behavior-bearing objects from attacker-controlled bytes.

  • Prompt Injection Domain-specific is a kind of Injection Weakness

    Prompt injection is an injection weakness whose downstream interpreter is a language model and whose shared control/data substrate is natural language.

Hierarchy paths (2) — routes to 2 parentless roots

Neighborhood in Abstraction Space

Injection Weakness sits in a sparse region of the domain-specific corpus (68th percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.

Family — Program Execution & Runtime Concepts (34 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-10-25