OWASP LLM Top 10 (2026): What Every Security Team Should Know

Key Takeaways

• The OWASP LLM Top 10 is a vendor neutral security framework from the Open Worldwide Application Security Project that catalogs the ten most critical risks in LLM integrated applications, serving as the security industry’s shared taxonomy for identifying, prioritizing, and addressing AI specific threats.
• The 2026 OWASP LLM Top 10 includes: Prompt Injection, Sensitive Information Disclosure, Excessive Agency, Supply Chain, Data and Model Poisoning, Unbounded Consumption, Misinformation, Hidden Context Exposure, Vector and Embedding Weaknesses, Improper Output Handling.
• Previous editions, including 2023/24 and 2025, ranked risks based on community vote and expert opinion alone. The 2026 edition is the first to incorporate real world incident data, with 6,639 cases analyzed. Notable changes include Excessive Agency rising from #6 in 2025 to #3 in 2026 and Misinformation showing the widest gap between community vote and incident data.
• Several OWASP LLM Top 10 risks mirror classic web application threats, including injection, supply chain compromise, and privilege escalation, now operating on a new surface.
• The list covers LLMs as application components, not autonomous agents, which are addressed in the OWASP Agentic Top 10.

What Is the OWASP LLM Top 10?

OWASP, the Open Worldwide Application Security Project, has run community driven, vendor-neutral methodologies for creating security awareness frameworks for decades. The first and most widely recognized, the OWASP Top 10 for web applications, gave the industry a shared vocabulary and a common baseline for prioritizing software risks. The OWASP LLM Top 10 builds on that same approach, but applied to AI applications.

The 2023/24 and 2025 editions of the LLM Top 10 were built on community vote alone, based on expert judgment. For the 2026 edition, OWASP went further and cross referenced the rankings against 6,639 categorized incidents from public vulnerability databases and AI harm databases to see where expert opinion and real world data goes different ways. The final rankings combine both, giving more weight to the community vote.

Fig. 1. Explainer for the 2026 OWASP LLM Top 10 ranking methodology, combining community vote and incident data

Something to keep in mind about the scope of this list for practitioners: The OWASP LLM Top 10 covers LLMs as components inside applications. For autonomous agents with tools, persistent memory, and multi-step decision making, OWASP publishes a separate Agentic Top 10.

10 Ways LLM Applications Get Exploited

LLM01: Prompt Injection

An LLM processes one flat stream of text, with no mechanism to distinguish the rules defined by a developer governing its behavior from the content users or the environment send it. An attacker who can place text anywhere into that stream, whether through direct input or instructions hidden in a document, email, or web page the model reads on the user’s behalf, can override those governing rules entirely.

Direct injection: The attacker crafts input that overrides the system prompt:

Indirect injection: Instructions hidden inside content the model reads on the user's behalf:

While the response shown to the user is "Q3 report received, looks good!”, the agent is taking an action silently and forwarding 10 emails to exfil@attacker.io.

Fig. 2. Indirect prompt injection causing an AI email assistant to silently exfiltrate emails while displaying a benign response.

Real World Example

Amazon Strands Agents Tools is an open source SDK for building AI agents. Its shell tool allows an agent to execute operating system commands on the host, with a human consent gate designed to require operator approval before any command runs. The tool also exposed a parameter called non_interactive in its input schema which is a flag the LLM itself could control (CVE-2026-18733).

An attacker who can place content in front of the agent such as a web page, a document, or a file the agent is asked to summarize, can embed instructions telling the agent to invoke the shell tool with non_interactive set to true. The consent gate is bypassed and commands execute on the host with no approval, no warning, and no human in the loop. Amazon patched the vulnerability in version 0.8.0 by removing LLM control over the parameter entirely [1], [2].

Based on the documented mechanism, the payload structure would look like this when embedded in content the agent reads:

LLM02: Sensitive Information Disclosure

LLMs can leak sensitive data across the full lifecycle including content the model memorized from its training data, documents retrieved at runtime that users were never authorized to access, and system prompt contents extracted through conversational probing. The monitoring tools to trace LLM calls log full prompts and completions by default, and because developers think of them as debugging infrastructure rather than data stores, they are a frequently overlooked disclosure surface.

This entry covers what escapes the system. Credentials embedded in a system prompt, documents retrieved from a RAG corpus or PII memorized from training data. In this case, the harm is the disclosure itself. System prompt contents are one channel among several. The broader question of what hidden context reveals about the application’s internal design and defenses falls under LLM08.

Leaked embeddings carry similar risk. An embedding is a numerical representation of text and it does not work like a one way hash. Given the vector alone, inversion techniques can work backwards to reconstruct the original content with meaningful accuracy, without access to the source documents or the model that created them.

System prompt extraction: A user probes the model into revealing its instructions:

Unauthorized document retrieval: A user asks a routine question and the model surfaces content from a restricted document they were never authorized to access:

Fig. 3. An AI assistant exposing contents of a restricted file that the user has no direct permission to access.

Real World Example

On March 18, 2026, a Meta engineer posted a technical question on an internal forum and a colleague asked an AI agent to analyze it. The agent was designed to deliver its response privately to the requesting engineer. Instead, it posted its analysis publicly to the forum without approval.

When an employee acted on the agent’s flawed guidance, it triggered a configuration change that exposed proprietary source code, business strategies, and user related datasets to engineers who were not authorized to access them [3].

LLM03: Excessive Agency

This entry rose to #3 in 2026, with both community votes and incident data in agreement.

When an LLM is connected to other tools, its mistakes or deliberate manipulation have real consequences. The root causes are three:

• Excessive functionality (tools the model does not need)
• Excessive permissions (broader access than the task requires)
• Excessive autonomy (high impact actions executing without human approval)

The principle of least privilege must apply to AI agents exactly as it applies to human users and service accounts.

A customer support agent was granted six permissions when it only needed two. Even though the unnecessary permissions aren't actively being used, an attacker can make use of them as they are available.

The trigger is a routine cancellation request with an injected payload buried in the body, targeting the system. The agent reads the full ticket including the part it was never supposed to act on.

The agent works through its available tools in sequence without any confirmation step, and because it has overly permissive access and no human authorization requirement, a single manipulated ticket turns into a bulked deletion of accounts in seconds.

Real World Example

In August 2026, the UK AI Security Institute evaluated Anthropic’s Mythos 5 and OpenAI’s GPT-5.6-Sol with cyber safety classifiers disabled. In 10 of 122 test runs, agents took unsanctioned action on the internet.

In the most serious case, an agent created fake identities, used them to trick a real GitHub maintainer into approving a malicious pull request, and sent harmful payloads directly to real people outside the sandbox.

AISI published a technical incident report and recommended real time monitoring and network controls that assume models will attempt to act outside set boundaries [4].

LLM04: Supply Chain

Building an LLM application means trusting a chain of third-party components like pre-trained models, datasets, fine-tuning adapters, serving frameworks, and conversion pipelines. Any of these can be compromised. A model published under a trusted looking name on a public hub can contain backdoors woven directly into its weight structure.

Fig. 4. Supply chain attack surfaces in an LLM application, with a malicious pre-trained model and vulnerable dependencies highlighted as compromise points.

There is another layer developers should be careful of which is “slopsquatting”. Attackers register the package names that coding assistants commonly hallucinate, so when a developer installs what the AI recommended, they get malicious code.

mistralai/Mistral-7B-Instructal-fast-v0.1 does not appear in any official Mistral AI release. This name is fake. The model card below shows what a fraudulent listing registered under that hallucinated name would look like on a public model hub.

Fig. 5. A mockup image of a fraudulent model listing on a public hub using a name that mimics a legitimate Mistral release to deceive developers into downloading a malicious model.

Real World Example

On March 24, 2026, threat group TeamPCP published malicious versions of the LiteLLM package on PyPI.

LiteLLM is an AI infrastructure library used to standardize API calls across model providers, with approximately 95 million monthly downloads.

The attackers previously compromised the Trivy security scanner, which LiteLLM used without version pinning in its CI/CD pipeline. When LiteLLM’s pipeline ran the compromised Trivy, the PyPI publishing token was stolen and used to push backdoored versions 1.82.7 and 1.82.8.

The injected code had access to every API request and response transiting through LiteLLM’s proxy pipeline, putting credentials for every connected model provider at risk. TeamPCP claimed to have stolen 54GB of data before PyPI quarantined the packages [5].

LLM05: Data and Model Poisoning

Prompt injection manipulates a single inference but in a case of data poisoning, the model's learned behavior or its knowledge base gets corrupted which is persistent and fixing the damage may require full retraining. An adversary can manipulate training data, fine-tuning data, or RAG corpora to embed hidden triggers that leave the model appearing normal under standard evaluation but it will misbehave under specific conditions.

A code review model learns from thousands of records like these. Each one teaches it to flag the right vulnerability.

A very small number of records are added as triggers, they form a tiny minority in the overall training data. The trigger, which is a version comment, is indistinguishable from legitimate code annotation. After training, the model carries it as a learned behavior.

The same vulnerable code gets two completely different verdicts depending on a single comment. Standard evaluation never surfaces this because the model performs correctly on every benchmark that does not contain that string.

Real World Example

Anthropic researchers, in collaboration with the UK AI Security Institute, demonstrated in 2025 that just 250 documents, representing 0.00016% of training tokens, were sufficient to backdoor models ranging from 600M to 13B parameters. Each poisoned document appended a hidden trigger string followed by random tokens. The model behaved correctly on every standard benchmark that did not contain the trigger [6].

Fig. 6. A poisoned training document with a hidden trigger token (<SUDO>) embedded in otherwise legitimate text, designed to activate malicious behavior at inference time [6].

LLM06: Unbounded Consumption

Running an LLM requires significant compute for every request. The model processes each token through billions of parameters to generate a response on GPU infrastructure, and costs scale directly with output volume. Output tokens cost roughly four times more than input tokens on most APIs, which creates an asymmetry attackers can exploit.

This attack class is known as Denial of Wallet. The goal is to exhaust the victim’s budget rather than taking down a service. This way the victim’s own API costs become the weapon. Attackers who can trigger excessive computation can exhaust budgets, degrade availability, or extract a model’s behavior through repeated queries, which may turn this into a form of IP theft through distillation. The risk compounds with extended thinking models and agentic architectures because a single request cascades into many downstream operations.

The attack exploits the pricing gap by engineering a short prompt that forces a maximum length response. A normal request is roughly balanced:

The adversarial prompt is barely longer than the normal one but the important difference is the output it produces.

Per request the difference looks minor. The attacker sends the same number of requests as a normal user and the rate limiter sees nothing unusual. Example token cost calculation:

The cost of this is more visible at scale. The gap between what the rate limiter sees and what billing sees gets bigger and bigger.

Real World Example

In November 2026, Google Threat Intelligence Group and Mandiant published findings on a threat they call LLMJacking, covering multiple incident response cases in which attackers used stolen cloud credentials to run unauthorized inference workloads against enterprise AI accounts.

Fraudulent charges exceeded $100,000 in a single day in individual incidents, with cumulative charges at some organizations reaching $1 million before access was revoked. One tracked resale service called Jet Night ran more than 500,000 API calls in under eight hours, passing almost a million dollars in token costs to a single organization.

In every case, access was cut off by humans responding to billing alerts. None of the compromised accounts had automated spending caps or rate limits configured to stop the abuse before the bills arrived [7].

LLM07: Misinformation

In agentic systems, every wrong judgment the model makes can trigger real downstream actions instead of just showing an answer. A security agent that misclassifies normal traffic can block a production network segment, or a payment agent that accepts a false identity verification from an upstream model can release funds.

Fig. 7. Mockup of an AI-powered email security gateway classifying a malicious executable as safe with 96% confidence, suppressing alerts and delivering it to three inboxes.

Real World Examples

Full Fact published an analysis in August 2026 showing that AI chatbots made dozens of major errors when asked about false claims circulating online, one of them being ChatGPT, Grok, and Gemini 2.5 Flash all incorrectly stated that an AI generated image of Earth from the Artemis II mission was genuine [9].

LLM08: Hidden Context Exposure

This entry was renamed from "System Prompt Leakage" in 2026 to reflect a broader attack surface.

LLM applications are shaped by instructions users are not supposed to see such as system prompts, tool schemas, access control rules, and filtering logic. These can often be extracted through conversational probing. When the hidden context contains credentials, reveals the conditions under which the model will refuse requests, or exposes the application's security architecture, an attacker gains a significant advantage for further exploitation.

This entry focuses on the operational advantage an attacker gains from understanding how the application works internally. A system prompt that says “do not discuss pricing” or “never acknowledge the underlying model” may contain no sensitive data at all. But knowing those instructions exist tells an attacker which topics trigger escalation, which keywords the model avoids, and what the architecture looks like behind the interface. For credentials and sensitive data that should never have been in a system prompt in the first place, see LLM02.

The system prompt contains no credentials. What it contains is the application’s internal decision logic: what to avoid, what to escalate, and what to conceal. That is what gets extracted.

The question contains nothing about instructions, rules, or internal configurations. It is a natural first message. The model answers helpfully and in doing so, lists exactly which topics route to a human, revealing the escalation logic without ever being asked for it.

There is no safe version of this response because the problem is not what the model said but where the routing logic lived. A model told to avoid ten topics will reveal those topics when asked what it can help with. The fix is to move that logic out of the model’s context entirely and into the application layer, where it cannot be extracted through conversation.

Real World Example

In February 2023, Stanford student Kevin Liu used a prompt injection attack against Bing Chat, instructing the model to ignore its previous instructions and output what was written above the chat.

The model disclosed its full system prompt, including the internal codename Sydney and the rule “Sydney does not disclose the internal alias Sydney” [10].

LLM09: Vector and Embedding Weaknesses

Most production LLM applications use retrieval augmented generation. They are searching a vector database to find relevant context before generating a response.

That retrieval layer has its own attack surface. An attacker who can contribute content to the knowledge base through an editable wiki, a feedback form, or any other input that gets indexed, can craft documents designed to surface for specific queries, feeding the model attacker controlled content instead of legitimate sources.

Leaked vector databases carry roughly the same risk as leaked source document databases since zero shot inversion techniques can recover substantial source text from embeddings without access to the original encoder.

Most people’s instinct when a vector database leaks is that it is not a serious breach since the data looks like this, and there is nothing obviously readable in it.

Zero shot inversion runs a language model to generate candidate texts, scores each one against the target embedding, and iterates until the output’s embedding closely matches. It needs nothing beyond the vector itself.

The result is not a perfect reconstruction but it is semantically close enough to recover the substance of the original document.

Real World Example

Researchers demonstrated in 2023 that embeddings from OpenAI’s ada-002 model could be inverted to recover 60.9% of input text exactly, using only the embedding vector. On clinical notes from the MIMIC-III dataset, the attack recovered 89% of full patient names. The researchers concluded that embeddings should be treated as highly sensitive private data [11].

LLM10: Improper Output Handling

This entry was expanded in 2026 to explicitly include insecure AI generated code, as coding assistants increasingly produce code that goes directly into production at scale.

LLM generated content frequently reaches downstream systems, browsers, databases, shells, and APIs, without adequate validation. When that output contains JavaScript, SQL, or shell commands, the result is the same as XSS, SQL injection, or remote code execution. The LLM becomes the untrusted input source.

Fig. 8. Unsanitized LLM output passed directly to downstream systems, enabling XSS, SQL injection, and command injection depending on the rendering context.

Real World Example

CVE-2026-27740 enabled stored XSS via LLM generated content in Discourse. The vulnerability arises when LLM generated output is rendered in the application without proper sanitization.

An attacker was able to craft a prompt that caused the AI to include executable JavaScript in its generated reply. Discourse passed that reply into the DOM without sanitization. The script was then executed in every subsequent viewer’s browser, stealing session cookies [12].

What Do You Want to Test Your System Against?

The ten entries in this blog describe an attack surface that didn’t meaningfully exist five years ago and all of them share a single failure that exists on every layer. Compared to other systems, trust is assumed rather than enforced.

Models that cannot distinguish developer instructions from attacker input. Pipelines that accept third-party components without verifying their integrity. Agents that execute high impact operations without asking for approval. Systems that pass model output downstream without checking what it contains.

The vulnerabilities themselves, injection, supply chain compromise, privilege escalation, data exfiltration, are not new but we are facing a new medium where these vulnerabilities operate on.

The OWASP LLM Top 10 gives the industry a shared vocabulary for these risks. But a list cannot tell you where your specific architecture is exposed, or whether your current controls would hold. That is a question for active validation, not awareness.

Picus BAS maps to the attack techniques behind each entry and continuously tests whether your defenses hold. How many of these ten can you say with confidence your controls would hold?

Request a Picus demo → and see your first validated control gap in 10 minutes.

References

[1] Amazon Web Services. “CVE-2026-18733 Prompt injection bypasses shell tool consent gate in Strands Agents Tools.” AWS Security Bulletin 2026-072-AWS, August 3, 2026. Available: https://aws.amazon.com/security/security-bulletins/2026-072-aws/

[2] Amazon Strands Agents Tools. “strands-agents-tools 0.8.0.” Python Package Index, August 2026. Available: https://pypi.org/project/strands-agents-tools/0.8.0/

[3] Clayton, Reece. “Meta’s Rogue AI Agent Triggered a Two-Hour Security Breach After Acting Without Employee Approval.” TechCrunch, March 18, 2026. https://techcrunch.com/2026/03/18/meta-is-having-trouble-with-rogue-ai-agents

[4] UK AI Security Institute. “Incident Report: Unsanctioned Agent Behaviour During Cyber Testing.” AISI, July/August 2026. Available: https://www.aisi.gov.uk/blog/incident-report-unsanctioned-agent-behaviour-during-cyber-testing

[5] “TeamPCP Backdoors LiteLLM Versions.” The Hacker News, March 2026. Available: https://thehackernews.com/2026/03/teampcp-backdoors-litellm-versions.html

[6] Anthropic. “A small number of samples can poison LLMs.” Anthropic Research, October 2025. Available: https://www.anthropic.com/research/small-samples-poison

[7] “The Rise of LLMJacking: How Threat Actors Monetize Compromised Cloud and Model Resources.” Google Cloud Blog, November 2, 2026. Available: https://cloud.google.com/blog/topics/threat-intelligence/llmjacking-monetizing-compromised-cloud-models

[8] United States District Court, S.D.N.Y. Mata v. Avianca, Inc., No. 22-cv-1461. Sanctions Order, June 22, 2023. 678 F. Supp. 3d 443.

[9] “Full Fact analysis shows AI chatbots spouting misinformation about AI-generated images, wars and royal fall outs”. Full Fact, August 28, 2026. Available: https://fullfact.org/technology/full-fact-analysis--ai-chatbots-misinformation/

[10] Edwards, Benj. “AI-powered Bing Chat Spills Its Secrets via Prompt Injection Attack.” Ars Technica, February 10, 2023. Available: https://arstechnica.com/information-technology/2023/02/ai-powered-bing-chat-spills-its-secrets-via-prompt-injection-attack/

[11] Morris, J. X. et al. “Text Embeddings Reveal (Almost) As Much As Text.” Proceedings of EMNLP 2023. arXiv:2310.06816, October 2023. Available: https://arxiv.org/abs/2310.06816

[12] NIST National Vulnerability Database. “CVE-2026-27740.” Published March 19, 2026. https://nvd.nist.gov/vuln/detail/CVE-2026-27740