OWASP's LLM Top 10 for 2026 is the first one backed by incident data. Three entries moved because of it

OWASP has published the 2026 edition of the GenAI/LLM Top 10. We read the full publication — all 122 pages, including the methodology — and the most useful thing in it is not the list itself.

It is that this is the first edition where the ranking was checked against evidence.

The methodology matters more than the ranking

Previous editions were consensus documents: practitioners agreed on what mattered, and that agreement became the order. Useful, but circular — the list reflected what the field believed, and the field's beliefs were partly shaped by the list.

The 2026 edition weighs two sources. Three-quarters of the weight is the community vote. One quarter is the incident record. OWASP is explicit about why that balance was chosen: a quarter is "enough to move an entry a tier when the gap between belief and evidence runs wide. It is not enough to let imperfect data rewrite the list on its own."

That single design decision is what makes this edition worth re-reading if you already know the 2025 one. The places where the two sources disagree are, almost by definition, the places where your programme's priorities are inherited from consensus rather than from what actually happens.

The list

	2026	Movement
LLM01	Prompt Injection	held 1st
LLM02	Sensitive Information Disclosure	held 2nd
LLM03	Excessive Agency	climbed to 3rd
LLM04	Supply Chain	—
LLM05	Data and Model Poisoning	—
LLM06	Unbounded Consumption	up four places
LLM07	Misinformation	—
LLM08	Hidden Context Exposure	renamed and re-scoped from System Prompt Leakage
LLM09	Vector and Embedding Weaknesses	—
LLM10	Improper Output Handling	fell 5th → 10th

Several entries also absorbed newer risks rather than becoming new categories — OWASP notes that "standing up thin new categories would have splintered the list for no gain." Prompt Injection now covers cross-modal attacks, where instructions are hidden inside an image or an audio track. Supply Chain now covers a promoted model artefact not being what it claims to be. Data and Model Poisoning absorbs fine-tuning subversion. Improper Output Handling now spans the insecure code that assistants generate at scale.

The four things worth acting on

1. Work out which list you are actually on

This is the first decision, and most teams get it wrong by assuming it is one or the other.

OWASP draws the boundary sharply: this list owns the risk when the model is a component inside your application. The moment 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.

Their own guidance is to pair them: "Read an entry here for the model-as-component failure. When your model starts acting on its own, pair it with the Agentic list, because neither one covers that ground alone."

In practice most organisations are running both shapes simultaneously and treating them as one problem. A retrieval-augmented chat assistant is model-as-component. A workflow that reads a ticket and updates a record is an actor. Same platform, same vendor, different failure modes, different controls.

What to do: inventory your LLM deployments and tag each one component or actor. It takes an afternoon and it tells you which list governs which system. Anything you cannot classify is almost certainly an actor that nobody has thought of that way.

2. Assume your hidden context is public

System Prompt Leakage has been renamed and widened to Hidden Context Exposure, and the re-scoping is the point. It now covers the system prompt, developer instructions, retrieved policy text from RAG stores, and — importantly — the schemas of the tools your application exposes to the model.

OWASP's guidance is unusually direct: practitioners "should design under the assumption that hidden context is discoverable and that any contents of the context should not be considered a secret."

That is a design instruction, not a warning. It means hidden context must not contain credentials, connection strings or tokens, and must not be the thing that enforces authorization, privilege separation or content policy. Their severity scale runs from informational — no secrets, no reliance on confidentiality — up to critical, where disclosure chains into remote code execution.

What to do this week: open your system prompt and read it as an attacker would. Ask what an adversary gains from having it. If the answer includes a credential, a connection string, an internal rule that gates a decision, or a tool schema that reveals what the model can reach, you have work — and it is cheap work, done now, expensive later.

3. Cap agency before you expand it

Excessive Agency climbing to third is described by OWASP as "the most consequential move on the list," and it moved because the vote and the incident record agree — which is rare and worth weighting accordingly.

The definition is broader than most teams assume. It is the vulnerability that "enables damaging actions to be performed in response to unexpected, ambiguous or manipulated outputs from an LLM, regardless of what is causing the LLM to malfunction." Prompt injection is only one trigger. Hallucination from a badly-engineered but entirely benign prompt is another. So is a compromised tool earlier in the chain.

That last clause is what makes it a design problem rather than a defensive one. You cannot fix excessive agency by getting better at detecting attacks, because the malfunction does not have to be an attack.

What to do: for every tool your model can call, ask what the worst legitimate-looking invocation does. If the answer is irreversible — a payment, a deletion, an access grant, an outbound message — put a human in front of it. Not a confirmation dialogue nobody reads: a step where a person has the information needed to say no.

4. Slow down on Misinformation

This is the entry OWASP explicitly asks readers to sit with, and the reason is the most interesting finding in the document.

Practitioners voted Misinformation near the bottom. The incident record placed it near the top — "the widest gap in the direction that actually hurts, where the vote sits low and the evidence sits high." OWASP seated it in the middle as a compromise and then flagged the disagreement rather than hiding it.

The mechanism they give: "When a model's fluent, confident output drives a decision or a tool call, a wrong answer turns into a wrong action, and the record says that failure lands more often than the vote assumes."

If your organisation has an LLM in a decision path — triage, classification, summarisation feeding a human judgement, retrieval answering a policy question — this is the entry your programme is most likely underweighting, because everyone's programme is.

What to do: identify where model output reaches a consequential decision without a competent human between. That is your exposure. The fix is rarely technical; it is usually a process that stopped requiring a person once the output started looking good enough.

One note on Prompt Injection

It held first place, but the reasoning is worth understanding because it is counterintuitive.

OWASP observes that prompt injection produces relatively few clean entries in the public incident record — and reads that as a defence effect rather than a low-risk signal: "Teams fight injection hard, so fewer clean exploits reach a public database, and the public count understates the risk that mature teams already spend real money holding off."

The surface "still sits everywhere a model reads untrusted input, which is to say everywhere." Since you cannot close it, their instruction is to build for the day it is used against you.

This is a good example of why the 25% weighting was the right call rather than 50%. A naive reading of incident data would have demoted the risk that mature teams spend the most money containing.

Where to start

If you are running LLM features in production and want a defensible order:

1. Classify each deployment as component or actor. Anything you cannot classify is an actor.
2. Audit hidden context on the assumption it is public. Cheapest item on this list.
3. Put a human in front of every irreversible tool call.
4. Find where fluent output drives a decision with nobody competent in the loop.

None of that requires a new platform or a research programme. It requires knowing which of your systems is which, which is the thing most organisations have never actually written down.

And if your models have started calling tools and carrying memory between sessions, this list stops being sufficient on its own — that is the boundary OWASP drew, and it is worth respecting rather than assuming one document covers both.