An Attacker Hijacked an AI Coding Assistant and Spread a Worm Across 100 Repositories
Mandiant says a threat actor poisoned an AI tool's recommendations at a software-as-a-service provider, then used the resulting access to push Shai-Hulud through about 100 internal code repositories.
Key points
- Mandiant reports an attacker hijacked an active AI coding-assistant session at an unnamed software-as-a-service provider.
- Before the worm spread, the assistant recommended software the attacker had already poisoned, and the recommendation was accepted.
- The worm, named Shai-Hulud, reached about 100 internal code repositories and stole secrets and source code.
How did the hackers get in?
The attacker hijacked a live session of an AI coding assistant, a tool developers use to suggest and auto-complete code, at an unnamed software-as-a-service provider, according to Mandiant. Before any worm moved, the assistant recommended software the attacker had poisoned. The recommendation was accepted. That acceptance gave the attacker the foothold to introduce Shai-Hulud.
What is Shai-Hulud?
Shai-Hulud is a worm: self-replicating malicious code that spreads without further attacker interaction once it's inside a network. It reached about 100 internal repositories, the version-controlled storage systems where developers keep their source code, and stole both repository secrets, think API keys and credentials, and the underlying source code itself. The poisoned-recommendation step is worth noting here because it shows the attacker understood the AI assistant's workflow well enough to exploit it before the worm ever ran.
Our 7 September story on ScreenConnect hijacking documented a similar pattern: trusted tooling turned into a delivery mechanism, spreading laterally before defenders noticed.
Should customers be worried?
Yes, potentially. Stolen repository secrets can include credentials that touch customer infrastructure, not just internal systems. If any of those secrets authenticated connections to downstream environments, the blast radius extends beyond the provider. Customers should ask their provider directly which secrets were stored in the affected repositories and whether any of those credentials have been rotated.
A senior OpenAI official was already warning of persistent AI-powered attacks as of 26 August. This incident shows that warning wasn't abstract: the attack surface isn't just AI generating threats, it's AI being subverted as an insertion point.
| Incident detail | What Mandiant reported |
|---|---|
| Initial vector | Hijacked AI coding-assistant session |
| Pre-spread action | Poisoned software recommendation accepted |
| Worm name | Shai-Hulud |
| Repositories reached | About 100 |
| Data stolen | Repository secrets and source code |
What should development teams do now?
The specific mechanics of how the session was hijacked aren't detailed in Mandiant's current reporting, so single-source attribution and a full kill chain should be treated with medium confidence until more technical indicators emerge. What is clear enough to act on: AI coding assistants that can write to repositories need the same access controls and audit logging applied to any privileged developer account. Session tokens for these tools should be short-lived. Recommendations that install or fetch external software deserve a human review step before acceptance, regardless of which tool made them.
The harder problem is cultural. Developers trust AI assistants precisely because they're fast. That trust is the vulnerability.
