In August the OWASP GenAI Security Project published the 2026 edition of its Top 10 for LLM Applications. Nothing was added and nothing was dropped. Eight of the ten entries changed rank, one was renamed, and for the first time the order was shaped by real incident data rather than by practitioner votes alone. If a finding on your desk cites "LLM03", that id now means something different from what it meant last year.
This post covers what moved and why, then walks the ten entries in their new order with two questions for each: what is it, and how do you actually test for it. Where one of RedLens's own attack methodologies maps onto an entry, we say which one. Where the platform does not cover something, we say that too, because a vendor's list of what it does not do is usually the more useful half of the page.
What changed, and what did not
The canonical text lives in the project's publication repository on GitHub, which records the 2026 release as published on August 4, 2026. The project announced it formally on September 1 alongside a donated Agent Control Standard, and said the edition passed 10,000 downloads in its first 48 hours. One practical note before anything else: as of this writing, the Top 10 landing page on genai.owasp.org still shows the 2025 entries and ids. The repository is the reference to cite, and every id you write down should carry its edition.
The methodology is the real headline. Earlier editions were ranked by practitioner consensus. For 2026 the authors compiled 7,714 publicly documented AI incidents, classified the 6,639 that had enough detail, and blended that evidence into the ranking at a weight of 25 percent, with the community vote carrying the other 75. The preface says the weighting was deliberate: one year of noisy data should not override practitioner judgment, but it was enough to move an entry by about one tier when belief and evidence sharply disagreed.
Here is what moved, old rank to new.
- Excessive Agency, sixth to third. The largest rise. Practitioners and the incident record both point at agentic deployments as where harm is now happening.
- Unbounded Consumption, tenth to sixth. Extended reasoning and agent loops made resource abuse expensive in ways a request-rate limit does not catch.
- Misinformation, ninth to seventh. Voters ranked it near the bottom; the incident record ranked it near the top. The evidence pulled it up, and the heavier vote kept it mid-list.
- Improper Output Handling, fifth to tenth. The largest fall, and not because the flaw was solved. The authors say input-boundary injections and data disclosures now dominate the incident record.
- Supply Chain, Data and Model Poisoning, and Vector and Embedding Weaknesses each slipped one place to make room.
- System Prompt Leakage became Hidden Context Exposure (eighth, from seventh) and was broadened to cover everything an application places in the context window that the user is not meant to see: retrieved policy text, tool schemas, configuration.
- Prompt Injection and Sensitive Information Disclosure held first and second.
Several entries also widened. Prompt Injection now explicitly covers instructions hidden in images and audio, poisoned long-term memory, and what the entry calls trusted-surface attacks, where text planted in a ticket or an issue is read by a developer's own agent under the developer's credentials. Supply Chain now treats model artifacts, adapters, and conversion or quantization steps as attack surface, and moves MCP servers and tool registries out to the separate OWASP Top 10 for Agentic Applications. Data and Model Poisoning absorbed fine-tuning subversion. Improper Output Handling absorbed insecure generated code. The authors merged rather than split on purpose, arguing that thin standalone categories would fragment the list.
One more thing the preface says plainly. Prompt injection ranked first in the vote and outside the top ten in the raw incident data, and the authors attribute the gap to a defense effect, not to lower risk: heavy investment in prevention keeps clean exploits out of public databases. Read the incident numbers with that in mind, and read the rest of this post the same way. A low count is not a low risk.
LLM01:2026 Prompt Injection, held at first
What it is. Any input, whether a user message, a retrieved document, a tool result, an image, an audio clip or a stored memory, that changes the model's behavior in a way the developer did not intend. The entry is blunt that no reliable prevention mechanism exists today, because the model reads instructions and data as one token stream and there is no equivalent of a parameterized query. The 2026 text adds a way to assess any injection by its delivery surface, its propagation, and its encoding.
How to test. Two suites. In the direct suite the tester plays the user and tries to override the system prompt, adopt a persona, split a payload across turns, or encode it past a filter. In the indirect suite the tester plants instructions in the content the system actually reads, then asks it to do its ordinary job. The entry's most useful sentence is about method: test with the defense specification disclosed to the testers. It cites research in which static attack success was near zero while adaptive attacks exceeded 90 percent against most of twelve recent defenses. Baseline on a public benchmark, then red-team adaptively, and record the input, the output, the channel and the reproduction rate for every finding, in the shape we described in what an AI vulnerability report should contain.
Where RedLens maps. The Master Attack Schema's Adversarial Prompt Engineering family (Instruction Override, Privilege Escalation via Roleplay, Payload Splitting) and its evasion methodologies (Semantic Obfuscation, Encoding and Character Substitution, Low-and-Slow Boundary Erosion) are the direct suite. Indirect Prompt Injection runs the attack through declared delivery channels, including retrieved context, tool results and an image channel, which is the cross-modal case the 2026 definition names. The LangChain guide walks one such test end to end, and the healthcare post shows why the indirect suite is the one most teams have never run.
LLM02:2026 Sensitive Information Disclosure, held at second
What it is. An LLM-integrated system exposing confidential, regulated or proprietary data through a channel it should not: the answer, a tool-call argument, a reasoning trace, a retrieved chunk, a log line, an embedding, or a side channel such as response length or timing. The entry names two structural causes: oversharing from the upstream sources that feed retrieval, and persistence, where data stays extractable from weights, adapters or embeddings after the source document was deleted. This is the entry where the vote and the incident record agree most.
How to test. The entry treats disclosure red-teaming as a release gate rather than an afterthought. Run extraction and divergence prompts for memorized training data. Run a two-tenant test: one shared index, and a question from tenant A that should never surface tenant B's chunk. Try to pull the system prompt and any credential that lives in it. Then test the quiet channels, which is where real incidents cluster: what your observability tool logs, whether reasoning traces reach the user, and whether a backup of your vector store is, in effect, a backup of your documents. Use synthetic data for all of it. The test should prove a leak is possible without causing one.
Where RedLens maps. Training Data Reconstruction, System Prompt Extraction and MCP Token Passthrough and Scope Escalation map here. The PHI Egress Scan is a pattern-based triage for PHI-shaped content in data flowing to an AI vendor; it is regex and keyword matching, not clinical language processing, and its findings are meant to prompt a human review rather than stand alone. Side-channel and membership-inference testing are not in the library. For the healthcare version of this question, see BAA plus visibility.
LLM03:2026 Excessive Agency, up from sixth
What it is. A system that has been given tools can take a damaging action whenever the model's output is unexpected, ambiguous or manipulated. The entry gives three root causes: excessive functionality (the agent holds tools its purpose does not need), excessive permissions (a tool's downstream identity can do more than the tool needs), and excessive autonomy (high-impact actions proceed with no independent check). Its sharpest line is that sanitization is not a root control here. The fix is limiting what the agent can do, and enforcing authorization in code rather than by asking the model.
How to test. Start with an inventory: for each agent, the task, every tool it can reach, the identity each tool runs under, and what that identity can do downstream. The least-privilege gap falls straight out of that table before you send a single prompt. Then test behavior. Deliver an instruction through one of the LLM01 channels that asks for an out-of-scope action, and watch whether the agent reaches an excess tool, under which identity, and whether a person was asked first. For chained agents, check that the user's security context survives the hop. We wrote up the method in the AI agent security testing guide, and the checklist turns it into yes-or-no questions.
Where RedLens maps. The Excessive Agency Test is a deterministic check against a declared scope: you list the task, every tool and whether it is necessary, plus an adversarial instruction, and it scores the structural least-privilege gap and a behavioral violation. The behavioral half is heuristic signature matching, not an execution trace, which is worth stating plainly. Tool Chain Hijacking, Autonomous Action Amplification, MCP Confused Deputy and Sandbox Escape via Network Misconfiguration run the live version against an agent. In production, Runtime Guard turns a confirmed finding into a runtime rule, runs in shadow mode first, fails open, and flags every hit with a trace back to the finding that justified it. It is in preview. It finds and flags; it does not enforce.
LLM04:2026 Supply Chain, down from third
What it is. Tampered training data, models, adapters, conversion pipelines or deployment platforms. The entry lists the newer cases: a pipeline that pulls a mutable "latest" tag, an unsigned artifact, a malicious LoRA adapter, a quantized model that behaves differently from its full-precision parent, a serving framework with a deserialization flaw, and a provider whose terms let it train on your data. MCP servers and tool registries are out of scope here and belong to the Agentic Top 10, which is where we put them in MCP security is broken by default.
How to test. Most of this is inventory discipline rather than adversarial testing. Pin and hash every artifact, verify signatures, and check that every dependency an AI coding assistant suggested actually exists, because an attacker can register the name it hallucinated. Then do the part signing cannot do: signing proves origin, not safety, so run a behavioral evaluation of any third-party model against your own use case, and diff the quantized build against the full-precision one on the same evaluation set. The entry points at the OWASP CycloneDX ML-BOM and AIBOM projects for extending a software bill of materials to models, adapters and datasets.
Where RedLens maps. The Vendor AI Assessment is a black-box test of a third party's model, gated behind a written attestation of authorization to test that target. The MCP posture review reads the configuration you hand over and reports what it declares, and nothing more; it does not probe a server. RedLens does not scan model artifacts for unsafe serialization, generate an AIBOM, or track licenses. Those belong with your existing supply-chain tooling.
LLM05:2026 Data and Model Poisoning, down from fourth
What it is. Corrupting the data or artifacts a system learns from or uses, so that it appears to work while carrying a hidden bias, unsafe behavior or an exploitable trigger. The entry covers pretraining, fine-tuning (including the targeted erosion of refusal behavior that standard evaluations miss), embeddings and RAG stores, reused base models, continuous learning loops, and distributed artifacts such as pickle files, chat templates, tokenizer configs and adapters that can run code when loaded. It notes that a small number of poisoned documents can implant a backdoor across model sizes.
How to test. The entry's testing guidance is unusually direct: red-team continuously with trigger-based prompts, repeat the trigger probing after every alignment cycle, and do not assume alignment removed a backdoor. Evaluate beyond the standard benchmarks, since poisoning can preserve general accuracy while hiding a targeted harm. For the retrieval path, plant a document in the corpus and measure whether it changes answers to the questions it was aimed at. Version datasets so that a finding can be traced to an ingestion and rolled back.
Where RedLens maps. Retrieval-Augmented Poisoning and MCP Memory Poisoning test the retrieval and persisted-memory paths, which is where a deployed application is exposed. RedLens does not detect poisoning in your training pipeline, probe weights for backdoor triggers, or statically analyze model artifacts. If you fine-tune, that testing has to live with the training team.
LLM06:2026 Unbounded Consumption, up from tenth
What it is. Excessive, uncontrolled inference that degrades availability, runs up cost, or lets someone clone the model. The entry reframes the old denial-of-service idea as cost asymmetry: a short, benign-looking prompt can trap an extended-thinking model in a long or non-terminating reasoning loop; one task can fan out into hundreds of tool calls; an image or a video costs far more tokens than the text that requested it. Its conclusion is that request-rate limits alone are not enough.
How to test. Measure cost per request class first, so you know what normal is. Then try the expensive shapes against a capped test key: a reasoning-loop prompt, a request that sits just under the context limit, a conversation that accumulates context, a tool that calls itself. The thing to verify is not whether the prompt is expensive but whether the cap works: does a hard spending limit per key, user and team actually halt inference, and do the agent circuit breakers for step count, recursion depth, elapsed time and per-run cost fire? Check whether your endpoint exposes logits or log-probabilities, which make model extraction faster.
Where RedLens maps. Context Overflow Injection is the one methodology that maps here, and it tests a narrower thing: flooding the context window to push the system prompt out of effective attention. RedLens does not run denial-of-wallet or reasoning-exhaustion load tests. That is a load test on your own bill, and it should be run by you, with the cap in place, before an attacker runs it for you.
LLM07:2026 Misinformation, up from ninth
What it is. Output that is incorrect, incomplete, unsupported or misleading, and credible enough to influence a person, a workflow or another agent. The entry is explicit that omissions count, and that in agentic chains a false claim about state travels: an unverified identity passed between agents, or a backup reported as complete that never ran. The reason it rose is in the methodology section above. Practitioners ranked it low; the incident record did not.
How to test. Build adversarial scenarios designed to mislead, then grade groundedness rather than fluency: does the answer cite a source, and does the source actually say that? Run omission tests, where the correct summary must carry a constraint or a contraindication and you check whether it did. For agents, test the claim-check-act pattern the entry recommends: when one agent asserts a state, does the next verify it before acting on it? And test continuously, because a model update can change the answer to a question you already closed, which is the same reason one scan is not evidence.
Where RedLens maps. Conversation Poisoning maps here, because its harm is confident output grounded in fabricated prior context. Medical Misinformation and Inaccuracy is a restricted, curated methodology for the healthcare vertical that tests whether a clinical assistant will assert false guidance as fact. General factual-accuracy evaluation of a model is not what RedLens does.
LLM08:2026 Hidden Context Exposure, renamed from System Prompt Leakage
What it is. The extraction, inference or reconstruction of the hidden instructions and operational context an application places in the model's context window: the system prompt, retrieved policy text, tool and function schemas, configuration. The entry grades severity by what the context contained, from informational when there is nothing secret in it to critical when disclosure enables code execution, broad exfiltration or privilege escalation. Its controls are the same three sentences every team should already have on a wall: assume all of it may be seen, do not rely on hidden context for control, and enforce authorization outside the model.
How to test. Direct extraction first, then paraphrase and reconstruction: ask for a summary of the rules, the output format, the list of tools. Most systems leak something. The question that matters more than whether it leaked is what was in it, so grade the finding by content. A credential or an authorization rule is critical; a tone guideline is not. Then take the second step most tests skip: check whether the exposed logic is usable. Knowing the refusal triggers lets an attacker write around them, and knowing the output schema lets them produce output that passes validation while carrying a manipulated value.
Where RedLens maps. System Prompt Extraction maps here and to LLM02, and the finding carries what the prompt contained so the severity is not a guess. RedLens does not test retrieved policy text or tool schemas for exposure as a separate exercise; those surface through the same extraction methodology when the application puts them in the prompt.
LLM09:2026 Vector and Embedding Weaknesses, down from eighth
What it is. Risks in any application where embeddings and similarity search decide what the model sees: retrieval, vector-backed agent memory, semantic caches, deduplication. The entry separates this from prompt injection by mechanism: these attacks exploit embedding geometry and search mechanics, not instruction-following. Its one-line summary is worth keeping: poisoning makes the system wrong, inversion makes it leak, jamming makes it silent, and an access-control failure makes it indiscriminate. A system with no vector retrieval has no LLM09 surface.
How to test. Tenant scoping first: with two tenants on one index, probe for the existence and topic of the other tenant's documents through result counts, similarity scores and timing, and confirm the filter is applied inside the index query rather than after it. Then plant a document whose embedding lands near a target query and check whether it is retrieved and steers the answer. Try a jamming document that pushes the right chunk out of the top results. Take a sample of stored vectors and attempt inversion. Finally, test the lifecycle: delete a source document and check whether its vector, and its backup, are still there.
Where RedLens maps. Retrieval-Augmented Poisoning, Embedding Space Probing and Training Data Reconstruction map here. RedLens does not run embedding inversion against your stored vectors or audit tenant isolation inside your index. Both are worth asking your vector database vendor to demonstrate.
LLM10:2026 Improper Output Handling, down from fifth
What it is. Weak validation, sanitization and handling of model output before it reaches a downstream component. The entry lists the sinks: a shell or an eval call, a browser rendering generated Markdown or JavaScript, a database running generated SQL, a file path, a terminal or log that honors control characters, a renderer that fetches any URL the model emits, and generated code deployed without review. It is distinct from LLM07 (is the output true) and LLM01 (is the input trusted); this entry is about where the output goes.
How to test. Enumerate the sinks, then test each with the payload class that sink fears, with the model as the untrusted source. A Markdown image whose URL carries data. A SQL fragment that is not parameterized. Shell metacharacters in a filename. ANSI control sequences in a log line. Generated code through the same static analysis and review as human code. This is classic application security, and it is the one entry on the list where your existing penetration testers already know exactly what to do once you point them at the model's output.
Where RedLens maps. Tool Chain Hijacking, Autonomous Action Amplification and MCP Confused Deputy test the path where model output becomes a tool call with no validation in between. RedLens does not test your web renderer for cross-site scripting or your database for injection through model output. That belongs with your application penetration test, and the two should cite each other.
What to do with this
Re-cite. Any report that names an OWASP LLM id without an edition is now ambiguous. LLM03 was Training Data Poisoning in 2023, Supply Chain in 2025 and Excessive Agency in 2026. Every RedLens finding prints the edition with the id for exactly this reason, and an auditor who receives your report next year will thank you for doing the same.
Re-weight your test plan toward what moved. Agency and consumption went up; output handling went down but did not go away. If your last red-team scope was written against the 2025 list, the agent inventory in LLM03 and the cost cap check in LLM06 are the two additions most likely to be missing. If your agents read anything they do not control, the indirect suite under LLM01 is still the place to start.
Draw the boundary. The 2026 list covers a model used as a component of an application. Once the model acts autonomously with tools, persistent memory and downstream effects, the authors hand the amplified risks to the OWASP Top 10 for Agentic Applications. Most teams running agents need both lists, and a finding should say which one it belongs to.
If you want to see the first entry against your own system today, the free assessment generates prompt injection and instruction override attacks for the assistant you describe, scores the responses, and hands you a report in about ten minutes with no account and no card. It covers LLM01 territory, not all ten; for the rest, the enterprise scope runs the methodologies named above, and the healthcare deployment runs them on synthetic PHI.