OWASP LLM Top 10 in 2026: What Every Developer Needs to Know

LLM01: Prompt Injection

Prompt injection is the top-ranked vulnerability for a reason. An attacker crafts input that overrides your system prompt, changes the model's behavior, or causes it to execute instructions it should not.

There are two variants. Direct injection happens when a user sends malicious instructions through the chat interface. Indirect injection happens when the model processes external content, a webpage, a document, or a tool response, that contains embedded instructions. Both can cause the model to leak data, ignore safety rules, or act on behalf of the attacker.

This is OWASP LLM01, and it is the category most automated scanners focus on first.

LLM02: Insecure Output Handling

The model's output does not stay inside the LLM. It gets rendered in a UI, passed to a downstream system, or used to construct a database query. If you trust that output without validation, you have introduced a new injection surface.

Classic examples include LLM-generated content that contains JavaScript executed by a browser (XSS), or SQL fragments passed directly to a query builder. The model is not the vulnerability here, your output pipeline is.

LLM03: Training Data Poisoning

If an attacker can influence what data your model was trained or fine-tuned on, they can influence its behavior at inference time. This is more relevant for teams fine-tuning their own models or using retrieval-augmented generation with external data sources.

Poisoned training data can introduce backdoors, bias outputs toward specific conclusions, or cause the model to behave differently when it encounters specific trigger phrases.

LLM04: Model Denial of Service

LLMs are computationally expensive. Sending carefully crafted inputs that force the model into long, resource-intensive generation loops can degrade performance or drive up costs significantly.

This category covers both deliberate attacks and accidental abuse patterns. If your endpoint has no rate limiting or input length constraints, you are exposed.

LLM05: Supply Chain Vulnerabilities

You are probably not running a model you trained from scratch. You are using a foundation model from a third-party provider, a fine-tuned variant, or a plugin ecosystem. Each of those is a supply chain dependency.

Compromised model weights, malicious plugins, or vulnerable third-party integrations can introduce risks that have nothing to do with your own code. This category asks you to treat your AI supply chain the same way you treat your software dependencies.

LLM06: Sensitive Information Disclosure

Models can leak sensitive information in several ways. They might reproduce training data that includes PII or credentials. They might expose your system prompt when asked directly. They might reveal internal configuration details through carefully structured queries.

System prompt leakage is particularly common and often underestimated. Your system prompt frequently contains business logic, persona instructions, and sometimes API keys or internal URLs that you do not want users to see.

LLM07: Insecure Plugin Design

LLM plugins and tool-use integrations extend what a model can do, but they also extend the attack surface. A plugin that executes code, reads files, or calls external APIs needs the same security scrutiny as any other privileged component.

Insecure plugin design typically means insufficient input validation, overly broad permissions, or no authentication on the plugin endpoint itself. An attacker who can control what the model sends to a plugin can potentially control what the plugin does.

LLM08: Excessive Agency

When you give an LLM the ability to take actions, send emails, modify records, or call APIs, you need to constrain what it is allowed to do. Excessive agency means the model has more permissions than it needs for its intended function.

This follows the principle of least privilege. If your copilot only needs read access to a knowledge base, it should not have write access to your CRM. The risk is not just malicious input; it is also the model making mistakes with real consequences.

LLM09: Overreliance

This one is less about attackers and more about your own team. Overreliance means treating model outputs as authoritative without appropriate human review or validation.

In security contexts, this matters when teams use LLMs to generate code, write configuration, or make access control decisions without checking the output. The model can be confidently wrong, and if your process does not account for that, errors propagate downstream.

LLM10: Model Theft

Model theft covers attempts to extract your model's weights, architecture, or training data through repeated querying. This is most relevant if you have invested in fine-tuning a model on proprietary data and that model represents a competitive asset.

Attackers can use systematic probing to reconstruct model behavior or extract memorized training data. Rate limiting, output monitoring, and query logging are the primary defenses here.