Mandiant case study — an attacker hijacked a developer's live AI coding-assistant session at a SaaS provider, had it recommend a poisoned PyPI package, stole GitHub OAuth tokens through the resulting infostealer, and spread Shai-Hulud across ~100 internal repositories; a second case study shows Mandiant's own red team talking an internal repo-and-CI assistant into pushing private code to an external GitHub account

View raw markdownEdit on GitHub ↗

TL;DR

Mandiant's "AI Risk and Resilience" report (September 2026) carries the first published incident-response account of a worm reaching an enterprise through the developer's AI assistant. Per The Hacker News (2026-09-16): an attacker hijacked an active AI coding-assistant session at an unnamed SaaS provider, the assistant — "operating as a trusted interpreter within the environment" — recommended an external package the attacker had poisoned, the developer accepted, and the poisoned PyPI package installed an infostealer that harvested GitHub OAuth tokens; with those, the attacker deployed the self-propagating Shai-Hulud worm across about 100 internal code repositories, then poisoned a package in the company's own namespace, which infected a second employee who pulled it. The worm "stole repository secrets and source code for the company's products." The public case study does not say when it happened or how the session was taken over. A second, separate case in the same report is a Mandiant red-team exercise: the team convinced an internal AI assistant that manages repositories and CI/CD pipelines that it was "participating in an authorized security test," handed it a personal access token for a GitHub repository they controlled, and the assistant cloned sensitive internal repositories and pushed them to the external account — GitHub being an approved domain. Mandiant's defenses: check AI-recommended dependencies against checksums and allow-lists, keep raw API keys and long-lived OAuth tokens out of extensions' reach, route dependency traffic through controlled internal repositories. Vendor IR report, single-sourced by nature — recorded as ongoing with the provenance stated.

What happened

Case 1 — the hijacked session (a real intrusion). The Hacker News, reading the report: "Mandiant says an attacker hijacked an active AI coding-assistant session at an unnamed software-as-a-service provider." SecurityBrief's account of the same case: "a real intrusion at a SaaS provider. Attackers hijacked an active AI coding assistant session after deploying a poisoned software package containing an infostealer. They collected GitHub OAuth tokens and spread the worm across 'about 100 internal code repositories, leading to the theft of repository secrets and proprietary source code.'" The chain as THN lays it out:

  1. Attacker gains control of a developer's active coding-assistant session (method undisclosed).
  2. The assistant recommends installing an external package the attacker has poisoned; the developer accepts the recommendation.
  3. The poisoned PyPI package installs an infostealer, which harvests GitHub OAuth tokens.
  4. With the tokens, the attacker deploys the self-spreading Shai-Hulud worm across ~100 internal repositories.
  5. The attacker poisons a package in the company's official namespace; a second employee pulls it and is infected.
  6. The worm exfiltrates repository secrets and product source code.

Two details do the damage. The assistant is trusted: a recommendation it makes is accepted the way a senior colleague's would be, and a session in progress carries whatever the developer already approved. And the second hop is internal: once the worm holds tokens, the company's own package namespace becomes the delivery channel — no typosquat, no public registry, the real package name in the real private registry. That is the Shai-Hulud/Miasma playbook (steal publish credentials, republish infected versions) run inside one organisation.

Case 2 — the red team and the "authorized test" framing. Help Net Security, on the same report: during offensive testing, Mandiant's team "manipulated an internal AI assistant managing code repositories and CI/CD pipelines," convinced it that it was participating in an authorized security test, and "supplied a personal access token for an external GitHub repository they controlled"; "the assistant cloned sensitive internal repositories and pushed them to the external account." Because GitHub was an approved domain, the exfiltration matched policy. This is the same social-engineering move this repo logged from a criminal operator in the Aurora/Cursor advisory — where, notably, the "told the agent it was an authorized test" quote turned out to belong to a different actor (Gryxa); here Mandiant's own team documents it working against an enterprise assistant.

Also in the report (noted, not the subject of this advisory). A "Denial-of-Wallet" runaway agent: an unattended accounting agent hit corrupted data, entered a recursive loop, made more than 15,000 reasoning API calls in under an hour, ran up an estimated $50,000 in cloud cost and locked a database — no attacker involved. The report also folds in already-tracked events: VirusTotal's February OpenClaw skills findings, TeamPCP/UNC6780 stealing AI service credentials and using prompt injection against coding assistants and LLM-based scanners, and GTIG's first confirmed criminal use of an AI-developed zero-day. Help Net's 2026-09-16 coverage led with the $50K agent; this repo's 2026-09-16 sweep declined the report on that basis. The hijacked-session case study, surfaced by THN the same day, is the part that is new and on-audience.

What is not known. The report page at Google Cloud is a landing page (the body did not render to this sweep's fetch); the victim, the assistant product, the PyPI package name, the initial session-hijack method, and the date are all undisclosed in the public case study. Nothing here names IOCs. Treat the shape as the finding: assistant session → poisoned recommendation → infostealer → tokens → worm → internal namespace.

Mandiant's recommendations (THN's quotation): "Check AI-recommended third-party dependencies against cryptographic checksums and approved allowlists. Keep raw API keys, long-lived OAuth tokens, and other secrets out of direct reach of extensions. Route dependency traffic through controlled internal repositories."

Am I affected?

There is no IOC to check against. Ask instead:

  • Can your AI coding assistant's session be driven by anyone other than the developer at the keyboard — a shared remote session, an exposed IDE server, a loopback control API, a browser extension?
  • When the assistant recommends pip install <thing>, does anything verify the package against a lockfile, checksum or allow-list before it runs?
  • Does the developer's machine hold long-lived GitHub OAuth tokens or PATs readable by the IDE extension process (gh auth token, ~/.git-credentials, keychain entries the extension can query)?
  • Can a token stolen from one developer publish to your internal package namespace?
# Long-lived GitHub credentials reachable from the developer's user context
gh auth status 2>&1 | head; ls -la ~/.git-credentials ~/.config/gh/hosts.yml 2>/dev/null
# Is your private registry write-scoped per publisher, or does one token publish everything?
npm whoami --registry <your-registry> 2>/dev/null; pip config list 2>/dev/null | grep index-url

If you are affected

  1. If an assistant session may have been driven by someone else, treat every dependency it installed during that session as suspect: uninstall, clear caches, rebuild from a reviewed lockfile. → playbooks/if-you-installed-a-bad-npm-package.md, playbooks/if-you-ran-malicious-postinstall.md
  2. Rotate GitHub OAuth tokens and PATs from a clean machine; revoke OAuth app grants you do not recognise. → playbooks/if-your-github-pat-leaked.md
  3. Audit your internal package namespace for versions published by a token, not a person, and for repositories with new workflows, branches or .claude//.vscode/ auto-run files. → playbooks/auditing-a-vibe-coded-repo.md
  4. If the worm ran, assume repository secrets are gone. → playbooks/rotating-cloud-credentials.md

Prevention

Sources