Software supply chain malware used to look for two things: source code and build secrets. The latest variant of the self-replicating npm worm known as Shai-Hulud looks for 469 different things, and the list now includes the credential stores of AI coding agents. That shift, not the worm’s latest package count, is the story: attackers have stopped treating AI tooling as a novelty and started treating it as infrastructure worth raiding.
What changed
Security researchers at GitGuardian tracked a new wave of the worm, dubbed Mini Shai-Hulud, after it compromised the popular npm package keyv@6.0.0 on August 4, 2026. The infection spread downstream into more than 800 dependent packages, including @cacheable/memory, cacheable-request, and flat-cache, before the last malicious package was published less than a day later. Companies whose environments pulled in the tainted dependencies included OneReach, Ornikar, Qlik, and Picsart.
The technical delivery mechanism is not new: a preinstall script fetches a runtime and loads an obfuscated JavaScript payload that then scans the host for anything resembling a secret. What has changed sharply is the scope of that scan. GitGuardian’s analysis found the worm now checks 290 credential locations on Linux hosts, up from 89 in the previous version; 129 on macOS, up from 88; and 50 on Windows, up from 12.
Media Partner
The AI tooling angle
The newly added locations are not random. They include configuration and credential paths for AI coding assistants such as Cursor, OpenAI Codex, and Gemini, alongside CI/CD platforms including ArgoCD, Jenkins, and CircleCI, and cryptocurrency wallet software such as Foundry, Brownie, and Electrum. The worm also pulls command-and-control addresses from the Ethereum blockchain, a technique that makes takedown harder because there is no single domain or IP to block.
“Don’t let attackers know where to find your secrets better than you do,” said Gaetan Ferry, a security researcher at GitGuardian who authored the firm’s analysis of the campaign. The line reads like a slogan, but it names the actual defensive gap: most organizations have a weaker inventory of where their AI agents and CI tools store credentials than the malware now scanning for them does.
This is not the first time an npm worm has gone after cloud and developer credentials at scale. CyberTech reported in July on a North Korean crew linked to a string of npm package hijacks, and an AI-directed backdoor surfaced in fake npm packages earlier this year. What distinguishes the Shai-Hulud lineage is persistence and scale: it has now gone through multiple generations since first appearing in the ecosystem, each one widening its target list rather than changing its delivery method.
How we got here
The Shai-Hulud lineage did not start this large. Palo Alto Networks’ Unit 42 first documented the worm in September 2025, when it identified a self-replicating campaign that had already backdoored hundreds of npm packages, including the widely used @ctrl/tinycolor library. Researchers there assessed with moderate confidence that an LLM had generated the malicious bash script, based on the comments and emojis left inside it. That original version harvested .npmrc files, GitHub personal access tokens, and cloud API keys for AWS, GCP, and Azure, then published the stolen secrets to public GitHub repositories created under the victim’s own account.
A second wave, Shai-Hulud 2.0, followed in November 2025 and escalated sharply: over 25,000 malicious repositories tied to roughly 350 compromised accounts, according to Unit 42’s updated analysis. That version moved its payload from a post-install to a pre-install script, guaranteeing execution on build servers before static scanners could inspect the code, and added a destructive fallback: if credential theft failed, the malware tried to overwrite and delete every writable file in the current user’s home directory. Ten months and two major revisions later, Mini Shai-Hulud is the same lineage with a far longer shopping list.
What it means for the security leader
The open source software supply chain has been a known weak point for years. What is new is that AI coding tools have quietly become part of that supply chain’s attack surface without most security teams updating their credential inventories to match. An engineer’s Cursor or Codex configuration can hold API keys with broad scope, and a compromised CI runner can hold cloud deployment credentials with even broader reach. A worm that treats those locations as first-class targets is a signal that attackers have already mapped this terrain more thoroughly than most defenders have.
Vetting a package before it enters a build pipeline no longer covers the real exposure. Security leaders need a current inventory of every place a credential could live in a developer’s environment, including AI agent configs and local wallet files that were never part of a traditional secrets-management program, and they need automated revocation paths for when a dependency is later found malicious. GitGuardian’s own guidance, drawn directly from the incident, is to treat credential-location mapping as an ongoing exercise, not a one-time audit, because the malware’s target list keeps growing faster than most inventories do.
What to do now
Audit npm dependency trees for the affected packages, rotate any credentials that were reachable from a build host during the exposure window, and extend secret-scanning coverage to AI agent configuration directories and local CI runner caches, not just source repositories. Treat any organization-issued AI coding tool credential as equivalent in sensitivity to a cloud access key, because attackers already do.
The blockchain-based command-and-control channel is also worth flagging to detection engineering teams specifically. A campaign that can rotate its infrastructure through Ethereum transactions rather than registered domains will not show up on a traditional domain blocklist, so egress monitoring and behavioral detection on build infrastructure matter more here than they would against a conventional malware family with a fixed set of command servers to block.
Source: GitGuardian
