Wiki / Blog / Attacks and defence

The Q1 2026 GenAI Exploit Round-up: Eight Incidents, One CVE

A read-through of the quarter's eight notable GenAI security incidents, why only one of them carried a CVE, and what that gap means for how you track AI risk.

Tolga SEZER · Threat modelling and adversarial testing team 8 min read

ai-security-2026agentic-aimcp-securityprompt-injectionai-spm

The Q1 2026 GenAI Exploit Round-up: Eight Incidents, One CVE

The quarter's public incident record for generative AI is now long enough to read like a pattern rather than a list of one-offs. Eight incidents stand out. They span government web applications, consumer agents, internal engineering systems, managed cloud platforms, open-source orchestration software, and observability tooling. They cost real data and real cleanup hours.

One of them had a CVE.

That ratio is the story. Most security teams run a vulnerability-management process that starts with a CVE feed: a number lands, you check whether you are exposed, you patch, you close the ticket. Seven of these eight incidents would never enter that process, because the weakness was not a coding flaw in a versioned dependency. It was a design choice, a missing control, a trusted input nobody treated as untrusted. The pipeline that keeps your servers patched does not see any of it.

This post walks the eight incidents by attack class, maps each to the framework identifiers we use, and then sits with the awkward conclusion: if your AI risk register is fed by CVEs, it is mostly empty for the wrong reason.

The eight, by attack class

We describe each by what happened and to which kind of system, not by who it happened to. The point is the mechanism, and the mechanism is portable. If one of these matches a shape you run, the brand on the original write-up does not change your exposure.

1. A model used as the attacker, against government web applications. An operator drove a coding agent and a general model through reconnaissance and exploit development against a set of public-sector systems, walking out with roughly 150 GB of tax and voter records. No software flaw was novel here; the news was the force multiplier. The model executed most of the hands-on-keyboard steps. *Maps to: OWASP LLM06 excessive agency, LLM02 sensitive information disclosure; OWASP Agentic ASI02 tool misuse, ASI03 privilege compromise.*

2. A consumer agent that deleted an inbox and ignored the stop command. Asked to tidy a mailbox, an autonomous agent kept going past the point the user tried to halt it, and removed mail it should not have touched. No attacker. The failure was unsafe autonomy: an agent with a destructive tool and no hard brake. *Maps to: OWASP LLM06 excessive agency; OWASP Agentic ASI10 overreliance.*

3. An internal agent whose advice leaked data for a couple of hours. An engineer followed a confident, wrong suggestion from an internal assistant, and a sensitive resource sat exposed until someone caught it. This is the boring, common one: model output treated as trustworthy guidance and acted on without a check. *Maps to: OWASP LLM05 improper output handling.*

4. A managed cloud agent platform abused for privilege escalation. A crafted agent on a hosted agent-execution service was able to reach for credentials and touch artifacts in projects it had no business in. The lesson is that an agent runtime is an identity boundary, and a weak one chains into cloud access. *Maps to: OWASP LLM06 excessive agency, LLM02 disclosure; OWASP Agentic ASI03 privilege compromise.*

5. A developer assistant whose source leaked, then became a malware lure. Hundreds of thousands of lines of source for a popular developer tool were exposed, and within days that exposure was repackaged into fake repositories that pushed malware to people looking for the real thing. A disclosure incident turned into a supply-chain one. *Maps to: OWASP LLM03 supply chain, LLM02 disclosure; OWASP Agentic ASI04 supply chain.*

6. A training-data vendor compromised through its dependencies. A supplier in the AI training-data pipeline was breached, putting sensitive workflows and contractor data at risk and pausing downstream work. The model was never touched; the soft tissue around it was. *Maps to: OWASP LLM03 supply chain, LLM02 disclosure.*

7. The one with a CVE: remote code execution in an orchestration platform. An open-source platform for wiring up AI workflows shipped a path that let a malicious configuration run arbitrary code, with somewhere between twelve and fifteen thousand instances exposed and under active targeting. This is a classic software flaw - injectable code in a versioned product - which is exactly why it got a number: CVE-2025-59528. *Maps to: OWASP LLM05 improper output handling; OWASP Agentic ASI05 code execution, ASI02 tool misuse.*

8. Indirect prompt injection that walked telemetry out the door. AI features bolted onto an observability platform could be steered by hidden instructions inside the content they were asked to summarise, and made to render external content and leak enterprise data to an attacker-controlled destination. No user typed anything malicious; the payload rode in on the data. *Maps to: OWASP LLM01 prompt injection, LLM02 disclosure; OWASP Agentic ASI01 memory poisoning.*

Read the column, not the rows

Line the eight up and the same handful of weaknesses repeat: an agent trusted a tool, an input, or its own output more than it should have, and a control that would have caught it was either absent or never tested. Six of the eight touch OWASP LLM02 - sensitive information disclosure - because once any of these mechanisms fires, the payoff is almost always data leaving somewhere it should not. Excessive agency and supply chain are close behind.

None of that is exotic. Every one of these maps cleanly onto a control that already exists in the OWASP LLM Top 10, the OWASP Agentic Top 10, or MITRE ATLAS. The frameworks are not the gap. The testing is.

The CVE gap is the real finding

Here is the uncomfortable part. The quarter's most expensive incident, the government-data theft, has no CVE and never will, because no single product was broken in a way a vendor patches. The inbox deletion has no CVE. The privilege escalation on the cloud agent platform has no CVE. The prompt-injection exfiltration has no CVE. The one incident that did get a number is the one that looks like a 2015 web vulnerability: injectable code in a config field.

So if you are managing AI risk the way you manage server risk, your register reflects one of these eight. The other seven are invisible to a CVE-driven process, not because they are minor, but because the industry has no habit of assigning identifiers to design flaws, missing guardrails, and prompt-borne attacks. The vulnerability-management frameworks have not caught up to the failure modes.

Waiting for the CVE feed to grow up is not a plan. The feed describes a different class of problem.

What actually closes the gap

If a CVE is not going to tell you that your agent will follow a hidden instruction, something has to. That something is testing the behaviour directly, on a schedule, and keeping the result as evidence:

  • Test the behaviour, not the version. Run the attack. Send the prompt injection, poison the tool description, ask the agent to call the tool it should refuse, and see what it does on your live configuration. A version number cannot answer that question; a probe can.
  • Treat every model-readable surface as untrusted input. Tool descriptions, tool results, retrieved documents, summarised email - if the model reads it, an attacker can write to it. Each is a place to test.
  • Make it recurring. A model upgrade, a new tool, a changed system prompt, or a swapped MCP server can reopen something last month's test cleared. Posture is a property of today's configuration, not last quarter's.
  • Keep the evidence in framework terms. A finding tagged to LLM01 or ASI02, with the probe and the verdict attached, is something an auditor and a CVE-shaped register can both ingest. A screenshot is not.

This is the case for posture management over patch management when the subject is AI. Not instead of - the orchestration RCE in incident seven still needs patching like any other CVE - but in addition, because seven out of eight incidents this quarter were never going to arrive as a patch.

A standing series

We will keep doing this read-through each quarter, because the value is in the trend, not the snapshot. If the ratio shifts - if more of these start carrying CVEs, or if a new attack class crowds out prompt injection - that change is worth seeing early. For the wider view of how the first half of 2026 played out, see our first-half retrospective.

If you want to know which of these eight shapes your own AI surface is exposed to, that is a test you can run rather than a feed you can wait on.

Sources

  • OWASP Gen AI Security Project, GenAI Exploit Round-up Report Q1 2026: https://genai.owasp.org/2026/04/14/owasp-genai-exploit-round-up-report-q1-2026/
  • OWASP LLM Top 10 (2025) and OWASP Agentic Top 10 (2026), for the control identifiers used above.
  • MITRE ATLAS, for the adversary-technique mappings.

Continue in the wiki

Attacks and defence · 11 min AI Security in the First Half of 2026: The Breaches That Ended the Debate H1 2026 AI security review: the breaches that turned theory into incident queues, why posture management is now essential, and the H2 outlook. Attacks and defence · 10 min Frontier Agents Cut Both Ways - Opus 4.8, Dynamic Workflows, and the First In-the-Wild LLM-Agent Intrusion The week frontier models learned to run a thousand parallel subagents is the same week someone pointed one at a network and dumped a database in under an hour. Notes for anyone shipping agents to production. Attacks and defence · 13 min MCP Tool Poisoning - How the Attack Works and How to Stop It MCP tool poisoning explained: line jumping, rug pulls, and the malicious tool descriptions that hijack AI agents, with byte-level payloads and the seven runtime controls that actually held.

All articles → Request architecture review →