OWASP LLM Top 10 (2026): Official List and What Changed

OWASP published the 2026 edition of its Top 10 for LLM Applications on August 3, and for the first time the ranking is not built on practitioner judgment alone. The project assembled a corpus of 7,714 real incidents from public vulnerability databases and an AI-harm database, classified the 6,639 that carried enough detail to sort, and weighted that record at a quarter against three quarters for the community vote.

Almost everything moved. Only Prompt Injection and Sensitive Information Disclosure held their positions from 2025. Excessive Agency climbed from sixth to third, Unbounded Consumption rose from tenth to sixth, Improper Output Handling fell from fifth to tenth, and System Prompt Leakage was renamed and re-scoped as Hidden Context Exposure.

That reshuffle has a practical cost. If you mapped controls, a test suite, or a security questionnaire to the 2025 identifiers, those numbers no longer point where they used to, because LLM06 was Excessive Agency last year and is Unbounded Consumption now.

Below is the current OWASP LLM Top 10, what each entry actually covers, and a map back through the 2025 and 2023 versions so an older identifier still resolves to something.

Updated: September 1, 2026. This page reflects the OWASP Top 10 for LLM Applications 2026 (v1.0), the current edition.

What Is OWASP?

OWASP is a nonprofit that publishes application security guidance and gives all of it away. Nothing sits behind a paywall or a membership, which is a large part of why its documents end up cited in procurement questionnaires, audit findings, and internal engineering standards at companies with no other relationship to the organization.

What Does OWASP Stand For?

OWASP stands for Open Web Application Security Project. It is a foundation rather than a standards body or a regulator, so nothing it publishes carries legal force on its own, and its documents describe themselves as awareness and guidance rather than requirements. That distinction matters less than it sounds, because auditors and enterprise buyers treat the material as a baseline regardless.

What OWASP Publishes

The best-known document is the OWASP Top 10 for web applications, currently in its 2025 edition, which runs from A01 Broken Access Control through A10 Mishandling of Exceptional Conditions and draws on contributed data covering more than 2.8 million applications. Alongside it sits the Application Security Verification Standard, a much longer list of specific controls to verify rather than risks to be aware of.

AI work now lives under the OWASP GenAI Security Project. That umbrella houses the LLM Top 10, a separate Top 10 for Agentic Applications, the AI Testing Guide, and the GenAI Red Teaming Guide. The older owasp.org project page for the LLM Top 10 still exists, but it now serves as an archive of the 2023 list and points to the GenAI project for anything current.

Why OWASP Matters for LLM and API Security

The web Top 10 assumes a boundary that an LLM does not have. Parameterized queries work because the database can tell a command from a value, and output encoding works because the browser can tell markup from text. A model has no equivalent, since the system prompt, the user's message, retrieved documents, tool outputs, and conversation history all arrive as tokens on one stream with no enforced trust boundary between them. OWASP makes this point directly in the 2026 prompt injection entry, noting there is no clean equivalent to a parameterized query.

Because of that, an LLM application fails in ways the older list has no category for:

• No trust boundary inside the context window - Anything the model reads can behave like an instruction, whether it came from a user, a web page, a database row, or a tool response.
• Persistence across sessions - An injection that writes to long-term memory, a RAG corpus, or a vector store taints every later session that reads from it, which turns a single successful attempt into a standing compromise.
• The model as a caller - Once output drives tool calls, the blast radius stops being the chat surface and becomes whatever the agent's credentials can reach.
• Cost as an availability risk - Inference is expensive enough that an attacker can trigger disproportionate spend at negligible cost to themselves, so the bill becomes an attack surface rather than a finance problem.

The API security overlap is heavier than it first appears. An LLM application is usually an API client and an API server at the same time, so authorization, rate limiting, and resource controls apply on both sides, and several of those concerns surface in the LLM list under Excessive Agency and Unbounded Consumption. The controls are familiar; what changes is that the thing calling your API is now non-deterministic, which is also why a documented AI governance framework shortens the security review that follows.

OWASP is explicit about where its own lists divide. The LLM Top 10 owns the risk while the model is a component inside your application, and once it becomes an actor with tools it can call, memory it carries between sessions, and consequences it sets in motion downstream, the risk moves to the Agentic Top 10. Many real incidents sit on that line, and OWASP's advice is to read both rather than pick one.

OWASP Top 10 for LLM Applications 2026 (Official List)

The 2026 edition is version 1.0, dated August 3, 2026, and published under CC BY-SA 4.0 by the OWASP GenAI Security Project. The ten entries are:

1. LLM01:2026 Prompt Injection
2. LLM02:2026 Sensitive Information Disclosure
3. LLM03:2026 Excessive Agency
4. LLM04:2026 Supply Chain
5. LLM05:2026 Data and Model Poisoning
6. LLM06:2026 Unbounded Consumption
7. LLM07:2026 Misinformation
8. LLM08:2026 Hidden Context Exposure
9. LLM09:2026 Vector and Embedding Weaknesses
10. LLM10:2026 Improper Output Handling

LLM01:2026 Prompt Injection

Input alters the model's behavior in ways the developer did not intend. The input does not have to come from a user, does not have to be human-readable, and does not have to be visible in the rendered interface, since retrieved content, tool output, an image, an audio track, intermediate reasoning, and persistent memory are all delivery surfaces.

Three deployment properties make it worse than a chat-surface problem. Context-window pooling removes any enforced separation between the system prompt and untrusted content. Memory persistence lets one injection survive into later sessions. Agentic execution turns a manipulated output into a real action against a real system.

The 2026 entry added cross-modal attacks, where instructions hide inside an image or an audio file rather than text. Prompt injection stayed at number one despite falling out of the top ten on raw incident counts, which the project leads attribute to a defense effect: teams fight it hard enough that fewer clean exploits reach a public database. Detection is layered rather than singular, and the tradeoffs between input filtering, output filtering, and dual-LLM patterns are worked through in more depth in this guide to prompt injection detection.

LLM02:2026 Sensitive Information Disclosure

Confidential, regulated, or proprietary data reaches a channel nobody authorized. The 2026 entry is broad about what counts as a channel, and the final answer is only one of them.

Tool-call arguments, reasoning traces, retrieved chunks, logs, telemetry, embeddings, and observable inference properties like timing, token length, log-probabilities, and cache-hit behavior all qualify as disclosure surfaces. Each should be treated as an output subject to the same classification and redaction rules as the response itself. This is the one entry near the top where the community vote and the incident record simply agree, which is why OWASP flags its confidence here as highest.

LLM03:2026 Excessive Agency

Climbing from sixth to third makes this the most consequential move on the list, and the project attributes it to vote and evidence pointing the same direction about where damage is actually landing. Excessive Agency is the vulnerability that lets damaging actions happen in response to unexpected, ambiguous, or manipulated model output, regardless of what caused the model to misbehave.

The root causes are excessive functionality, excessive permissions, and excessive autonomy. An extension that only needs to read a mailbox also carries the ability to send. A read-only integration connects with an identity that also holds UPDATE and DELETE. A high-impact action executes without anyone confirming it.

Mitigation lives in the application rather than the prompt. Credentials and state-change capability belong in trusted code with least privilege per operation, and privileged calls should route through a deterministic policy engine that revalidates intent and arguments at execution time.

LLM04:2026 Supply Chain

Training data, base models, adapters, conversion pipelines, and deployment platforms are all attack surface. Fine-tuning methods like LoRA made adapters a shared, downloadable artifact, and platforms that host model merges and format conversions became places where a compromise can be introduced without touching anyone's code.

The 2026 revision widened this to cover the trust failure when a promoted model artifact turns out not to be what it claims. Model cards and repository documentation describe provenance but do not guarantee it, so integrity checks, signing, and file hashes carry weight that documentation cannot.

LLM05:2026 Data and Model Poisoning

Poisoning is no longer scoped to training data in the traditional sense. It can happen anywhere data is ingested, transformed, retrieved, or reused, which includes pre-training, fine-tuning, embedding creation, retrieval augmentation, and model distribution.

What makes it hard to catch is that the system usually keeps working. A backdoor can leave behavior untouched until a specific trigger appears, which means routine testing passes and the failure only shows up when someone knows what to send. The 2026 entry absorbed fine-tuning subversion, where the tuning process itself is used to strip safety behavior or install targeted triggers.

LLM06:2026 Unbounded Consumption

Rising four places, this entry covers excessive and uncontrolled inference: denial of service, unsustainable cost, service degradation, and model theft through cloning. The defining characteristic OWASP names is cost asymmetry, where an attacker triggers expensive computation at negligible cost to themselves.

The controls are mostly ones an API team already knows, including input size limits, rate limiting per entity, timeouts, throttling, and dynamic resource management. What is different is that a hard spend ceiling matters as much as a request ceiling, because a rate limit that permits expensive requests does not stop a denial-of-wallet attack.

LLM07:2026 Misinformation

This is the entry OWASP's project leads asked readers to slow down on. Voters placed it near the bottom and the incident record placed it near the top, the widest disagreement on the list and the one running in the direction that hurts.

Misinformation is incorrect, incomplete, unsupported, or misleading output that appears credible enough to influence a human decision, an automated workflow, or an agent action. The risk is not that the model is wrong but that something downstream trusts it. In agentic systems it usually shows up as incorrect state or reasoning consumed by a later component, so a fluent wrong answer becomes a wrong action several steps away from where it originated.

LLM08:2026 Hidden Context Exposure

System Prompt Leakage was renamed and broadened here, and the new framing is more useful. Hidden Context Exposure covers the unauthorized extraction, inference, or reconstruction of any non-user-facing instruction or operational context the application assembles into the model's window.

That includes the system prompt, but also developer instructions, retrieved policy text from RAG knowledge bases or configuration stores, the schemas of tools the application exposes, and workflow criteria. It becomes security-relevant when what leaks reveals secrets, trust boundaries, or policy logic that materially increases what an attacker can do. OWASP's longstanding position holds: the system prompt should never be treated as a secret or used as a security control in the first place.

LLM09:2026 Vector and Embedding Weaknesses

RAG is the familiar case, though the same machinery sits underneath vector-backed agent memory, semantic caches, and deduplication pipelines. Wherever similarity search decides what the model sees, the embedding layer is part of the trust boundary.

These weaknesses are distinct from prompt injection because they exploit the geometry of the embedding space and the mechanics of similarity search rather than the model's instruction-following. Many succeed even when the retrieved content contains no instructions at all, through embedding inversion, cross-tenant retrieval in a shared vector store, or access controls that were never made permission-aware. The controls that hold up here sit at the retrieval layer rather than the prompt, which is the argument behind these RAG security best practices.

LLM10:2026 Improper Output Handling

Falling from fifth to tenth is the largest drop on the list, and the entry itself did not shrink. Improper Output Handling is insufficient validation and sanitization of model output before it reaches another component, and successful exploitation produces XSS and CSRF in browsers along with SSRF, privilege escalation, and remote code execution on backends.

OWASP draws the line between this and its neighbors carefully. Improper Output Handling concerns unsafe use of output, Misinformation concerns output that is wrong, and validation of what goes into the model belongs to Prompt Injection. The 2026 version extended it to cover insecure code generated by assistants at scale, which is the same failure at a different point in the pipeline.

What Changed in the 2026 OWASP LLM Top 10

How the 2026 Ranking Was Built

Every previous edition ranked on the community vote alone. The 2026 release kept that vote as the dominant input and added the incident record underneath it, deliberately weighting judgment heavily so that one year of imperfect data could not overturn a consensus product. A quarter of the weight is enough to move an entry a tier when belief and evidence diverge sharply, and not enough to let the data rewrite the list on its own.

Where the two disagreed is the more useful output. Rank the categories by raw incident count and prompt injection falls out of the top ten entirely, which the project leads read as a defense effect, since teams fight it hard enough that fewer clean exploits reach a public database and the count understates a risk mature teams already spend real money holding off. Misinformation runs the other direction, scoring near the bottom on the vote and near the top on the evidence, the widest gap on the list and the one pointing toward more harm rather than less. It still seats in the middle because the vote carries more weight, though the evidence pulled it up several places.

Excessive Agency is the entry where vote and record agreed, and that agreement is why it moved as far as it did.

Mapping 2023 to 2025 to 2026

The 2025 edition remains available as a published PDF, dated November 18, 2024, and the 2023 entries are preserved on the GenAI project archive.

Categories That Were Merged, Renamed, or Retired

Two entries from 2023 no longer have a category of their own. Model Theft was folded into Unbounded Consumption, which now treats extraction and functional replication as consequences of uncontrolled inference rather than a separate risk. Insecure Plugin Design was dropped as a standalone entry, and its concerns are now spread across Excessive Agency, which covers what a tool is permitted to do, and Supply Chain, which covers where the tool came from.

Several renames tracked scope changes rather than cosmetics. Model Denial of Service became Unbounded Consumption in 2025 to include cost and resource exhaustion. Overreliance became Misinformation, moving the focus from user behavior to the output itself. Training Data Poisoning became Data and Model Poisoning once poisoning stopped being confined to the training stage.

The 2026 revision resisted adding categories. Cross-modal attacks went into Prompt Injection, artifact substitution into Supply Chain, fine-tuning subversion into Data and Model Poisoning, and assistant-generated insecure code into Improper Output Handling. OWASP's stated reasoning is that thin new categories would have splintered the list for no gain, and the incidents behind those risks were real before they had anywhere to sit.

One boundary got firmer. Risks belonging to autonomous, tool-using agents moved to the Top 10 for Agentic Applications, announced in December 2025, which means the LLM list is now scoped to the model as a component and the two documents are meant to be read together.

Testing Your Agents Against the OWASP LLM Top 10 With Respan

A risk list tells you what to look for; it does not tell you whether your agent gives way when someone tries. Respan's red teaming runs that test against the agent you actually deployed, with its prompt, retrieval pipeline, and tools attached, rather than against the model underneath it.

The engine profiles the target first and changes tactics based on how it responds, so a refusal leads somewhere instead of ending the attempt. Findings come back with evidence attached, in a form a security reviewer or an auditor can read without translation.

• Attacks that adapt - Recon profiles the agent and its refusal behavior, broad testing finds where it gives way, then crescendo, PAIR, tree of attacks with pruning, and Bad Likert judge escalate against whatever failed.
• A verdict on every attempt - Each round returns refused, partial, or successful, so you see what held as clearly as what broke.
• Proof beside every finding - Confirmed findings carry the decisive prompt next to the response or the recorded tool action, with severity plus OWASP and MITRE ATLAS identifiers attached.
• A grade your pipeline can block on - Campaigns close on a letter grade, a resistance rate, and a confirmed-finding count, so a release either clears your bar or it does not.
• Honest coverage reporting - Results split into what was confirmed, what was tested and held, and what needs deeper access than a conversation interface allows.
• Testing on your terms - Start on a hosted sandbox that never touches your systems, then connect your own agent through a local adapter where credentials and connection logic stay on your machine.
• Attacks you can read first - The campaign CLI is public at respanai/respan-redteam, which matters when the thing you are approving is adversarial traffic against production.
• The loop closes in one place - A confirmed finding becomes a dataset row, an evaluator, and an online eval scoring live traffic, so the same failure gets caught in production and not only in the next campaign.

That last point is what separates a campaign from an exercise. Testing an agent adversarially and then watching production for the same failure are usually two purchases and two integrations, and keeping both against one span-based record of what the agent did is what makes a finding cheap enough to fix the week it appears.

OWASP AI Testing Guide

The Top 10 names risks. The AI Testing Guide supplies the method for checking whether your system has them, and OWASP describes v1 as the first open, community-driven standard for trustworthiness testing of AI systems.

Its scope reaches past security. The guide covers reliability, fairness, privacy, and compliance alongside adversarial robustness, on the argument that security by itself is not what a stakeholder means when they ask whether an AI system can be trusted. It is written to be technology and industry agnostic, with test methodology, threat modeling, and checklists that apply across the development lifecycle rather than at a single gate.

Alongside it, the GenAI Red Teaming Guide covers adversarial assessment specifically, organized into phases spanning model evaluation, implementation, system, and runtime. Between the two, the Top 10 gives you the scope and these give you the procedure, which is roughly the relationship the web Top 10 has with the Web Security Testing Guide.

What neither document decides for you is which of the ten categories your application can be tested for at all. That is a scoping question, and getting it wrong is how an assessment ends up reporting a clean result on ground it never covered. A few things worth settling before the first campaign runs:

• Map every category to a feature - Work through LLM01 to LLM10 and name the specific feature that makes each one reachable: the retrieval pipeline for LLM09, the tool schema for LLM03, the memory store for LLM01. A category with no feature behind it is either genuinely out of scope or a sign the scope is incomplete, and you want to know which before someone else asks.
• Sort tests by the access they need - Some categories give way to anything that can hold a conversation with the agent, while Supply Chain and Data and Model Poisoning need visibility into the build pipeline, the model registry, and the ingestion path. Splitting the list this way early keeps you from treating an inconclusive result as a passing one.
• Pin the assessment to a list version - Record which edition your findings map to, because an identifier written down without a year stops meaning anything the next time the list moves. A finding tagged LLM06 in 2025 and read in 2026 points at a different category entirely.
• Report untested as untested - Categories nothing reached should come back labeled that way rather than folded into a pass. A resistance rate summarizes one run against one scope with one budget, and a strong number only means no severe issue was confirmed inside that scope.

None of this replaces the methodology in the guide, which is more thorough than anything a scoping pass will produce. However, the scoping decisions come first in practice, and they determine what the methodology is applied to.

If you are choosing software to run those campaigns rather than writing the methodology yourself, this comparison of AI red teaming tools covers what each one points at and what it hands back.

Frequently Asked Questions

How does OWASP define prompt injection?

OWASP defines a prompt-injection vulnerability as one that occurs when input to a large language model alters the model's behavior in ways the application developer did not intend. The input can be direct user text, retrieved content, tool output, an image, audio, video, intermediate reasoning, or persistent memory.

The definition splits into direct injection, where a user or someone with the user's access path supplies the input, and indirect injection, where the model ingests content from an external source that the user neither wrote nor saw. Jailbreaking is treated as a subset of direct injection where the attacker's goal is specifically to make the model violate its safety protocols. The reason OWASP considers prevention structurally hard is that models make no architectural distinction between instructions and data, so there is no parameterized-query equivalent to reach for, and defenses work by layering rather than by closing the hole.

What is OWASP ASVS?

The Application Security Verification Standard is OWASP's list of specific security requirements to verify in an application, currently at version 5.0.0 from May 2025, with roughly 350 requirements across 17 chapters. Where the Top 10 raises awareness of common risks, ASVS gives you something testable, which is why it tends to show up in contracts and procurement rather than in training material.

It is relevant to LLM applications through output handling in particular, since the OWASP entry on improper output handling points at ASVS directly for validation, sanitization, and context-aware encoding guidance. OWASP also runs a separate AISVS project applying the same verification approach to AI systems specifically.

How does OWASP recommend preventing XSS?

Context-aware output encoding is the primary control, meaning data gets encoded for the context it lands in, whether that is HTML, JavaScript, or a URL, rather than filtered once on the way in. OWASP pairs that with input validation, parameterized handling of anything reaching a database, and a strict Content Security Policy as defense in depth. In the 2025 web Top 10, cross-site scripting sits inside A05 Injection rather than carrying its own category.

For LLM applications the same control applies at a new point in the pipeline. Model output is attacker-influenceable by definition, so rendering it in a browser without encoding produces XSS the same way unescaped user input does, which is exactly what LLM10:2026 Improper Output Handling names as an outcome. The practical rule OWASP gives is to treat the model as an untrusted user and validate its responses before they reach any downstream component.