LLM Vulnerabilities: The OWASP Top 10 and How to Prioritize Them

An LLM vulnerability is any weakness in a large language model application that an attacker can exploit to make the model leak data, execute unintended actions, or produce harmful output. In cybersecurity, "LLM" refers to the AI models (like GPT-4, Claude, or Llama) increasingly embedded in products — and the new attack surface they create. The authoritative reference is the OWASP Top 10 for LLM Applications, which catalogs the ten risks security teams most need to defend against. The single biggest problem is that LLMs blur the line between data and instructions, making input manipulation (prompt injection) hard to fully prevent.

What "LLM vulnerability" actually means

Traditional software separates code from data. LLMs don't. Every piece of text a model reads — a user message, a retrieved document, a web page it summarizes — is processed the same way, so malicious text buried in "data" can hijack the model's behavior. That single property drives most of the LLM vulnerabilities on any credible list.

This differs from classic application security in three ways worth naming:

• Non-determinism: the same input can produce different outputs, so signature-based defenses and regression tests are unreliable.
• Opaque decision boundaries: you can't read the model's "logic" the way you read source code, so you can't fully audit why it did something.
• Training-time exposure: the data used to train or fine-tune a model becomes part of the model, and can leak later.

The OWASP Top 10 for LLM Applications

OWASP publishes the definitive LLM vulnerabilities list (available on GitHub and the OWASP site). The v1.1 release names these ten risks:

• LLM01 – Prompt Injection: crafted input overrides the system prompt or intended behavior. Includes indirect injection via poisoned documents or web content.
• LLM02 – Insecure Output Handling: passing model output to downstream systems (shells, browsers, SQL) without validation, enabling XSS, SSRF, or RCE.
• LLM03 – Training Data Poisoning: tampering with training or fine-tuning data to introduce backdoors or bias.
• LLM04 – Model Denial of Service: expensive queries that exhaust context windows, compute, or budget.
• LLM05 – Supply Chain Vulnerabilities: compromised third-party models, datasets, or plugins.
• LLM06 – Sensitive Information Disclosure: per the OWASP Top 10 for LLM Applications v1.1, LLMs can memorize and reproduce training data including PII, credentials, and proprietary code.
• LLM07 – Insecure Plugin Design: plugins with weak input validation or excessive access.
• LLM08 – Excessive Agency: giving the model too much autonomy, permission, or functionality relative to what it needs.
• LLM09 – Overreliance: trusting model output without verification, propagating hallucinations into decisions or code.
• LLM10 – Model Theft: unauthorized access to or extraction of proprietary model weights.

How to prioritize: what to fix first

You don't fix all ten at once. Prioritize by exploitability and blast radius:

• Fix first — Insecure Output Handling (LLM02) and Excessive Agency (LLM08). These turn a prompt injection into real-world damage. If the model can't trigger a shell command, delete a record, or send an email without a human check, a successful injection is contained. Treat every model output as untrusted user input: sanitize, encode, and gate high-impact actions behind confirmation.
• Fix next — Sensitive Information Disclosure (LLM06). Scope what the model can access. Don't fine-tune on secrets, strip PII from training and RAG sources, and apply output filtering. Because models memorize training data, the cheapest control is never feeding them data they shouldn't be able to repeat.
• Mitigate, don't "solve" — Prompt Injection (LLM01). There is no complete fix. Layer defenses: separate system and user context, use allow-lists for tool calls, and constrain the model with least-privilege rather than trying to block every malicious phrase.

Worked example: a support chatbot with a "look up customer order" tool. The dangerous combination is LLM01 + LLM08 + LLM06 — an injected instruction convinces the model to call the lookup tool for a different customer's ID and read back their address. The fix isn't a better prompt; it's enforcing that the tool only accepts the authenticated user's own ID at the application layer, so the model literally cannot query someone else's data.

Building an LLM threat model your team can act on

Map each LLM feature to the Top 10, then assign a control owner. For every model touchpoint, ask: what can it read, what can it do, and who verifies its output? Log all prompts and completions for detection, red-team with known injection payloads (many are published on GitHub), and rate-limit to blunt denial-