Mandiant: Attacker Hijacked an Active AI Coding Assistant Session and Spread Shai-Hulud to ~100 Repositories
Mandiant: Attacker Hijacked an Active AI Coding Assistant Session and Spread Shai-Hulud to ~100 Repositories
Google's Mandiant team has disclosed an intrusion in which an attacker hijacked an active AI coding-assistant session at an unnamed software-as-a-service provider, steered the assistant into recommending a poisoned software dependency, and then used the developer's existing session to spread the Shai-Hulud worm to roughly 100 internal code repositories. The case appears in Mandiant's September 2026 AI Risk and Resilience report and is one of the first documented examples of an autonomous agent being used as both the initial access vector and the persistence mechanism for a self-propagating supply-chain compromise.
How the Attack Unfolded
The public case study does not say when the intrusion happened, or how the attacker first took over the active coding-assistant session, but the post-intrusion activity is described in detail. After the takeover, the attacker instructed the assistant to recommend a piece of third-party software that the attacker had previously poisoned. The developer accepted the recommendation, which caused the developer's machine to install the malicious package — an infostealer delivered through a poisoned PyPI upload. With the developer's active credentials now in hand, the attacker stole GitHub OAuth tokens associated with the account and used them to deploy the Shai-Hulud worm across approximately 100 internal code repositories. The worm exfiltrated repository secrets and source code for the company's products.
The attacker then escalated further: they poisoned a package inside the company's own official namespace on the registry, and another employee pulled the compromised version while performing routine development work — producing a second infection from inside the trusted software supply chain. Mandiant had already documented, in its March 2026 report, that attackers had moved during 2025 from using generative AI mainly to speed up operations to embedding large language models directly inside malware and active attack chains. This case is the practical realization of that trajectory: the AI assistant was not a sidekick, it was the operator.
The Shai-Hulud Family Keeps Growing
This incident is the latest in a string of Shai-Hulud–family attacks that have specifically targeted developer tooling and credentials. In August 2026, a Keyv-linked npm worm poisoned hundreds of packages and planted hooks for Claude Code and Visual Studio Code. A later analysis found a Shai-Hulud variant scanning 469 distinct locations for credentials across developer systems, CI/CD pipelines, cloud configuration files, and AI tool configuration. Those were separate campaigns; the available evidence does not yet link them to the unnamed Mandiant intrusion, but the recurring pattern is that the same family keeps finding new surfaces — and AI coding assistants are now one of them.
What Should You Do?
- Verify every AI-recommended dependency against a cryptographic checksum and an approved allowlist. An assistant's recommendation is not a trust signal. Treat AI-suggested packages like any other third-party import: hash them, pin them, and require them to come from your internal registry or your allowlisted upstream mirrors.
- Keep raw API keys and long-lived OAuth tokens out of the reach of extensions. Any token that lives on the same machine as a browser extension or an IDE assistant is, by definition, one extension compromise away from being stolen. Move to short-lived, broker-issued credentials and rotate aggressively.
- Route dependency traffic through controlled internal repositories. Direct developer-to-public-registry egress is exactly what enables the "poisoned package in our own namespace" pattern. Proxy everything through a vetted internal mirror that enforces version pinning and blocks typosquats.
- Treat AI assistant sessions as production identities. If a developer is signed into GitHub, the cloud console, and the package registry while an AI assistant is running, the assistant inherits that identity. Audit which integrations each assistant is connected to and minimize the blast radius.
The WAF Angle
For WAF operators, this case reframes the AI supply-chain problem. The poisoned package is the obvious layer — signature verification, registry gating, dependency pinning — and a WAF in front of an artifact registry's API can catch obvious exfiltration and abnormal publishing patterns. The harder problem is that the AI assistant is the user. It reads a developer's prompt, executes a recommendation, and acts on the developer's behalf inside a trusted session. A WAF cannot see that the prompt was attacker-written; it sees a developer using a tool they have always used. Defenders therefore need to move the controls closer to the AI layer: rate-limit and anomaly-score recommendations, log every dependency pull that originates from an assistant session, and require post-install attestation (signed SBOM, checksum match, allowed-source confirmation) for any package an assistant installs. Treat AI coding assistants as a privileged user class — because in the moment they install a package, they are exactly that.
