LLM Vulnerabilities: The OWASP Top 10 Every Security Team Should Know

An LLM vulnerability is a weakness in how a large language model application processes input, handles data, or integrates with other systems that an attacker can exploit to leak information, bypass controls, or manipulate output. The authoritative reference is the OWASP Top 10 for LLM Applications, which catalogs the most critical risks — from prompt injection to sensitive information disclosure — specifically for teams deploying models like GPT, Claude, or open-source LLMs in production. In cybersecurity, "LLM" simply means the large language model itself, treated as a new attack surface that traditional AppSec tooling was never designed to cover.

The OWASP Top 10 for LLM Applications

OWASP published its LLM-specific list because standard web vulnerability frameworks miss the unique failure modes of generative AI. The OWASP Top 10 for LLM Applications v1.1 is the closest thing to a canonical "LLM vulnerabilities list" — and you'll find community mirrors and mapping repos on GitHub if you want machine-readable versions. The ten risks are:

• LLM01: Prompt Injection — malicious input that overrides system instructions.
• LLM02: Insecure Output Handling — trusting model output without sanitization, leading to XSS or code execution.
• LLM03: Training Data Poisoning — corrupting the data the model learns from.
• LLM04: Model Denial of Service — resource-exhausting queries that spike cost or degrade service.
• LLM05: Supply Chain Vulnerabilities — compromised third-party models, datasets, or plugins.
• LLM06: Sensitive Information Disclosure — the model leaking data it shouldn't.
• LLM07: Insecure Plugin Design — plugins with weak input validation or excessive privileges.
• LLM08: Excessive Agency — giving the model too much autonomy to take real-world actions.
• LLM09: Overreliance — humans trusting hallucinated or wrong output without verification.
• LLM10: Model Theft — unauthorized extraction of proprietary model weights.

What is the biggest problem with LLMs?

The single hardest problem to defend is prompt injection (LLM01), because there is no clean separation between instructions and data — everything the model sees is text. An attacker can hide malicious instructions in a web page, PDF, or email that your LLM later processes, and the model has no reliable way to tell the difference between your trusted system prompt and the poisoned content. This is why "excessive agency" (LLM08) is so dangerous when combined with injection: if your model can send emails or execute code, a successful injection turns a text trick into real damage.

The second recurring problem is data leakage. According to the OWASP Top 10 for LLM Applications v1.1, Sensitive Information Disclosure ranks as risk #6, and OWASP notes that LLMs can memorize and reproduce training data — including PII, credentials, and proprietary code. If you fine-tune a model on internal documents, that data can resurface in responses to entirely different users.

How to prioritize LLM vulnerabilities

Not every risk on the list applies to every deployment. Prioritize based on what your application actually does:

• If your LLM takes actions (calls APIs, runs tools, sends messages): fix LLM01, LLM07, and LLM08 first. This is the highest-blast-radius combination.
• If your LLM renders output in a browser or shell: LLM02 (Insecure Output Handling) is your priority — treat model output as untrusted user input and sanitize it.
• If you fine-tune or use RAG on internal data: focus on LLM06. Scope access controls per user, and never fine-tune on secrets you can't afford to leak.
• If you use open-source or third-party models: LLM05 matters — verify model provenance and pin dependency versions.

A worked example: locking down an internal chatbot

Say you build a support chatbot with RAG over your knowledge base and a tool that can create Jira tickets. The concrete controls, mapped to OWASP:

• LLM01: Put user input in a clearly delimited section of the prompt, and validate tool-call arguments against a strict schema before execution.
• LLM06: Filter retrieved documents through the requesting user's access permissions before they reach the model — don't rely on the model to keep secrets.
• LLM08: Give the Jira tool least privilege (create only, no delete), and require human confirmation for any write action.
• LLM02: Escape model output before rendering it in your web UI to prevent stored XSS.

The pattern is consistent: treat the model as an untrusted component sitting between untrusted input and privileged systems, and enforce