OWASP LLM Top 10 (2026): What Changed and How to Test

What Is the OWASP LLM Top 10?

The OWASP LLM Top 10 is a community-built awareness document that ranks the ten most critical security risks in applications powered by large language models. It is maintained by the OWASP GenAI Security Project, and the 2026 edition is the third release since the list first appeared in 2023.

It exists because LLM applications fail in ways the web list never anticipated. SQL injection has a fix: parameterize the query and the attacker's input can no longer become instruction. An LLM has no equivalent. The system prompt, your question, a retrieved document, a tool's response, and last week's conversation history all arrive as tokens on the same stream, with nothing marking which of them is allowed to give orders.

That single design fact drives most of the list. Once you accept it, the ten entries stop looking like a grab bag and start looking like one failure spreading outward: into what the model says, what it remembers, what it retrieves, and what it is permitted to do.

What Changed in the 2026 Edition

What is new in the 2026 OWASP LLM Top 10? Eight of the ten entries changed position, one was renamed, and the ranking method changed. For the first time OWASP blended community voting with evidence from catalogued AI incidents, weighting the vote at 75 percent and incident data at 25 percent. Of the incidents reviewed, 6,639 carried enough detail to classify.

That methodology change explains most of the movement, and it produced one genuinely interesting anomaly. Prompt Injection stayed at number one despite a thin incident record, because organizations that block it successfully do not generate incidents. Misinformation went the other way: it barely registered with voters and dominated the incident data, so it climbed two places on evidence rather than opinion.

The project leads summarized their own conclusion bluntly in the release coverage: "Stop trying to build a model that cannot be fooled. Build the system around it, so that when the model is fooled, and it will be, nothing important breaks." That sentence is the difference between the 2025 and 2026 lists in one line, and it is why the agency and blast-radius entries moved up while the sanitization entry fell.

The 10 Risks, Explained

Each entry below uses the official LLM01:2026 style identifier you will see cited in pentest reports and AI red team findings. The 2026 release also maps every risk to NIST, CWE, the companion OWASP Top 10 for Agentic Applications, and MITRE ATLAS, which is worth knowing if your report needs to speak a client's framework.

LLM01:2026 - Prompt Injection

Input alters the model's behavior in ways the developer did not intend. The input does not have to be typed by a user, does not have to be human-readable, and does not have to be visible in the rendered page. A poisoned wiki page, an issue title, a tool response, an image, or a line written into long-term memory all reach the same token stream. Invisible Unicode is the trick worth knowing: tag-block characters (U+E0000 to U+E007F), variation selectors, and zero-width characters smuggle instructions past a human reviewer entirely.

Indirect injection is where this gets nasty. The attacker never touches your backend. They leave text where your assistant will read it, and your assistant, running with your credentials, does the work for them.

LLM02:2026 - Sensitive Information Disclosure

The model exposes data it should not, and the answer text is only one of the channels. Tool-call arguments, reasoning traces, retrieved chunks, logs, embeddings, and even observable timing or token-length patterns all leak. OWASP cites the November 2023 divergence attack in which repeated-token prompts pushed gpt-3.5-turbo to emit more than 10,000 unique memorized training examples for roughly 200 dollars of API spend.

Most real leaks are duller than that. A retrieval pipeline pointed at an over-shared drive returns exactly what it was built to return, and the sensitive document was never supposed to be in the index.

LLM03:2026 - Excessive Agency

The most significant promotion in the 2026 list. An LLM given tools can act, and Excessive Agency is what turns a manipulated output into a real consequence. OWASP breaks the root cause into three: excessive functionality (a document-reading tool that can also delete), excessive permissions (a read-only feature connecting with an account that holds UPDATE and DELETE), and excessive autonomy (no human approval on an irreversible action).

It moved to third because agentic deployments made the theory concrete. The 2025 list treated agency as a downstream concern. The 2026 list treats it as the control deciding whether an injection is an inconvenience or an incident.

LLM04:2026 - Supply Chain

Third-party models, datasets, LoRA adapters, conversion pipelines, and serving frameworks are all attack surface. Pickle-serialized model files execute arbitrary code on load, which is the single most reliable way to get shell from a model artifact, and OWASP is explicit that moving to safer formats reduces the risk without eliminating it: a backdoor can live in an ONNX computational graph too.

The newest variant here has the best name on the list. Coding assistants hallucinate plausible package names at scale, attackers register those names in advance, and the AI-suggested dependency resolves to malicious code. OWASP calls it slopsquatting.

LLM05:2026 - Data and Model Poisoning

An adversary corrupts data or model artifacts so the harmful behavior is baked in rather than injected at runtime. It can happen at pre-training, fine-tuning, embedding creation, retrieval augmentation, or anywhere a continuous-learning pipeline ingests content without validation. Backdoors can stay dormant until a trigger phrase appears, which makes behavioral testing alone a weak assurance.

The reason this hurts more than a normal bug: you cannot patch it. Remediation means revalidating data, retraining, or replacing the model.

LLM06:2026 - Unbounded Consumption

Up four places, and reframed around cost asymmetry rather than plain denial of service. An attacker spends almost nothing to trigger computation that costs the provider a great deal. Reasoning models with generous output budgets, multimodal inputs, and agent loops that fan one request into dozens of downstream calls all widen the gap. Denial of Wallet is now a legitimate finding in an LLM assessment, and request-rate limiting alone does not close it because one request is not one unit of cost.

LLM07:2026 - Misinformation

The model produces output that is wrong but credible enough to be acted on. This is the entry the incident data pushed up hardest. It stopped being a user-trust problem when model output started driving tool calls, inferring workflow state, and feeding other agents. A confident wrong answer that a human double-checks is an annoyance. The same answer consumed by an automated workflow is a fault with no reviewer in the path.

LLM08:2026 - Hidden Context Exposure

Renamed from System Prompt Leakage, and broadened. The entry now covers everything assembled into the model's context that users are not meant to see: system instructions, retrieved policy text, tool schemas, and workflow rules. OWASP's guidance is refreshingly direct here. Assume hidden context is discoverable, and design so its disclosure has little security impact.

Extracting a system prompt is a fun demo. The finding that matters is what the prompt reveals: credentials, filtering logic, or the tool names and argument shapes that make the next attack precise.

LLM09:2026 - Vector and Embedding Weaknesses

Wherever similarity search sits between a data source and the prompt, the embedding layer joins the trust boundary. This covers RAG, vector-backed agent memory, semantic caches, and deduplication. The attacks exploit the geometry of the vector space rather than the model's instruction-following, so many of them work even when the retrieved text contains nothing malicious.

Cross-tenant leakage is the case to test first: similarity search frequently runs across the whole index before the application applies access control, so result counts, score distributions, and timing reveal other tenants' documents without ever returning them. OWASP also points to conventional auth flaws compounding the problem, citing CVE-2025-64513 in Milvus and CVE-2025-69286 in RAGFlow, both rated CVSS 9.3.

LLM10:2026 - Improper Output Handling

Model output reaching a downstream component without validation. This is the classic pipeline: generated Markdown rendered as HTML gives you cross-site scripting, generated SQL concatenated into a query gives you injection, generated shell arguments give you command execution. The 2026 edition adds terminal and IDE sinks that interpret ANSI escape sequences, and client renderers that auto-fetch Markdown images, which turns a rendered answer into an outbound exfiltration channel.

It fell five places, which is easy to misread. The risk did not get smaller. OWASP moved it because it is well understood and directly fixable with the encoding and validation practices web developers already have, while the entries above it are not.

How to Test an LLM Application Against the Top 10

How do you test an LLM app for these risks? Map the trust boundaries first, then attack in order of blast radius: what the model can reach, what it retrieves, and what its output touches. Chat-surface jailbreaks make the best screenshots and the least valuable findings, so leave them until last.

1. Inventory the context. List everything that lands in the context window: system prompt, user input, retrieved documents, tool responses, memory, and conversation history. Anything on that list that an outsider can write to is an injection surface.
2. Enumerate the tools. Get the tool schemas, then check the identity behind each one. A read-only feature connecting with write credentials is an LLM03 finding before you have sent a single payload.
3. Test indirect injection first. Plant instructions in a document, a page, an issue title, or an API response the system will ingest, then watch whether they influence a later session. Cross-session persistence through memory or a RAG corpus is the finding worth escalating.
4. Follow the output. Trace every sink the response reaches: browser, terminal, log viewer, IDE pane, email template, database query. Test each with the encoding that sink interprets, including ANSI sequences and Markdown image tags.
5. Probe retrieval boundaries. In a multi-tenant deployment, query for content you should not be able to see and measure result counts, scores, and latency. Inference is a finding even when no document comes back.
6. Bound the cost. Measure how much downstream compute one request can trigger. Reasoning loops and agent fan-out are where Denial of Wallet lives.

When testing real deployments, the pattern that comes up most often is not an exotic jailbreak. It is a tool wired to a service account with far more access than the feature needs, sitting behind a model that will eventually be talked into calling it. The payload is the easy part.

The Lethal Trifecta, and Why Filtering Loses

OWASP's own prevention guidance for prompt injection opens with an admission most vendors will not make: no reliable prevention mechanism exists today. Input filters degrade against adaptive attackers, and a second model asked to police the first is just another model that can be talked around.

What survives contact with an attacker is architecture. The 2026 release cites Simon Willison's "lethal trifecta" as a pre-deployment check, and it is the most useful idea in the whole release for a working tester. An agent is in danger when it can do all three of these at once:

• Access private data through files, databases, or an authenticated API.
• Ingest untrusted content from web pages, email, documents, or tool output.
• Communicate externally by sending requests, writing files, or rendering fetched resources.

Remove any one leg and the high-impact exploitation path closes. That is a design review question, not a payload question, and it belongs at the top of any agentic engagement. If a client insists their guardrail model handles injection, ask which of the three legs they removed. The silence is usually the finding.

Where This Fits If You Are Learning Offensive Security

You do not need machine learning research skills to test these systems. Seven of the ten risks are recognizable web problems wearing new clothes. Improper Output Handling is injection with an extra hop. Excessive Agency is privilege escalation. Vector and Embedding Weaknesses is a multi-tenant authorization bug. Supply Chain is dependency confusion plus insecure deserialization.

The honest career advice: learn web application security properly first, then add the model-specific parts. A tester who understands trust boundaries and can read an API contract will find more in an LLM assessment than someone who only knows jailbreak prompts. Our OWASP API Security Top 10 guide covers the authorization thinking that transfers directly, and the AI-specific mechanics build on top of it.

Last verified: August 2026. The 2026 edition was published on 4 August 2026. Rankings and entry titles confirmed against the OWASP GenAI Security Project's published release and its canonical source repository.

Legal and Ethical Considerations

• Test only systems you own, dedicated practice labs, or targets inside a signed engagement or a bug bounty program's published scope.
• Check the scope wording before you start. Many programs still exclude model behavior, or accept prompt injection only when you can show impact on a connected system.
• Data extraction testing can surface real personal data. Stop at proof of impact, and never retain or share what comes back.
• Denial of Wallet testing costs the target actual money. Agree limits in writing first.
• Plant injection payloads only in content you control. Poisoning a shared wiki or a public repository to see what happens hits people who never agreed to your test.