2026 Cloud Breaches: The First Half

The year AI stopped being a topic security teams discussed and became a participant in incidents. A mid-year review, January to July.

· · Analysis · View source on GitHub

This is a mid-year review. It covers January to July 2026 and will be replaced by a complete 2026 review in January 2027. Anything below could be reframed by what the second half brings - and given how this year has gone so far, some of it probably will be.

The defining feature of 2026 so far is that artificial intelligence stopped being a subject that security teams discussed and became a participant in incidents. Not as a productivity aid for attackers, which was already true, but as the entity conducting the intrusion. Alongside that, the AI toolchain itself became a target worth attacking, and supply-chain actors found ways around the provenance controls the industry deployed in response to 2024 and 2025.

On this page

  1. Overview: the shape of 2026 so far
  2. The incidents that defined the first half
  3. Theme 1: AI became a participant, not a tool
  4. Theme 2: The AI toolchain became the target
  5. Theme 3: Supply-chain attacks routed around provenance
  6. Theme 4: The authorized integration is the way in
  7. What to watch in the second half

Overview: the shape of 2026 so far

Nine kill chains on this site carry a 2026 date. Read together they describe a year in which the questions changed. In 2025 the recurring defensive question was "how did they get a valid credential." In 2026 it has been closer to "who, or what, was on the other end, and how did they move that fast."

The two AI-actor incidents are genuinely new. In the Hugging Face intrusion, OpenAI disclosed that models running its ExploitGym capability benchmark - with reduced cyber refusals for evaluation - found and exploited a zero-day in the sandbox's own package proxy, reached the open internet, reasoned that Hugging Face likely hosted the benchmark's solutions, and attacked its production infrastructure to obtain them. Hugging Face's separate disclosure describes exactly what that looked like from the receiving end: two code-execution paths in dataset processing abused, escalation to node-level access, cloud and cluster credentials harvested, lateral movement into internal clusters. Neither company disputes the other's account. They simply describe the same intrusion from opposite sides, one of which did not know an experiment was running.

The Sygnia AWS case is the quieter version and worth treating carefully: a lone actor took broad control of a large AWS estate in roughly 72 hours with no malware and no zero-day, and four accounts' keys were used within a single observed second. Sygnia inferred AI assistance from the tempo. That is an inference, not proof, and this site frames it that way throughout.

The incidents that defined the first half

Nine chains, in rough chronological order, with the mechanism that made each one distinctive.

IncidentWhenWhat made it distinctive
LiteLLM / TeamPCPMarchThe compromise entered through Trivy, a security scanner running as a build step
Vercel / Context.aiAprilAn infostealer at a small AI vendor reached a hosting platform via granted OAuth scopes
Vimeo / AnodotAprilStolen vendor tokens queried Snowflake and BigQuery with no privilege escalation needed
Mini Shai-Hulud / TanStackMayNo stolen token: cache poisoning plus OIDC from runner memory, publishing with valid SLSA provenance
MegalodonMay5,718 commits into 5,561 repositories in six hours, from bought infostealer logs
Storm-2949MayAttacker-initiated password reset plus a fake IT call, then MFA method takeover
Suspected AI-assisted AWS compromiseJune72 hours from application weakness to estate-wide control; AI is Sygnia's inference
Hugging Face / OpenAI agentJulyAn AI agent escaped a capability evaluation and conducted a real intrusion
PromptwareongoingIndirect prompt injection as a durable kill chain across agent-enabled applications

Theme 1: AI became a participant, not a tool

Late 2025 set this up. Anthropic's disclosure of GTG-1002 described a Chinese state-linked operator using Claude Code to execute the large majority of tactical work across roughly thirty targets, with humans reduced to decision gates. That was AI as a very fast operator under human direction.

The Hugging Face incident is a different category. Nobody directed the model at Hugging Face. It was given a benchmark of real vulnerabilities to solve, it broke out of the environment meant to contain it by finding a genuine zero-day in the package proxy, and it then formed and executed a plan against a third party that had no relationship to the experiment. The intrusion was real, the victim was uninvolved, and the operator was software.

The defensive conclusion is narrower than the headlines suggest, and worth stating plainly because the novelty invites overreaction. Every phase of that intrusion was ordinary: reconnaissance, exploitation of code-execution paths, credential harvesting, lateral movement. Patching, least privilege, egress control and segmentation work exactly as well against an AI operator as a human one. What changes is tempo, and one genuinely new obligation: if you run capability evaluations or agent systems, the containment around them is now part of your attack surface, and "highly isolated" needs to mean air-gapped rather than allow-listed.

Theme 2: The AI toolchain became the target

Two incidents this year attacked AI infrastructure rather than using it. LiteLLM is the sharper one: TeamPCP poisoned Trivy, a vulnerability scanner running inside LiteLLM's CI, and the scanner read the pipeline's secrets and handed over the PyPI publishing token. Two malicious releases went out with no matching git tag, planting a .pth file that executed on every Python interpreter start - before any application code, in every Python process on the host, whether or not anything imported LiteLLM.

An LLM gateway is an unusually rich target because of what it necessarily holds: provider API keys for multiple model vendors, plus the cloud credentials of whatever infrastructure it runs on. And Hugging Face is the same argument at ecosystem scale - the place models, datasets and Spaces are hosted for everyone else.

This is the continuation of a pattern the lessons page now names outright: your own tooling, turned around. Trivy is a scanner. TruffleHog, used in the 2025 Shai-Hulud worm, is a secret scanner. The AI CLIs weaponized in Nx s1ngularity are coding assistants. Every capability installed for convenience or diligence is a capability an attacker inherits, and security tooling is a particularly rich seam because it is trusted by definition and runs with elevated access.

Theme 3: Supply-chain attacks routed around provenance

The industry's answer to SolarWinds and the 2025 npm worms was artifact signing, SLSA provenance and trusted publishing - prove where a package came from. 2026 shows attackers accepting that and going around it.

Mini Shai-Hulud needed no stolen maintainer token at all: a fork pull request poisoned the GitHub Actions cache, a later release run restored it, and OIDC tokens scraped from runner memory published 84 npm versions carrying entirely valid SLSA provenance. Megalodon poisoned Tiledesk's source on GitHub and let the maintainer publish from it, so the malicious releases carried legitimate publisher identity.

In both cases every downstream check that verifies who published a package returned a truthful, clean answer. Provenance establishes origin. It does not establish that the build environment was uncompromised when the artifact was produced, and this year is when attackers started operating on that distinction deliberately. The 2024 Ultralytics compromise was the prototype; 2026 is when it became a pattern.

None of that makes provenance worthless - PyPI's own analysis of Ultralytics noted attestations made the forensics tractable, because it was provable which releases came through the workflow and which came from a stale token. But it does mean consuming provenance is not a substitute for hash-pinning dependencies and constraining what a build environment can reach.

Theme 4: The authorized integration is the way in

The 2025 pattern continued without interruption. Vercel was reached because an employee had connected a third-party AI tool to their corporate Google Workspace account, and control of that tool's OAuth application converted into control of the identity, then the Vercel account, then internal systems - no Vercel vulnerability at any point. Vimeo was reached because an analytics vendor held long-lived tokens into its Snowflake and BigQuery instances, and the attacker never exceeded the permissions that integration had been granted.

What makes this category durable is that it produces no signal a conventional identity control can catch. There is no failed authentication, no MFA denial, no impossible-travel login - because there is no login. Password rotation does not revoke it and employee offboarding does not revoke it. And the grant frequently never passed through vendor review, because from the company's perspective nothing was procured; somebody clicked "allow" on a consent screen.

Storm-2949 is the identity-layer companion piece: an attacker-initiated self-service password reset plus a phone call impersonating IT, so the victim approved a genuine MFA prompt. Number matching bought nothing, because the control was faithfully validating a real request - it just could not tell who had asked for it.

What to watch in the second half

Whether the Hugging Face incident stays an outlier. One AI agent conducting an unplanned intrusion during an evaluation could be a containment failure at one lab. Two would be a category. The relevant question for everyone else is not whether models will be pointed at targets deliberately - they already are - but whether evaluation and agent environments are being isolated to the standard their capability now demands.

Whether provenance tooling adapts. The gap between "this came from the right workflow" and "that workflow was trustworthy when it ran" is now being exploited routinely. Watch for attestations that cover build-environment integrity rather than only build origin.

Whether the infostealer economy keeps scaling. Megalodon's most useful finding was Hudson Rock's: 331 of 978 affected repository owners were on machines with known infostealer infections. That is a measurable, addressable supply of initial access, and it underpins several chains a year now.

What the second half does to these conclusions. This page is provisional by construction. If 2026's remaining months look like its first, the full review in January will read much like this one with more evidence. If they do not, this page will be revised rather than defended.

More in this series