Published on gastropod.io on 09-17-2026

A Hijacked AI Coding Assistant Session Installed a Poisoned PyPI Package and Spread Shai-Hulud to About 100 Repositories

Tags: vulnerability-intelligence, software-supply-chain-security, pypi, python, ai-coding-assistants, shai-hulud, credential-theft, ci-cd-security

Mandiant published its AI Risk and Resilience Report 2026 on September 16. The first case study describes an intrusion at an unnamed SaaS provider where an attacker took control of an active AI coding assistant session on a developer's workstation. The assistant recommended an external package that the attacker had poisoned. The developer accepted the recommendation.

From there the attacker used the developer's session to install an infostealer from a poisoned PyPI package, collect the developer's GitHub OAuth tokens, and deploy the self-propagating Shai-Hulud worm across approximately 100 internal code repositories. The worm stole repository secrets and exfiltrated source code for the company's products. The attacker then poisoned a package in the company's own official namespace. A second employee pulled that version, which started a second infection. According to The Hacker News, The public write-up gives no date for the intrusion and does not yet say how the attacker took over the session.

Most Shai-Hulud incidents this year started with a compromised maintainer account or a stolen publishing token. ChainDrop, which I have already covered here: https://gastropod.io/news/the-keyv-worm-published-releases-that-had-no-commit-behind-them, began when the attacker took over the keyv maintainer's GitHub account. In this case the first malicious install came from a suggestion inside a tool the developer already used every day. The only check in that step was whether the developer agreed with the suggestion. AI agents acting on attacker-supplied content is a pattern I have also covered with FakeGit: https://gastropod.io/news/fakegit-7-600-repos-14-million-downloads-and-an-ai-agent-reading-the-attacker-s-readme.

The second infection came through the company's internal namespace. Engineers install packages from their own organization as first-party code, so a poisoned internal version gets less review than an unfamiliar public package. Mandiant does not say how the attacker published to that namespace. The attacker held GitHub OAuth tokens and write access to about 100 repositories at that point, which is enough access to modify code that feeds an internal release.

The payload targets the same thing every Shai-Hulud variant targets: credentials. GitGuardian found that a variant from early August checks 469 credential locations across developer environments, CI/CD tooling, cloud configuration, and AI tool configuration, up from 189 in earlier versions. Any secret an AI assistant session can read, the worm can read.

Mandiant recommends three controls for AI-assisted development:

Validate every AI-recommended third-party dependency against cryptographic checksums and an approved allowlist, using IDE and CLI verification hooks.
Keep raw API keys, long-lived OAuth tokens, and other secrets out of reach of assistant extensions.
Restrict workstation network egress so all dependency traffic goes through internal repositories.

After an incident like this one, the response team has to produce a list of every machine that installed the poisoned PyPI package and the poisoned internal version, and every service built with either. That list exists only if a system recorded each install at the time it happened.

An artifact repo can help here. Developer workstations and CI runners point pip, npm, and the other package managers at one repo address, and firewall/proxy rules block direct access to the public registries, so every install is forced to go through one intake point, including installs an AI assistant starts. Gastropod is this type of artifact repo and resolves each artifact to a PURL and a sha256 digest, verifies it against the authoritative source for its ecosystem, and applies block rules at intake. Once a package name or version is flagged, it fails to install on every workstation and runner at once. The per-pull audit log records who pulled each artifact, from which IP, and when, so the list of machines that installed the poisoned version comes from a query of the log. The blast-radius graph shows which internal services depend on the poisoned internal package. For the internal namespace, the publisher role in Gastropod's access controls limits which accounts can push to a hosted repository, and scoped API tokens replace broad credentials for publishing. Endpoint and identity controls cover that part.

The product page shows the audit log and blast-radius views on a real malicious npm package. To see the same records for your own PyPI and npm traffic, you can point a client at Gastropod from app.gastropod.io/start.

Sources: