The attack chain is simple enough to describe in one sentence: an attacker poisoned a package, an AI coding assistant recommended it, a developer accepted, and a worm spread to 100 repositories. That is what Mandiant documented in its September 2026 AI Risk and Resilience Report, and if you are shipping code with AI assistants in your pipeline, the blast radius should make you pause before your next pip install on a recommendation you did not verify.
An AI coding assistant hijack at an unnamed SaaS provider let the Shai-Hulud worm spread across roughly 100 internal repositories, stealing secrets and proprietary source code. The report does not name the victim or say exactly when the intrusion occurred, but the mechanics are detailed enough to audit your own environment against.
What exactly happened in the Mandiant case?
According to The Hacker News coverage of the Mandiant report, the attacker hijacked an active AI coding assistant session at an unnamed software-as-a-service provider. The report does not explain how the session was hijacked, but what followed is well documented.
The attacker used the developer's active session to install an infostealer through a poisoned PyPI package. The AI assistant had recommended software that the attacker had poisoned, and the developer accepted the recommendation. That acceptance was the pivot point. The infostealer grabbed GitHub OAuth tokens, which gave the attacker the access needed to deploy the self-spreading Shai-Hulud worm across approximately 100 internal code repositories.
The worm stole repository secrets and source code for the company's products. The attacker also poisoned a package in the company's official namespace, and another employee pulled the compromised version, causing a second wave of infection. This is the part that should worry you: the initial compromise was bad, but the self-propagation through the official namespace turned a single bad suggestion into an ongoing internal supply chain problem.
The chart above shows the scale of three recent campaigns in the same family. The Mandiant case infected 100 repositories, while related Shai-Hulud and Keyv campaigns reached 444 poisoned packages and 469 scanned credential locations.
Mandiant had already documented attackers using AI in real attacks. In a March 2026 report summarized by SecurityBrief, Mandiant said attackers had moved during 2025 from using generative AI mainly to speed up their work to embedding large language models in malware and active attacks. The September report goes further, arguing that static controls are insufficient for AI environments where software agents can act quickly across multiple systems without direct human involvement at every step.
The broader research draws on observations from both Mandiant and the Google Threat Intelligence Group. The findings show a shift in how security teams must assess exposure as AI systems move beyond advisory roles to execute API calls, manage workflows, and make decisions autonomously. A compromised agent or assistant becomes a channel for code theft, remote execution, or sudden cost escalation, and traditional network and identity boundaries are becoming less distinct as AI systems gain wider access to tools and data.
How does this attack chain actually work?
The attack has four stages, and each one maps to a gap that most teams have not closed.
Stage 1: Session hijack. The attacker gains control of an active AI coding assistant session. The report does not specify how, but the vector could be a compromised developer machine, a leaked session token, or a man-in-the-middle position on an unencrypted connection. The key point is that the session had the same permissions as the developer, including the ability to install packages and interact with repositories.
Stage 2: Poisoned recommendation. The attacker plants a malicious package in a public registry like PyPI. The AI assistant, which surfaces recommendations based on available packages, suggests the poisoned package to the developer. The developer accepts, because the assistant is trusted and the package name looks plausible. This is the supply chain equivalent of prompt injection, but the payload runs on your build machine.
Stage 3: Credential theft. The poisoned package installs an infostealer that harvests GitHub OAuth tokens and other secrets from the developer's environment. These tokens survive the session and give the attacker persistent access to repositories, CI systems, and cloud resources.
Stage 4: Worm propagation. The attacker uses the stolen tokens to deploy Shai-Hulud across internal repositories. The worm copies itself into new repos, and when another developer pulls from a compromised namespace, the cycle restarts. The second infection in this case came from a poisoned package in the company's own namespace, not from an external registry.
The amplification is what makes this dangerous. A single accepted suggestion led to 100 infected repositories. The attacker did not need to compromise each repository individually. The worm did that work, and the stolen OAuth tokens gave it the access to do it silently.
Why does this matter if you ship code with AI assistants?
If your team uses AI coding assistants like GitHub Copilot, Claude Code, Cursor, or similar tools, this incident is your threat model now. The attack did not exploit a novel AI vulnerability. It used session hijacking, package poisoning, and credential theft, but the AI assistant amplified their reach and speed in a way that traditional supply chain attacks do not.
The core problem is trust. Developers trust AI assistant recommendations enough to accept them without the same scrutiny they would apply to a manual dependency addition. That trust is the attack surface. An attacker who can poison a package in a public registry and get it recommended by an AI assistant has a direct path into your build environment.
The blast radius is larger than a normal supply chain attack because the AI assistant's session permissions are the developer's permissions. If your developer can push to 100 repositories, so can the attacker who hijacks that session. If your developer's OAuth tokens can access cloud resources, so can the infostealer that grabs them.
The Shai-Hulud family has been active and expanding. In August, a Keyv-linked npm worm poisoned hundreds of packages and planted hooks for Claude Code and Visual Studio Code, as we covered in our Keyv npm worm analysis. A later analysis found a Shai-Hulud variant scanning 469 locations for credentials across developer systems, CI/CD tools, cloud configurations, and AI tool files, which we documented in our Shai-Hulud credential scanning guide. These were separate campaigns, and the available evidence does not link them to the unnamed Mandiant intrusion, but the pattern is clear: AI development environments are now a primary target. For a broader look at how AI coding agents can be turned against their operators, our earlier AI coding agent malware guide walks through the same trust problem from a different angle.
The Mandiant report also makes a broader architectural argument that operators should take seriously. Security teams need to treat AI agent sessions the way they treat privileged access: with short-lived credentials, behavioral monitoring, and fast containment. The report recommends feeding token usage telemetry, multi-application API activity, and helper logs into SIEM and EDR systems, so that automated memory snapshots and rapid containment become possible when anomalies appear. Static perimeters will not catch an agent that has legitimate credentials and is acting within its normal permission scope.
What should you do this week?
Mandiant recommends three specific controls for AI-assisted development. Start with these, then go further.
1. Check AI-recommended dependencies against cryptographic checksums and approved allowlists. Every package an AI assistant suggests should be validated before it enters your build. If the package is not on your allowlist, it does not get installed. If the checksum does not match the registry's published hash, it does not get installed. This is the single most important control because it breaks the attack chain at stage 2, before the infostealer ever runs.
2. Keep raw API keys, long-lived OAuth tokens, and other secrets out of direct reach of extensions and AI tools. Long-lived tokens are the persistent credential that let the worm spread. Replace them with short-lived, repo-scoped credentials that cannot push to 100 repositories from a single session. Mandiant specifically recommends replacing long-lived service accounts with dynamic identities tied to workloads and cryptographic controls. The goal is to reduce the risks associated with persistent credentials that can be stolen, reused, or misapplied in automated environments.
3. Route dependency traffic through controlled internal repositories. Your CI pipeline should pull from an internal mirror or proxy, not directly from PyPI or npm. The internal repository can enforce allowlists, run static analysis, and block packages that do not meet your security baseline. This gives you a choke point between the public registry and your build environment.
Beyond Mandiant's three controls, here is what the incident response looks like if you suspect a similar compromise:
- Revoke and rotate everything. Every repository, CI, cloud, and package-registry secret that sat in the same identity context as the hijacked session. Assume source from affected repos is already in the attacker's hands, because the worm had access to all of them.
- Disable auto-apply. Turn off one-click install from assistant suggestions. Require a second channel: lockfile review, an allowlisted registry, or a signed artifact before a new dependency hits CI.
- Inventory your AI tool access. Identify which assistants, IDE plugins, and tool bridges have network and repository access. Kill org-wide tokens. Issue short-lived, repo-scoped credentials that cannot push to 100 repositories from one chat.
- Log prompt and suggestion metadata into your incident response pipeline. Treat accepted suggestions that CI then built as a first-class detection category. You are looking for the chain: suggestion accepted, dependency installed, CI built it. That chain is your signal.
- Start the investigation at the chat transcript. The transcript and the identity that accepted the install are ground zero. Then walk CI, artifact stores, and every downstream system that identity could touch. Clone-and-grep on 100 repos will miss the lateral movement that matters.
On an ongoing basis, log prompt and suggestion metadata into your incident response pipeline the way you log admin command history. Hunt for an accepted suggestion that CI then built, and treat that chain as a first-class detection. Keep edge lockouts for SSH and git brute-force, and pair those with allowlisted package sources and segmented build networks so a poisoned suggestion cannot walk into production.
The trust tax on AI development tools
The Mandiant case is a proof of concept for something that was theoretical a year ago: an AI coding assistant can be turned into a propagation vector for a supply chain worm. The attacker needed a poisoned package, a recommendation the developer would accept, and a session with enough permissions to spread. Every team that has given an AI assistant write access to their repositories is running the same risk. The question is whether you have the controls in place to stop the worm before it reaches your 100th repository.
