From A05 to LLM01: The Injection Lineage, from SQLi to Prompt Injection

Aug 26

By Krish Malik and Jai Malik, Artais

The Reign

For most of the 2010s, injection was one of the web's most dangerous security risks, holding the number one slot in both the 2013 and 2017 editions of the OWASP Top 10, with SQL injection serving as its defining example. A typical attack involved an attacker inserting a stray quotation mark, semicolon, or similar input into a login field, causing a database that was only meant to store and retrieve data to execute unintended commands. Command injection exploited the operating system shell in much the same way, LDAP injection targeted directory queries, and cross-site scripting targeted the browser’s Document Object Model (DOM). Although each attack focused on a different target, the weakness underneath remained the same.

At its core, every injection vulnerability follows a common pattern: untrusted input reaches an interpreter and is treated as executable instructions rather than ordinary data. The interpreter has no reliable way to distinguish between the commands it was originally intended to execute, and the input supplied by an external user, so it processes both together. That concept accurately described SQL injection in 2012, and it also describes the vulnerability class that reappeared more than a decade later in an entirely different computing environment. Everything that follows builds on this same principle.

What Worked

The solution that reduced the prevalence of classic injection was not a more sophisticated filter or a better regular expression. Instead, it was a structural change: parameterized queries and prepared statements. Rather than building a SQL command by concatenating strings, the application sends the query's structure and the user's input separately. The database driver enforces the separation at the protocol level, ensuring that user input is always interpreted as data and can never become part of the command itself, regardless of how malicious that input may be.

Modern object-relational mappers (ORMs) reinforce this approach by encouraging or automatically using parameterized queries instead of relying on developers to remember them every time they write the database code manually. Web frameworks also introduced context-aware output encoding for web applications. This is because HTML, JavaScript, CSS, and URL contexts each require different escaping rules. When a user's input still interacts directly with an interpreter, developers typically supplement these protections with positive allowlist validation. None of these defenses are especially novel or complex. Instead, they have become standard components of modern software development due to consistently preventing entire classes of vulnerabilities. Their effectiveness comes from becoming routine rather than exceptional.

The common principle behind each of these defenses is the separation of the control channel from the data channel. The control channel is the instructions that define what the system should do, and the data channel is the information supplied by users. By preventing user input from crossing into the control channel, applications ensure that data cannot be promoted into executable instructions regardless of how carefully it is crafted, serving as the foundation for everything that follows.

Why A05, Not A01

OWASP's Top 10:2025 places Injection at A05, down two positions from A03 in the 2021 edition. The widespread adoption of parameterized queries, ORMs, and framework-level output encoding has measurably reduced the frequency of traditional SQL injection and command injection vulnerabilities in production applications. The lower ranking reflects this reduction in prevalence rather than a reduction in severity. Injection is still one of the most heavily tested categories in the entire list and carries the largest number of associated CVEs of any category in the 2025 edition. This includes everything from high-frequency, lower-impact cross-site scripting vulnerabilities to less common but far more severe SQL injection attacks. The vulnerability class was not eliminated; it was made substantially harder to reach.

That distinction, demoted due to being contained rather than defeated, is the central idea that the rest of this piece builds on.

The Mutation

Now consider the same underlying weakness in a different computing environment. Large language models (LLMs) take a system prompt and untrusted user or document content and process both as a single stream of tokens. Unlike a database driver enforcing a clear separation between a query and its parameters, there is currently no reliable structural separation within an LLM’s runtime that distinguishes “the instructions the model was configured to follow” from “the content someone provided for it to process.” To the model, both are simply text that must be interpreted. As a result, the model must infer which portions of the input represent instructions and which represent content. That distinction is based on contextual reasoning rather than a hard separation enforced by the runtime. This is fundamentally different from the way SQL drivers mechanically separate query templates from user-supplied values.

This is the foundation of Prompt Injection, ranked LLM01 in OWASP's Top 10 for LLM Applications 2025, for the second consecutive edition of that list. Structurally, it is the same class of failure as SQL injection: a system that cannot reliably separate instructions from untrusted data, allowing carefully crafted input to be interpreted as though it were a legitimate command.

Why It Is Harder This Time

This is where the comparison between traditional injections and prompt injections becomes more challenging. Parameterized queries worked because SQL has formal grammar. The structure of a query can be expressed independently of the values plugged into it, allowing the database driver to enforce that separation mechanically. Natural language does not offer the same advantage. Instructions and ordinary content are both represented as text that the model must interpret. There is no parser capable of separating commands from data in the same deterministic way that a SQL driver separates a query template from its bound parameters. As a result, there is currently no widely accepted equivalent to parameterized queries for large language models.

Prompt injection defenses differ not only in implementation but also in philosophy. Rather than eliminating the vulnerability through structural separation, today’s mitigations are designed to reduce risk. These protections rely on multiple defensive layers, including input and output filtering, least-privilege access for models and agents, requiring human approval before high-risk actions, treating retrieved or ingested content with greater skepticism than direct user instructions, and monitoring systems for anomalous behavior. Each of these controls contributes to reducing the likelihood or impact of a successful attack, but none provides the same guarantees that parameterized queries offered SQL injection. Defense in depth is currently the most realistic security strategy because no broadly accepted structural solution exists. This makes prompt injection a risk-management problem rather than one with a universally reliable technical solution.

Direct, Indirect, Multimodal

Prompt injection generally appears in three forms, and understanding the distinctions between them is key. They differ significantly in how the attacker delivers malicious instructions.

Direct prompt injection is the most straightforward example. An attacker enters instructions such as, "ignore your previous instructions" straight into a chat box. Since the attacker is an obvious participant in the conversation, this form of prompt injection is also typically the easiest to detect and defend against.

Indirect prompt injection presents a more significant challenge, particularly for organizations building agentic systems or applications that consume external content. For this prompt injection, the attacker never communicates directly with the model at all. Instead, attackers hide malicious commands inside everyday files that they know an AI will eventually process. These hidden instructions could be placed inside webpages, PDFs, resumes, or other documents that appear legitimate. When the AI scans these documents, whether summarizing a webpage, a PDF in a research database, or an applicant’s resume in a screening tool, it unknowingly processes both the legitimate content and the hidden instructions together. The individual requesting the summary becomes an unwitting participant, unaware that the document they supplied contains instructions intended to manipulate the model. This often happens in systems using Retrieval-Augmented Generation (RAG), where an AI retrieves information from external sources to improve its responses. If those external sources contain hidden, adversarial instructions, the model may incorrectly interpret them as legitimate directions and follow them instead of the application’s intended behavior.

Multimodal prompt injection extends the same idea across data types. Instead of embedding malicious instructions in documents, attackers hide them inside images, audio recordings, or other non-text inputs that multimodal models process alongside traditional text. As multimodal systems get more common, they expand the available attack surface without introducing a new security concept. The underlying vulnerability remains exactly the same; only the medium carrying the malicious instructions changes.

Although all three forms differ in their delivery methods, they all come from the same underlying failure. Whether the untrusted content arrives as a chat message, a webpage, a PDF, or an image, the failure is the same: nothing separates the instruction channel from the data channel.

The Loop Closes

Modern prompt injection attacks do more than manipulate an AI into generating misleading responses; they weaponize the model so it can attack systems connected to it. Many AI-enabled applications blindly trust model outputs and pass them downstream without sufficient validation. When this occurs, a successful prompt injection acts as a delivery mechanism for classic cyberattacks like SQL injection or cross-site scripting. As highlighted by the OWASP LLM05: Improper Output Handling guidelines, attackers no longer need direct access to your database. Instead, they can simply manipulate the LLM into constructing and delivering the malicious payload on their behalf.

Classic injection vulnerabilities were largely contained by separating control from data at the query level. Prompt injection reopened the same underlying weakness at the model's input, while improper output handling allows that manipulated output to bypass the defenses meant to stop it, reaching vulnerable areas in the code that were supposedly protected. In effect, prompt injection and improper output handling can work together to recreate the same attack chain that modern software engineering practices largely eliminated from traditional applications.

Looking Forward

Agentic systems raise the stakes considerably because they do far more than generate text. Modern AI agents can call APIs, write or modify files, send emails or messages, execute workflows, and operate using credentials on behalf of a user or organization. OWASP tracks this separately as LLM06:2025 Excessive Agency, and it amplifies the impact of every vulnerability discussed above. A successful prompt injection against a passive chatbot may produce an incorrect answer or an inappropriate paragraph. A successful prompt injection against an AI agent with tool access and standing credentials produces an action taken under your identity or a trusted identity.

Unlike parameterized queries, which work because SQL’s formal grammar lets a driver separate code from data mechanically, there is currently no equivalent “magic bullet” for prompt injection in AI systems. The most realistic path forward relies on well-established security principles rather than entirely new ones. Organizations should apply least-privilege access to limit the damage a compromised agent can cause. At the same time, they should perform rigorous adversarial testing that evaluates complex and indirect attack paths rather than focusing solely on obvious prompt bypass attempts.

That philosophy is the motivation behind the companion tool for this post, promptsift. It is a small CLI probe that evaluates an LLM or agent endpoint against a versioned corpus of known injection technique patterns. Each test uses deterministic canary-token and marker checks instead of relying on subjective interpretation of the model’s responses. Every entry in its corpus is classified twice: once with the LLM01 sub-technique it falls under, and once with the classic pre-LLM injection technique it structurally mirrors. As a result, the generated report functions as a lineage map rather than a pass-or-fail checklist. Promptsift is a single-purpose, CI-friendly susceptibility probe rather than a broad red-team framework in the mold of Promptfoo or DeepTeam, and it does not generate or automate jailbreaks. Producing new attack content is intentionally outside its scope.

Injection attacks were never truly eliminated; they were only patched in traditional software through structural security improvements. Those same solutions, however, do not transfer directly to large language models because the underlying execution model is fundamentally different. Rather than viewing prompt injection as an entirely new category of security problem, it is more accurate to see it as the latest evolution of one of the oldest vulnerability classes.

References