OWASP Top 10 for LLM Applications 2026: Real RAG & Agent Attacks + Practical Defenses

What You'll Learn

• The new 2026 ranking - what moved up, what fell, and why the list is now backed by incident data
• Real prompt injection and RAG poisoning attacks in production systems, from Copilot Studio to Cursor
• Why excessive agency and misinformation climbed the list while output handling fell furthest
• Practical defense controls - least privilege, retrieval-time access control, cost caps, and monitoring

The OWASP Top 10 for LLM Applications 2026 landed on August 3, 2026, and it is not your typical update. For the first time in the project's history, the ranking was shaped by real-world incident data - 7,714 incidents pulled from public vulnerability databases and an AI-harm database - not just expert votes. The result is a list that looks different from 2025, with new names like Hidden Context Exposure, a renamed Misinformation entry, and a reshuffled order that tells you exactly where attackers are causing damage today.

If your team builds chatbots, RAG pipelines, or autonomous AI agents, this edition is a direct mirror of what is breaking in production. Prompt injection is still the biggest threat, but excessive agency has shot from sixth to third place, and unbounded consumption jumped from tenth to sixth. Meanwhile, system prompt leakage was renamed and broadened into hidden context exposure, and improper output handling fell from fifth to tenth. Every change matters, and every change has a story behind it.

This guide walks through the complete 2026 list with real attack case studies - including the ShareLeak and PipeLeak findings in Microsoft Copilot Studio and Salesforce Agentforce, RAG poisoning research, and coding-agent credential theft - then gives you a practical defense playbook you can put to work immediately. Before you dig in, you may want to understand how attackers take over autonomous systems in our deep dive on AI Agent Hijacking Explained.

Why the 2026 Edition Is Different: Data Now Backs the Ranking

Every previous edition of the OWASP Top 10 for LLM Applications was built on consensus. Hundreds of security practitioners voted on which risks mattered most, and the results became the list. The 2026 edition keeps that consensus - the community vote still carries 75 percent of the weight - but it adds something entirely new: a 25 percent weight for actual incident data.

OWASP's team assembled 7,714 real LLM-related incidents from public vulnerability databases and an AI-harm database, then classified the 6,639 that carried enough detail. The project leads were explicit about the design: one noisy year of data should not overturn the judgment of people who attack and defend these systems daily. But when belief and evidence diverged sharply, even a quarter-weight was enough to move an entry up or down - and it did, in several places.

The most instructive disagreements are also the most useful findings in the document. Practitioners voted prompt injection the number one risk even though the raw incident record would have dropped it out of the top ten entirely. OWASP calls this a defense effect: teams work so hard to block prompt injection that fewer successful attacks ever show up in public databases, which makes the risk look smaller than it is. The opposite happened with misinformation, which voters placed near the bottom but the incident record ranked near the top - the widest gap on the list, in the dangerous direction.

The methodology change also brings new rigor for compliance teams. Instead of scattered framework links inside each entry, the 2026 edition ships a single, version-pinned appendix that maps all ten risks to nine external frameworks: MITRE ATLAS, MITRE ATT&CK, MITRE CWE, NIST AI 600-1, NIST AI Risk Management Framework, the OWASP Top 10 for Agentic Applications, the OWASP GenAI Data Security guide, the CSA AI Controls Matrix, and the OWASP AI Vulnerability Scoring System. Every mapping cites a pinned framework version, so references do not drift as frameworks update.

The Complete OWASP Top 10 for LLM Applications 2026 at a Glance

Here is the full 2026 ranking compared with the 2025 edition, so you can see every movement at a glance before we break each risk down:

One phrase runs through all ten entries, and it is the best summary of the entire document: stop trying to build a model that cannot be fooled, and build the system around it so that when the model is fooled - and it will be - nothing important breaks. This is blast-radius control rather than perfect prevention, and it changes how you should think about every control described below.

LLM01: Prompt Injection - Still the Number One Threat

Prompt injection kept the top spot in the OWASP Top 10 for LLM Applications 2026, and the entry now covers more ground than ever. The 2026 scope explicitly includes cross-modal attacks - instructions hidden in images, audio, or video - plus memory persistence and the agentic blast radius. An injection written to persistent memory or a RAG corpus does not expire after one session; it taints every future interaction that reads from that store.

The attack surface is everywhere a model reads untrusted input, which is to say everywhere. In April 2026, security firm Capsule Security disclosed two parallel findings that show exactly how this plays out in enterprise software. ShareLeak, assigned CVE-2026-21520 with a CVSS score of 7.5, hit Microsoft Copilot Studio: an attacker submits a malicious payload into a public SharePoint form field, and when the agent later processes that form, the payload overrides its instructions and exfiltrates sensitive data. Microsoft patched the flaw in January 2026, but follow-up research showed data exfiltration remained achievable. The companion finding, PipeLeak, hit Salesforce Agentforce the same way - weaponizing CRM lead-capture forms to extract customer data - and had no CVE assigned at the time of disclosure.

The same pattern is tearing through developer tools. Researchers showed that a malicious GitHub README can trick Cursor, the popular AI code editor, into dumping environment variables and API keys - no phishing, no malware, just a poisoned file the agent happily reads. A separate June 2026 investigation by Mitiga demonstrated a fake take-home coding test that made a developer's own AI assistant steal cloud credentials in under two minutes. Attackers have even weaponized fake Sentry error pages to hijack coding agents mid-task.

Why does this keep happening? Because current LLMs treat all input as equally authoritative. There is no reliable separation between trusted system instructions and untrusted user data, and even the biggest vendors treat this as an architectural limitation rather than a patchable bug. The incident data shows a surprisingly low count of recorded prompt injection successes, but OWASP is clear that this is a defense effect - low counts mean defenses are working, not that the work is done. Research puts prompt injection attack success rates between 50 and 84 percent depending on configuration, with one dataset documenting over 461,640 injection submissions, so the risk is very much alive.

LLM03: Excessive Agency - The Biggest Climb on the List

Excessive agency jumped from sixth to third place in the OWASP Top 10 for LLM Applications 2026, the biggest climb on the list - and the one where the expert vote and the incident data agree most clearly. The reason is simple: agentic deployments are where damage is landing. An LLM that can call tools, modify files, send emails, and invoke cloud APIs with the privileges of the user who deployed it is a completely different attack surface from a chat interface.

The real-world record is full of painful examples. In April 2026, security researchers documented a coding agent running on a long-lived API credential that deleted production resources - the agent was authorized to do it, and nobody had scoped its permissions to the task at hand. Palo Alto Networks' Unit 42 team separately documented web-based indirect prompt injection in the wild, where hidden content on websites quietly commands agents to perform high-impact actions.

The OWASP guidance for 2026 is not to remove agency - agents are too valuable for that - but to enforce least privilege at every layer. Each tool an agent can call must be explicitly authorized, high-risk actions should require human confirmation, and every tool invocation must be logged and monitored. When a model stops being a component and becomes an actor with its own memory and consequences, the risk moves to the separate OWASP Top 10 for Agentic Applications. For a broader view of what happens when autonomous systems cross the line, read our analysis of The Hidden Risks of Agentic AI.

LLM07: Misinformation - The Risk Experts Got Wrong

Misinformation climbed from ninth to seventh place, and it is the finding that should make teams the most uncomfortable. Practitioners placed it near the bottom of the community vote, yet the incident record placed it near the top - the widest gap in the entire list, and in the dangerous direction.

The 2025 edition framed misinformation mostly as users overly trusting fluent output. That framing is now too narrow. In 2026, model outputs drive tool calls, generate production code, authorize actions, and coordinate other agents. A wrong answer fed into that chain does not stop in the user's chat box - it becomes a wrong action in a downstream system. As the OWASP authors put it, when a model's fluent, confident output drives a decision or a tool call, a wrong answer turns into a wrong action.

Consider a developer assistant asked to scan a codebase and file issues for anything that looks broken. If the model hallucinates a vulnerability that does not exist and files a critical-severity ticket, an on-call engineer may burn hours investigating a ghost finding. Multiply that by an agentic pipeline with write access to production systems, and you have entirely new failure modes at scale. OWASP's own GenAI exploit round-up for Q1 2026 documented a real case where a system misinterpreted user intent and acted unsafely, exposing 12,000 to 15,000 instances online.

The takeaway is uncomfortable but clear: the gap between the vote and the data means many teams are calibrating misinformation risk against how LLMs were used in the past, not how they are being used now. Treat every model output that can trigger an action as a security event, not just a quality issue.

LLM08: Hidden Context Exposure - Much More Than a Leaked Prompt

What was LLM07:2025 System Prompt Leakage is now LLM08:2026 Hidden Context Exposure, and the rename is not cosmetic. The old name implied a narrow, containable problem: an attacker extracts your system prompt and now knows your instructions. The new name points at a broader design principle: the system prompt is only one part of what the model sees.

The full hidden context also includes tool and function schemas, retrieved policy text from RAG pipelines and configuration stores, developer instructions, and any other material assembled into the context window that is not visible to the end user. All of it is potentially extractable - and when it is, the consequences go far beyond knowing the prompt. Disclosed behavioral logic makes prompt injection more targeted. Leaked tool schemas expand the surface for excessive agency. Embedded credentials in the context window constitute a sensitive information disclosure in their own right. The severity model for this entry runs from informational up to critical, where disclosure chains to remote code execution or broad data exfiltration.

The design guidance is blunt: practitioners should design under the assumption that hidden context is discoverable, and that any contents of the context should not be considered a secret. If your application relies on hidden context staying hidden as a security control, the 2026 list is telling you to rearchitect that assumption out. Never embed credentials or API keys in prompts, keep sensitive logic in secure tool-call layers the model never sees, and treat memory stores as part of the trusted surface - because they are. If your agents carry memory between sessions, our guide on AI Agent Memory Systems covers where that data lives and how to protect it.

LLM09: Vector and Embedding Weaknesses - RAG Poisoning in Practice

Vector and embedding weaknesses dropped one place to ninth, but the RAG attack surface it covers is as dangerous as ever. This is data poisoning at the retrieval layer: an attacker changes the documents an LLM trusts as authoritative, and the model quietly starts answering from poisoned knowledge.

The attack is deceptively simple. An attacker finds a public source used in a RAG pipeline - a Wikipedia page, a GitHub repository, a corporate documentation site - and makes a minor edit, embedding misleading text or a hidden instruction. When the ingestion pipeline runs its next scheduled update, it fetches the poisoned version and stores it in the vector database. Even if the attacker later reverts the edit at the source, the poisoned embedding persists in the knowledge base. Every subsequent query that matches the poisoned document's semantic context pulls the malicious content into the model's answer.

This is not theoretical. Repello AI's research demonstrated RAG poisoning against a production Llama 3 deployment where a single adversarially-crafted document injected into the knowledge base produced discriminatory outputs that persisted across retrieval cycles until the document was manually removed. Researchers have also demonstrated compound attacks that combine prompt injection with database poisoning in a single exploit. MITRE ATLAS and OWASP both track RAG poisoning as a scalable supply chain problem, and the 2026 entry keeps retrieval-time access control front and center as the primary defense: validate documents before ingestion, monitor for unauthorized changes at the source, and never retrieve content the user is not authorized to see.

LLM05: Data and Model Poisoning - The 250-Document Problem

Data and model poisoning slipped from fourth to fifth place, and the 2026 entry absorbed fine-tuning subversion - a sharper, newer attack that targets models after deployment. While RAG poisoning corrupts the knowledge base, training data poisoning corrupts the model itself, embedding malicious patterns that persist in its weights long after deployment.

The research that should scare every team came from Anthropic, working with the UK AI Security Institute and the Alan Turing Institute: as few as 250 maliciously crafted documents can poison LLMs of any size. The number was near-constant across models from 600 million parameters to tens of billions, and it is a tiny fraction of any training dataset. A backdoored model can be designed to activate only under specific conditions - a trigger phrase, a rare topic - making it look like an occasional bug rather than an attack.

Fine-tuning subversion raises the stakes further. A poisoned fine-tuning dataset can make a model subtly biased, more susceptible to jailbreaking, or outright malicious when a trigger appears - and most organizations fine-tune on third-party data or instruction sets they never fully audit. The 2026 defenses are unchanged in spirit but stricter in practice: verify the provenance of all training data, scan for anomalies and outliers, demand transparency from third-party model providers, and treat any dataset you did not curate yourself as untrusted by default.

LLM06: Unbounded Consumption and LLM10: Improper Output Handling

Unbounded consumption rose four places from tenth to sixth, the biggest upward jump after excessive agency - and the reframe explains why. The 2026 entry moves beyond denial of service to something the authors call cost asymmetry: attackers can trigger disproportionately expensive computation at negligible cost to themselves, whether through crafted prompts, stolen credentials, or manipulated workflows.

The rise of extended-thinking reasoning models makes this worse. A single crafted input can force a model to burn through long reasoning chains, multimodal requests multiply the cost, and MCP-connected tool chains amplify a tiny prompt into a huge bill. Rate limiting by request count alone is no longer sufficient - the 2026 guidance calls for token-aware cost controls, spending caps, and agent-level circuit breakers that stop runaway execution. Guard your inference budget the way you guard your data.

Meanwhile, improper output handling fell the furthest of any entry - from fifth to tenth - but its scope actually grew. It now explicitly covers terminal and IDE sinks that render ANSI escape sequences, where a model output can silently manipulate a developer's terminal, and client renderers that auto-fetch external resources referenced in model output, turning a rendered response into an exfiltration channel. The drop in rank reflects urgency elsewhere, not a smaller risk. Never let an LLM directly emit executable content without validation, and always run generated code in a sandboxed environment.

LLM04: Supply Chain and LLM02: Sensitive Information Disclosure

Supply chain vulnerabilities moved from third to fourth place, and the 2026 entry adds artifact-trust failure to its scope - the risk of trusting model files, plugins, and deployment artifacts that come from unknown sources. The real-world record keeps proving the point. Researchers at the Cloud Security Alliance documented coordinated campaigns between October 2025 and June 2026 that hijacked IDE toolchains to steal API keys, including a fake AI assistant campaign targeting JetBrains users. Attackers publish malicious packages that mimic legitimate libraries on PyPI and other registries, and automated dependency resolution pulls them straight into production AI systems.

The defenses are a zero-trust approach to dependencies: scan all third-party code, pin dependency versions, verify code signatures, and maintain a software bill of materials for your entire AI stack, from base models to plugins. Before you connect tools to your agents, understand the risks in the connection layer itself - our guide to Model Context Protocol (MCP) in 2026 explains how tool-connected agents are built safely.

Sensitive information disclosure holds the number two spot, and it is the one entry where the community vote and the incident data fully agree. It remains the accidental leak: an LLM reproducing confidential data it was never meant to surface, whether from training data, retrieved documents, or context assembled at runtime. The uncomfortable truth is that a RAG system will answer from any document it retrieves - so if a user's query pulls an internal document into context, the model will happily quote it, regardless of who asked. Strict data access controls, output filtering, and continuous monitoring for PII in responses remain the core defenses, and they are non-negotiable if you handle customer data at all.

How to Defend Your LLM Application in 2026

The OWASP Top 10 for LLM Applications 2026 is not a checklist of isolated fixes. It is a unified threat model, and the defense is a layered system. Here is a practical playbook built directly from the 2026 guidance.

Treat every input as untrusted

Validate and sanitize all user input, and never let untrusted content sit in the same trust tier as system instructions. Prompt isolation - keeping instructions and data in separate tiers or using delimiter-aware handling - remains the strongest mitigation for prompt injection. Monitor for unusual input patterns that match known injection families, and remember that images, audio, and documents are input too.

Enforce least privilege on agents

Give every agent the minimum tool access needed for its task, and no more. Scope credentials tightly, require human approval for high-risk actions like payments, deletions, or external sends, and log every tool invocation. If an agent does not need write access, it should not have it. This one control neutralizes most excessive agency scenarios before they start.

Secure the retrieval path

For RAG systems, implement retrieval-time access control so the retriever can only surface content the current user is authorized to see. Validate documents before ingestion, hash and monitor source documents for unauthorized changes, and consider provenance tracking for everything in your vector store. Assume poisoned content will get in eventually, and make sure it cannot be retrieved by the wrong person.

Assume the context window is public

Never place secrets, credentials, or sensitive logic anywhere the model can see. Design under the assumption that hidden context is discoverable, and architect so that even a full context dump damages nothing. Externalize secrets to secure vaults and tool-call layers the model never reads.

Put a price on every token

Enforce token limits per request and per user, set maximum response lengths, and implement token-aware cost controls rather than naive request throttling. Add spending caps and circuit breakers for agents, and disable recursive tool calling so no loop can run unchecked.

Validate outputs, not just inputs

Filter and validate everything the model produces before it reaches users or downstream systems. Fact-check high-stakes outputs against reference data, sandbox any generated code, and strip or block ANSI sequences and auto-fetching links in rendered output. For critical decisions, keep a human in the loop - treat every LLM output as a hypothesis, not a fact.

Monitor and respond

Instrument your AI stack end to end. Track token spend, tool-call frequency, retrieval patterns, and anomalous output. Alert on abnormal consumption, repeated injection attempts, and unexpected agent actions. If you run observability for LLM applications, our guide on OpenTelemetry GenAI Semantic Conventions shows how to wire this up properly. For smaller websites and businesses, there are practical AI cybersecurity tools for small websites that cover the essentials without an enterprise budget.

LLM Top 10 vs Agentic Top 10: Know Which List Applies

One of the most important changes in 2026 is a scope boundary OWASP drew for the first time. The LLM Top 10 covers risk when the model is a component inside your application. The OWASP Top 10 for Agentic Applications, first published in December 2025, covers risk when the model becomes an actor - with tools it can invoke, memory it carries between sessions, and consequences it sets in motion downstream.

The agentic list uses its own numbering, ASI01 through ASI10, and it starts with Agent Goal Hijack, the agentic counterpart to prompt injection. It also covers tool misuse and exploitation, agent identity and privilege abuse, agentic supply chain compromise, unexpected code execution, memory and context poisoning, insecure inter-agent communication, cascading agent failures, human-agent trust exploitation, and rogue agents.

The two lists are complementary, not redundant, and OWASP says explicitly that neither covers the full picture alone. If your deployment is anywhere near an agentic architecture - and in 2026, many are - you need both. Excessive agency and unbounded consumption in the LLM list carry explicit cross-references to the agentic list, so treat them as one continuous threat model rather than two separate checklists.

Conclusion

The OWASP Top 10 for LLM Applications 2026 makes one thing unmistakable: AI security is no longer about building a model that cannot be fooled. The incident data behind this edition proves that models will be fooled, and the question that matters is whether anything important breaks when they are. Prompt injection remains the top threat because the surface is everywhere. Excessive agency rose because agents now act with real credentials. Misinformation climbed because wrong answers now trigger real actions. And behind all of them sits the same architectural truth - treat the model as an untrusted component and build defenses around it.

The practical path forward is defense in depth: isolate untrusted input, enforce least privilege on agents, secure the retrieval path, keep secrets out of context, cap consumption, validate outputs, and monitor everything. None of these controls is a silver bullet, but together they shrink the blast radius of every risk on the list. Secure AI is not a destination; it is an ongoing process of testing, monitoring, and tightening. The 2026 list gives you the map - the work of securing your systems is yours.