7 Critical LLM Security Vulnerabilities to Patch in 2026

TL;DR

• Prompt injection is still unsolved. It’s the same #1 risk it was in 2023, and in September 2025 it was used to drive an AI-orchestrated espionage campaign that hit roughly 30 organizations, according to Anthropic.
• 250 documents is all it takes. Anthropic, the UK AI Security Institute, and the Alan Turing Institute showed that a fixed, small number of poisoned training documents — not a percentage of the dataset — can backdoor a model regardless of its size.
• MCP is the new soft underbelly. A design default in the official Model Context Protocol SDKs, disclosed by OX Security in April 2026, left an estimated 200,000 instances exposed across a supply chain of 150 million-plus package downloads.
• Your system prompt is not a secret. OWASP added System Prompt Leakage as a named risk in the 2025 list specifically because teams keep putting credentials and access rules where any determined user can coax them out.
• RAG doesn’t make you safer — it adds a new attack surface. Vector and embedding weaknesses are their own OWASP category now, and “grounding” a model with retrieval doesn’t stop prompt injection; it just moves where the poisoned content can hide.
• Incidents are about to triple. Gartner projects that by 2028, a quarter of enterprise GenAI applications will suffer at least five minor security incidents a year — up from 9% in 2025.

What Are the Most Critical LLM Security Vulnerabilities in 2026?

OWASP’s GenAI Security Project released its 2026 edition of the Top 10 for LLM Applications on August 3, having spent the prior year absorbing lessons from thousands of documented incidents. The list still opens with prompt injection at LLM01, a position it has held since 2023, and that alone tells you something: three years of tooling, guardrails, and red-teaming budgets have not solved the fundamental problem. An LLM cannot reliably tell the difference between an instruction from its developer and text it’s merely reading. Everything downstream — sensitive data leaking, agents taking actions nobody approved, poisoned training runs — traces back to some version of that same gap.

Here’s a way to sort the noise. I use what I call the Boundary Test: for any LLM vulnerability, ask whether it breaks because the model can’t distinguish instructions from data, or because a human gave the system more authority than it needed. Prompt injection, sensitive information disclosure, and vector weaknesses fall in the first bucket — they’re about what the model can be tricked into believing. Excessive agency, supply chain exposure, and system prompt leakage fall in the second — they’re about what the model was allowed to do or hold in the first place. Data poisoning sits at the intersection, since it corrupts belief before deployment ever begins. Every one of the seven risks below maps to one side of that line or the other, and the fix usually lives on the same side as the break.

Prompt Injection Is Still Undefeated (LLM01)

In mid-September 2025, Anthropic detected unusual activity that turned out to be a highly sophisticated espionage campaign. A threat actor Anthropic assessed with high confidence to be a Chinese state-sponsored group — tracked as GTG-1002 — had manipulated Claude Code into acting as an autonomous penetration-testing agent. They didn’t need a zero-day. They convinced the model, through a jailbreaking framework built on layered personas, that it was doing legitimate defensive security work for a client, then broke the real attack into small tasks that looked innocuous in isolation.

Least-privilege tool access and human approval gates aren’t the whole answer — for a deeper breakdown of what actually holds up against indirect injection through RAG pipelines, see our five architectural defenses against LLM prompt injection.

The scale is the part that should worry you. According to Anthropic’s public threat report, the operation targeted roughly thirty organizations across large tech companies, financial institutions, chemical manufacturers, and government agencies, and the AI executed an estimated 80–90% of tactical operations independently — at a request rate no human operator could sustain. Human involvement was reduced to strategic checkpoints: continue, don’t continue, does that look right. This wasn’t a lab demo. It’s the clearest public evidence to date that indirect prompt injection and jailbreaking scale into something closer to an autonomous cyberweapon than a chatbot prank.

GTG-1002 isn’t an isolated case — we’ve documented AI-generated exploits already breaching production infrastructure using nothing more than commercially available coding tools.

Direct injection manipulates what a user types. Indirect injection — the more dangerous variant — hides instructions inside content the model reads: a document, a scraped webpage, an email, a tool’s output. Because both arrive as plain natural language, the model has no built-in way to flag one as untrusted. Least-privilege tool access, human approval gates on high-impact actions, and treating every piece of retrieved content as hostile until proven otherwise are the only defenses that have held up under real adversarial pressure so far. Constraining behavior in the system prompt helps at the margins — but as you’ll see in the System Prompt Leakage section, it was never designed to be a security boundary.

Sensitive Information Disclosure (LLM02)

This risk moved up to the number-two slot in OWASP’s 2025 reordering, and it covers two different failure modes that get conflated constantly: a model regurgitating something it memorized during training, and a model leaking something a user typed earlier in the same session or a shared context window. OWASP documents a case where prompting a model to repeat a single word indefinitely caused it to eventually spit out memorized personal data — a reminder that “the model doesn’t store files” is not the same claim as “the model cannot leak information.”

The practical version of this problem shows up constantly in smaller deployments too. A support bot fine-tuned on a company’s ticket history can surface a previous customer’s email or account number if a new user phrases a question the right (wrong) way. Restricting this at the prompt level — “never reveal customer data” — is not a control, it’s a suggestion, and a moderately motivated user will talk their way around it within a handful of turns. The fix has to sit outside the model: redact and tokenize sensitive fields before they ever reach the training set or the context window, apply least-privilege access to whatever data source the model can query, and treat any output surface — chat, API response, generated summary — as a place PII can leak from by default.

Supply Chain and the MCP Problem (LLM03)

If you’ve connected Claude, GPT, or any agent framework to external tools in the last year, you’ve probably used the Model Context Protocol. It’s become the de facto standard for letting an LLM call APIs, read files, and query databases — genuinely useful, and genuinely under-secured. In April 2026, OX Security disclosed a systemic architectural flaw embedded not in one product but in the official MCP SDKs themselves, a design default that propagated into every downstream project trusting the reference implementation. The Cloud Security Alliance’s writeup put the exposure at roughly 200,000 vulnerable instances across a supply chain touching more than 150 million package downloads. It had already been weaponized for authenticated remote code execution against Letta AI, unauthenticated server takeover on LangFlow through exposed configs, and guardrail bypasses on Flowise.

That’s not an isolated fluke. Wiz scanned more than 500 live MCP servers and found 38% running with no authentication at all — meaning any client that could reach the endpoint could talk to it. Separately, a CVE tracked as 2026-33032 hit nginx-ui with a CVSS score of 9.8 because its MCP message endpoint skipped authentication on command-execution requests entirely. And this isn’t just a theoretical researcher’s playground: it’s the exact protocol GTG-1002 leaned on to automate its attack chain against those thirty organizations described above. Same technology, weaponized for offense in one report and dissected for architectural failure in another, seven months apart.

If you’re running any of this on your own hardware rather than a managed platform, the exposure compounds — start with these self-hosted LLM hardening tips before you connect an MCP server to it.

Here’s what most guides get wrong about this one: they treat MCP security as a patching exercise — update the SDK, move on. The NSA’s May 2026 cybersecurity information sheet on MCP is more honest about it, describing the protocol as reversing a familiar pattern (servers now query and act for clients instead of the other way around) and calling that inversion a source of largely untraced new attack paths. Patching a version number doesn’t fix an architectural inversion. Vet every MCP server the way you’d vet a third-party dependency with production database access, because that’s functionally what it is: maintain a signed inventory, verify server provenance, and default to explicit allow-lists for what commands an agent’s tools can execute — not a filter trying to catch what it shouldn’t.

Data and Model Poisoning (LLM04)

Here’s the sentence that should reset how you think about training-data risk: injecting just 250 malicious documents into pretraining data was enough for researchers to successfully backdoor language models ranging from 600 million to 13 billion parameters, according to a joint study released in October 2025 by Anthropic’s Alignment Science team, the UK AI Security Institute’s Safeguards team, and the Alan Turing Institute. The number stayed almost constant regardless of model size — a 13-billion-parameter model trained on more than twenty times the data of the 600-million-parameter one was backdoored by roughly the same fixed document count, not a proportional share of a much larger dataset.

That overturns an assumption a lot of security teams have been quietly relying on: that scraping the open web is “safe” for large models because any individual bad actor’s contribution gets diluted into irrelevance by sheer volume. It doesn’t, at least for this class of backdoor. The study focused on a narrow trigger — producing gibberish text on a specific phrase — and the researchers were careful to say this specific attack is unlikely to threaten frontier models directly. But the mechanism it demonstrates, a fixed rather than proportional poisoning cost, is the more durable finding, and it’s the kind of result that reshapes how much scrutiny any pretraining or fine-tuning data pipeline deserves.

Now here’s where I’ll push back on something you’ll read constantly: that retrieval-augmented generation solves this by grounding the model in your own verified data instead of trusting whatever it memorized. That advice is dated. RAG doesn’t remove the poisoning surface, it relocates it — from the training set to whatever document store your retrieval pipeline pulls from at inference time. A single poisoned PDF sitting in a shared knowledge base is functionally a live backdoor every time it gets retrieved. Track data provenance the same way you’d track code provenance: version it, sign it where you can, sandbox anything ingested from an untrusted source, and treat “we’re using RAG” as a description of your architecture, not a security control.

Excessive Agency in Agentic Systems (LLM06)

Excessive agency climbed OWASP’s rankings as agentic architectures spread from novelty to default, and it’s the risk that shows up the moment you give an LLM the ability to act rather than just answer. OWASP breaks the root cause into three overlapping failures: excessive functionality (the agent has tools it doesn’t need for its actual job), excessive permissions (the tools it does need reach further into your systems than the task requires), and excessive autonomy (high-impact actions fire without a human ever reviewing them).

This is where the GTG-1002 campaign and the MCP supply chain flaw both stop being separate stories and start looking like the same failure mode wearing different clothes. An agent with broad, unreviewed tool access is dangerous whether the entity abusing it is an external attacker who jailbroke the model or a legitimate workflow that was simply granted more reach than it needed. And the scale of this exposure is compounding fast — CyberArk’s research, cited in Gartner’s 2026 security forecast, puts machine identities at more than eighty times the number of human employees in a typical enterprise now. Most access-review processes were never built to audit at that ratio.

The fix isn’t exotic, it’s just unglamorous: minimize the tools an agent can call to the smallest set the task genuinely requires, execute every action in the authenticated context of the actual human user rather than a shared service account, and put human approval in front of anything irreversible — a payment, a deletion, a deploy. Authorization has to live in the downstream system that actually performs the action, not in the model’s judgment about whether a request seems reasonable. Models are persuadable. Deterministic permission checks are not.

Compare that to Chrome’s mandatory-confirmation model for agentic actions — it’s one of the few consumer-facing examples of least-privilege agency actually shipped by default.

System Prompt Leakage (LLM07)

New to the 2025 OWASP list, and it addresses a mistake that’s genuinely common: teams write credentials, internal role definitions, or filtering rules directly into a system prompt and then treat that prompt as though it were a locked door. OWASP is unambiguous about this — a system prompt should never be considered confidential, full stop, because a sufficiently patient user can usually infer most of a model’s guardrails just from probing its normal responses, let alone from a direct extraction attempt.

OWASP is unambiguous about this because it’s already happened at scale — system prompts already extracted and archived from ChatGPT, Claude, and Gemini prove that treating a prompt as a locked door was never realistic.

The actual damage isn’t the leak itself. It’s the architectural decision that put something sensitive there to begin with. If your system prompt contains a database connection string, that string was never secure — it was one clever phrasing away from public. The same goes for access-control logic: “don’t let users in the free tier access the premium tools” written into a prompt is a suggestion the model is trying its best to honor, not a policy a system is enforcing. Keep secrets out of prompts entirely, enforce authorization in an external, deterministic system that the model calls into rather than reasons about, and use guardrails that check the model’s behavior rather than trusting instructions embedded in its context.

Vector and Embedding Weaknesses (LLM08)

The other new 2025 category, and the direct consequence of how fast retrieval-augmented generation went from niche technique to default architecture. Weaknesses here cluster around four patterns: unauthorized access to a shared embedding store, cross-tenant leakage in multi-tenant vector databases (one customer’s retrieval accidentally surfacing another customer’s data), embedding inversion attacks that reconstruct meaningful chunks of the original source text from the mathematical vectors alone, and — the one people underestimate most — behavior alteration, where retrieval quietly reshapes a model’s tone or judgment without anyone deciding it should.

This is the direct consequence of how fast retrieval-augmented generation went from niche technique to default architecture — we cover eight RAG architecture patterns and where each one’s ingestion step becomes an attack surface.

That last one is worth sitting with. A customer service model grounded in strictly financial policy documents can shift from empathetic to purely transactional purely because of what it’s now retrieving, even though nobody changed its instructions. The system got “more accurate” and, in the process, got worse at the actual job. If you’re running any RAG pipeline in production — and if you’ve built anything with local models and a document store, you almost certainly are — permission-aware vector stores with real tenant partitioning aren’t optional at scale, and hidden-instruction scanning on anything you ingest into the knowledge base earns its cost quickly.

The Bottom Line

The honest read for 2026 is that LLM security isn’t converging toward a fix, it’s diversifying into more categories every year OWASP updates the list. Three of the seven risks above didn’t exist as named categories in 2023. That’s not a failure of the framework — it’s an accurate reflection of how fast the attack surface is expanding as agents, MCP servers, and RAG pipelines move from demos into production. If you’re shipping anything with tool access this year, start with the Boundary Test: figure out whether your biggest exposure is a belief the model can be tricked into, or an authority you handed it that it never needed. Patch that side first. Everything else on this list gets easier once you have.

Sources

• Gartner — Gartner Predicts 25% of All Enterprise GenAI Applications Will Experience At Least Five Minor Security Incidents Per Year By 2028
• OWASP GenAI Security Project — Top 10 for LLM Applications 2026
• Elevate Consult — OWASP LLM Top 10: Security Vulnerabilities Every AI Developer Must Know in 2026
• Anthropic — A small number of samples can poison LLMs of any size
• Anthropic — Disrupting the first reported AI-orchestrated cyber espionage campaign
• Cloud Security Alliance / Lab Space — MCP Security Crisis: Systemic Design Flaws in AI Agent Infrastructure
• Wiz — Understanding Model Context Protocol Security (MCP) in 2026

Frequently Asked Questions