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.
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¶
Current abstraction Injection Weakness Domain-specific
Parents (1) — more general patterns this builds on
-
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) — more specific cases that build on this
-
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
- Injection Weakness → Control / Data Channel Confusion → Untrusted Input Execution
- Injection Weakness → Control / Data Channel Confusion → Interface → Boundary
Neighborhood in Abstraction Space¶
Injection Weakness sits in a sparse region of the domain-specific corpus (67th percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.
Family — Unclustered & Miscellaneous (309 abstractions)
Nearest neighbors
- Prompt Injection — 0.86
- Cross-Site Scripting — 0.84
- Excessive Data Exposure — 0.83
- Data Extraction Through Prompting — 0.83
- Source Protection — 0.82
Computed from structural-signature embeddings · 2026-07-12