Shai-Hulud Outbreak Debrief: The Worm Evolves into MCP

5 days after 440+ npm packages were compromised, 5 malicious repositories remain live in the wild—and the threat is still active

While the cybersecurity community was traveling to Black Hat last week, threat actors unleashed one of the most widespread software supply chain attacks of 2026. A new evolution of the Shai-Hulud self-propagating worm compromised over 440 unique npm packages—reaching downstream projects with an estimated total of over 2 billion monthly downloads.

After monitoring the evolution of npm and Github’s response since the outbreak, these are our findings:

Active threats Aug 9 (5-days post-infection)

• 5 GitHub repositories distributing infected Claude Code/VS Code settings files are still active with the recent Shai-Hulud malware variant.
  – One of the GitHub repositories is the source code repository for a public MCP server found in a public MCP marketplace (see below in detail)
• 3,800+ public GitHub repositories containing exfiltrated credential dumps (matching the structural pattern results-<ID>.json seen in prior campaigns) remain publicly accessible and searchable, combined from all recent Shai-Hulud variants.
• Active Propagation: Compromised maintainer accounts continue to automatically spawn new infected repositories bearing the signature string “Shai-Hulud: Here We Go Again”.

Delayed response issue found

• 2 malicious npm packages  (@ornikar/intl-config and @ornikar/react-native-svg-transformer) stayed live for 3 whole days and were only removed 72 hours after initial infection in the npm registry
  

Shai-Hulud Weaponizes the MCP Registry

While earlier iterations of Shai-Hulud tampered with local AI coding client configs, this marks the first time we observed a Shai-Hulud payload being delivered directly through the official Model Context Protocol (MCP) Registry (registry.modelcontextprotocol.io).

During our continuous threat monitoring, our threat intelligence engines flagged an official MCP server entry: V.A.P.E (designed for cryptocurrency chain security).

How the MCP Attack Works

1. The PyPI package linked by the MCP server is completely clean to evade automated package scanners.
2. The linked GitHub repository (jUXTAPOSITION1/V.A.P.E) contains embedded malicious execution instructions within the local workspace settings files (.vscode/settings.json and .claude/settings.json configuration files).
3. The Infection: Opening or cloning the repository inside Claude Code or VS Code triggers the malware, harvesting developer tokens, cloud credentials, and session keys to further propagate the worm.

Shai-Hulud Lives On (In GitHub)

Beyond the V.A.P.E server, we identified 5 live GitHub repositories actively distributing this exact Claude Code malware vector:

• https://github.com/techtoboggan/claude-desktop-hardened-linux 
• https://github.com/rainb0w-clwn/node-cache-manager-fs-binary-ts 
• https://github.com/diegobbarbosa09/Automacao_swaglabs_cypress 
• https://github.com/evilgodfahim/kal 
• https://github.com/jUXTAPOSITION1/V.A.P.E (Official MCP Server)

Because these developers’ accounts remain compromised, their automated background activity could serve as the launchpad for the next wave of supply chain attacks.

Key Questions 

This raises a series of serious questions about npm’s and GitHub’s ability to automatically detect and remove infections from their services:

• If automated signature detection is active, why are exact payload matches remaining live?
  
• If they don’t—does this mean they manually remove them one by one?
  
• Can we rely on a non-security vendor (npm, GitHub) to remove our stolen credentials in time, right when the attack happens? Do they hold the same responsibility for our data that companies like Meta and Google do when removing harmful content right on the spot?

Conclusion

1. The Detection Collapse at GitHub & npm
   We can’t rely on vendors that don’t take security seriously.
   Just days before this outbreak (July 28, 2026), GitHub publicly announced publish-time malware scanning for npm. The fact that the largest malware campaign of the year launched successfully immediately afterward suggests threat actors actively tested and bypassed these new controls using dynamic obfuscation.
   
2.  git clone is the New USB Flash Drive
   Regular actions that everyone is doing on a daily basis, like cloning and opening a repository, have stopped being safe by default. Cloning a repository in 2026 is no different than connecting an unknown USB drive to your computer in the late 2000s. What seems like a harmless action is actually the driver for how the worm spreads—it directly executes code and tries to infect anything it can touch. And yes, one can argue that cloning a repository and trusting it is a user’s responsibility and can be harmful.
   
   

But not all developers are security engineers with cybersecurity expertise. Most people trust repositories by default, or even just dismiss warnings so they can work without the hassle.

Microsoft had to disable the AutoRun feature to handle the rise of USB worms being spread; now, IDE and coding agent developers need to handle settings.json execution similarly to prevent the next generation of worms from spreading.

Software must be engineered not only for ease of use, but to minimize high-consequence human error. The cybersecurity industry invests billions in automated malware detection, EDR, and built-in backups precisely because end users shouldn’t have to be human firewalls. When platforms refuse to build basic guardrails and shift security responsibility onto the user, a single “Yes, I trust the authors” prompt becomes an infostealer’s paradise. It proves we haven’t solved the underlying problem—we’ve just shifted the blame.