Shai-Hulud Worm Spreads Through a Compromised AI Coding Assistant Session

AI coding assistants have become everyday tools: they complete code, suggest libraries, and "help" every developer with routine work. But in September 2026, Mandiant (Google Cloud's incident-response unit) published a case that shows the flip side of that convenience. An attacker gained control of an active AI coding assistant's session at one SaaS company, made it recommend poisoned software, and ultimately spread the Shai-Hulud worm across roughly 100 internal repositories. The repositories' secrets and the company's product source code were stolen.

This is not a hypothetical "evil machine" scenario but a real attack that exposes the weakest point of new development tooling: the AI assistant runs with the same privileges as the developer and trusts whatever it is fed. We break down exactly what happened, why Shai-Hulud is dangerous, and how to protect your team.

What happened: the AI assistant's poisoned recommendation

The case is described in Mandiant's September report. It concerns an unnamed software-as-a-service (SaaS) provider whose attacker intercepted control of an active AI coding assistant's session. Importantly, the public description does not reveal exactly when the incident occurred or the precise method the attacker used to seize the session — but the consequences are described in detail.

The chain looked like this. First, the assistant recommended software that the attacker had poisoned in advance, and that recommendation was accepted. In other words, the attacker didn't "break into" the repository directly — they exploited a developer's trust in AI suggestions to slip in a malicious component.

Then, already holding access to the developer's active session, the attacker installed an infostealer via a poisoned PyPI package and stole GitHub OAuth tokens. After that, they deployed the self-propagating Shai-Hulud worm across about 100 internal code repositories. The worm stole repository secrets and the company's product source code.

How the attack worked: from session to worm

The key detail Mandiant highlights: the attacker didn't stop at one victim. They also poisoned a package in the company's official namespace. When another employee downloaded the already-compromised version of that package, a second infection occurred — without any "hacking" by the attacker, just through a normal workflow.

This is a classic supply-chain attack, only with a new "carrier" — the AI assistant. Traditionally, attackers rely on a developer copying a command from a malicious site or installing a dubious package. Now it's enough for the AI assistant, which the developer is used to trusting, to recommend the needed component itself. The human in the chain stops being a checkpoint and becomes a point of automatic execution.

The attack sequence boils down to five steps:

• Session takeover — the attacker gains control of an active AI coding assistant session.
• Package poisoning — the malicious component is prepared and published in advance.
• Recommendation — the assistant suggests the poisoned software and the developer accepts it.
• Privilege expansion — an infostealer is installed via the session and GitHub OAuth tokens are stolen.
• Propagation — the Shai-Hulud worm spreads across repositories, harvesting secrets and source code.

What Shai-Hulud is and why it's dangerous

Shai-Hulud is a self-propagating worm for supply-chain attacks. According to the MITRE ATT&CK knowledge base (identifier S9008), it was first documented in September 2025. The worm spreads through code repositories, including GitHub and npm packages, and uses CI/CD pipeline dependencies to move from victim to victim.

Once inside an environment, Shai-Hulud steals credentials and access tokens from compromised repository accounts and exfiltrates them to attacker-controlled servers via encoded GitHub Actions workflows. There are also known cases where it published stolen credentials in public GitHub repositories — meaning lost access can turn into a public leak.

The worm's technical signature is well documented. MITRE ATT&CK records that Shai-Hulud creates a repository in the compromised account that stores collected system information, environment variables, and stolen secrets as a JSON dump; to find secrets it downloads and runs the TruffleHog tool; and for exfiltration it uses, among other things, the webhook.site service. It is also known that the worm masqueraded as the legitimate Bun installer and suppressed npm warnings to keep infections unnoticed. All this shows a mature tool, not a one-off prank.

The name refers to the giant sandworms from Frank Herbert's "Dune," and the analogy is apt: like the fictional monster, this malware "moves" beneath the surface of development infrastructure, devouring everything valuable in its path.

Why it matters: the AI assistant has the developer's privileges

The main lesson of the case is not a specific malware sample but an architectural problem. AI coding assistants operate with the same filesystem, network, and repository access rights as the developer who runs them. This means any vulnerability in, or compromise of, the assistant immediately gives the attacker the same capabilities as a stolen human account.

Add a second factor — blind trust in recommendations. When an assistant suggests a library, many developers accept it without extra checking: it's "convenient" and "how it's supposed to be." That is exactly the habit the attackers exploited in this case.

For Ukrainian teams this risk is especially acute. On one hand, AI tooling is rapidly entering everyday development, including small product teams without dedicated security staff. On the other, companies working in defense, fintech, or critical infrastructure are a constant target, and leaking source code or access tokens can have consequences far beyond a single repository. You can check whether your credentials have appeared in breaches via the cyberpeople.tech breach-check tool.

Wider context: Mini Shai-Hulud and attacks on AI tooling

Shai-Hulud is not the only one, nor the last, in its "family." The MITRE ATT&CK knowledge base separately documents Mini Shai-Hulud (S9043) — a derived worm that the TeamPCP group has been using against CI/CD workflows since at least 2026.

Notably, Mini Shai-Hulud became the first documented sample to use AI coding agents' configuration files as a persistence mechanism. The worm modifies .claude/settings.json (for Claude Code) and .vscode/tasks.json (for VS Code) to re-run every time a developer opens a project — even after the infected package is removed. In other words, the malicious code "hides" in the settings of tools the developer uses daily and survives dependency cleanup.

This means the threat to development AI tooling is not a one-off incident but a trend. Attackers have already adapted their methods to the new landscape: where there were once only npm packages and build scripts, there are now AI assistants and their configuration files.

Why development environments became a priority target

The attack Mandiant describes is not accidental — it points to a structural shift in attacker targets. Development environments today concentrate several of a company's most valuable assets at once: product source code, secrets and access tokens, and automated build and delivery pipelines that have broad privileges by default. If an attacker compromises CI/CD or a repository, they often get a path to production infrastructure without extra effort.

Add the speed of propagation: through the supply chain, one poisoned component can infect dozens or hundreds of projects, as happened with the repositories in the Shai-Hulud case. Unlike a classic server attack, where each system needs a separate breach, here one step "multiplies" automatically. That's why such attacks increasingly appear in reports of the most destructive incidents, and protecting development environments has stopped being a "big-corporation topic."

How to protect yourself: three controls from Mandiant and practical tips

In its report, Mandiant proposes three baseline controls for AI-assisted development, worth implementing regardless of team size:

1. Verify dependencies by checksums and allowlists. Any library recommended by an AI assistant must pass the same check as one a developer found on their own: a cryptographic checksum and presence on the allowlist. An AI recommendation is not permission — it's just a signal.
2. Keep secrets out of reach of extensions. Raw API keys, long-lived OAuth tokens, and other secrets should not sit where an AI assistant or its extensions can read them. Use secret managers and short-lived environment variables.
3. Route dependency traffic through internal repositories. An internal artifact registry lets you control where packages come from and block suspicious versions before they reach a build.

To these three points, add practical habits that close most such scenarios:

• Don't auto-run recommended code. Before accepting an assistant suggestion that installs a package or runs a script, read what it proposes.
• Separate privileges. An AI assistant should not run with full repository-owner rights; configure a separate context with minimal permissions.
• Monitor GitHub Actions workflows. Shai-Hulud exfiltrated stolen data through them, so anomalous workflow runs should trigger immediate review.
• Regularly scan secrets in repositories. Tools like TruffleHog (which, notably, Shai-Hulud itself uses to find secrets) help spot accidentally-committed tokens before an attacker does.
• Train your team. A basic understanding that an AI suggestion can be compromised is the cheapest defense. More on systematic team training in our piece "Cybersecurity: learning from scratch".

What to do if the attack already happened

If you suspect your development environment is already compromised, the first steps must be fast and aimed at limiting damage:

• Revoke tokens immediately. GitHub OAuth tokens and API keys that may have reached the attacker must be revoked first — they are what enables further access.
• Isolate affected repositories. Pause CI/CD workflows and block suspicious workflow runs until you understand the scope.
• Check dependencies. Look for recently added or changed packages, especially in your organization's official namespace, and compare them against known-good versions.
• Engage specialists. For an incident of this scale, turn to a dedicated response team (or your security vendor), as Mandiant itself advises.

The main rule in response is not to "clean" blindly but to first understand how many accounts and secrets were affected. Otherwise a worm anchored in configuration files or workflows will come back after the first "cleanup."

Conclusion

The incident Mandiant describes is not about "malicious AI" but about how a new tool in a developer's hands inherited the old supply-chain risks and added a new trust factor to them. The AI coding assistant has become yet another attack surface, and attackers have already learned to use it.

The main takeaway: trust in an AI assistant's recommendation must not replace verification. Checksums, allowlists, internal repositories, and keeping secrets away are not bureaucracy but a minimal barrier separating convenient tooling from compromised infrastructure. For Ukrainian teams increasingly using AI in development, this is a skill worth mastering before it's needed in a real incident.