In September 2026, security researchers reported an attack that started inside a live AI coding assistant session at a software company. The assistant recommended a package. A developer installed it. A hidden infostealer inside that package took their GitHub OAuth tokens, and the Shai-Hulud worm used those tokens to copy itself across roughly 100 internal repositories while walking off with source code and repository secrets.
How the attack unfolded
The attacker first took control of an active coding assistant session. Through that session, the assistant recommended what looked like a normal outside package. The developer installed it from PyPI. The infostealer collected source code, repository secrets, and high-privilege GitHub OAuth tokens. With those tokens, the attacker released Shai-Hulud, which self-replicated into about 100 internal repositories. A poisoned package then appeared inside the company’s own internal namespace, and a second employee pulled it and got infected too.
Three ways attackers get into the assistant
The AI Risk and Resilience Report 2026, covered by iTWire and SecurityBrief Asia, documents the three routes researchers found that all end with the attacker controlling what your assistant suggests.
- Prompt injection. A group called TeamPCP planted instructions where an assistant would read them and execute them as if you had typed them. They also targeted the LLM-based security scanners meant to catch such attempts. Those scanners then approved the same malicious code.
- Tampered startup hooks. Attackers modified the command-line hooks an assistant runs on startup. Opening the project ran their code. No suggestion needed to be accepted.
- Weaponized agent skills. In February, attackers shipped OpenClaw agent skills with backdoors, droppers, and infostealers inside. Most developers install a skill the same way they install a browser extension: without reading it.

The worm keeps growing
A newer variant of Shai-Hulud now searches 469 locations for credentials, up from 189. The added targets include CI systems, cloud configuration files, and the settings files that AI development tools write to disk. Those files get created by an installer and then forgotten. Teams keep finding access keys sitting in them in plain text.
The same report also documents a failure with no attacker involved. An autonomous agent hit a corrupted value and fell into a reasoning loop. In one hour it fired more than 15,000 API calls, ran up around $50,000 in cloud bills, and locked a database hard enough to interrupt the business.
What to do now
- Treat any package your assistant recommends like a pull request from a stranger. Review it before it gets installed.
- Scan every dependency that lands in your lockfile in CI. Verify hashes against the registry rather than trusting the package name.
- Get long-lived tokens off developer laptops. Short-lived credentials and OIDC-based publishing limit what a stealer can take.
- Grep your AI tool config directories for secrets. If Shai-Hulud checks 469 locations, start with the same list.
- Review agent skills, extensions, and MCP servers with the same scrutiny you give a dependency. They run with your permissions.
Most teams scan their lockfiles and pull requests. Almost nobody scans the tool that decided what went into the lockfile. That gap is what this attack used.
