The evolution of Shai-Hulud-style worms

The software supply chain landscape changed forever in early-to-mid 2026. What began as a series of isolated credential-theft incidents quickly mutated into a highly coordinated, multi-registry, self-propagating worm campaign.

By abusing trusted relationships, hijacking CI workflows, poisoning build caches, and even embedding execution scripts inside compiled native binaries, the threat actors behind this campaign (tracked as TeamPCP) bypassed traditional static scanner defences.

As of the time of writing, this is a somewhat complete, chronological teardown of the three distinct waves of this campaign: Shai-Hulud, Hades, and Miasma.

Shai-Hulud, Mini Shai-Hulud and similar worms

The Shai-Hulud worm lineage first surfaced in late 2025 as a direct credential stealer targeting the npm ecosystem. However, on May 11th, 2026, a highly automated, modernised variant called Mini Shai-Hulud struck with vastly expanded scope. While it heavily impacted npm, compromising more than 170 packages across the TanStack, Mistral AI, UiPath, and OpenSearch ecosystems, the worm simultaneously breached the broader software supply chain, orchestrating coordinated attacks against PyPI, RubyGems, Docker Hub, and even malicious extensions within VS Code.

Unlike the earliest waves of Shai-Hulud that relied specifically on stolen static developer credentials, Mini Shai-Hulud (believed to have been created by a different group to TeamPCP), gained entry to these diverse environments via entirely new approaches, like pull request workflow misconfigurations in GitHub Actions (as seen in the TanStack compromise).

The basic workflow looked like this. An attacker submitted a pull request from a fork. This triggers a workflow that grants write access to the base repository's cache. The attacker proceeds to poison the cache with malicious payloads. Hours later, a legitimate maintainer merges a commit, triggering the standard release workflow. And this all concludes with the release run pulling the poisoned cache and executing the malicious payload invisibly.

Rather than exposing static tokens, the worm scraped live tokens directly from the GitHub Actions runner’s active memory (the Runner.Worker process via /proc/<pid>/mem). Depending on the target ecosystem, it then exchanged these temporary workflow credentials for registry-specific publish tokens, using OIDC token exchange endpoints for npm and PyPI, or harvesting raw API keys for RubyGems and container registries like Docker Hub.

This allowed the published packages, container images, and extensions to carry valid SLSA Build track provenance signatures. To defenders, the updates appeared completely legitimate and officially attested across all affected registries. It’s the equivalent of deepfakes for the software supply chain.

Perhaps the most malicious aspect of this multi-registry wave was its defence mechanism. Once inside a developer's local machine or build server (whether pulled via a Python pip install, a Ruby gem, an npm package, or a VS Code extension) the payload established a background daemon named gh-token-monitor. This daemon monitored whether its stolen tokens had been rotated or revoked, acting as a dead man’s switch. If a defender revoked the token, the daemon immediately triggered a local script that executed rm -rf ~/ and rm -rf ~/Documents, wiping the victim's entire home directory to eliminate forensic traces and punish the developer.

Miasma

Discovered on June 4th, 2026, Miasma represents the third evolution of the Shai-Hulud family of worm attacks, compromising hundreds of npm components (including packages within the @redhat-cloud-services and @asyncapi namespaces).

In this workflow, a simple npm install forces a node-gyp rebuild which executes a binding.gyp command that drops the Miasma payload. Again, the tactics and techniques of this Shai-Hulud worm have changed multiple times so far this year. Most security scanners and manual reviewers focus closely on scripts blocks in package.json (watching for preinstall or postinstall triggers).

Miasma bypassed this completely by abusing binding.gyp. The binding.gyp, for context, is a legitimate config file used to compile native C++ Node.js add-ons. When a package containing this file is installed, the npm client automatically spawns node-gyp rebuild. The attackers embedded direct command execution wrappers inside the binding.gyp target configs. The system executes the malicious payload during compilation, completely avoiding the need for suspicious package.json lifecycle scripts.

Miasma focused heavily on capturing cloud identities instead of static keys, implementing collectors specifically designed to steal active GCP and Azure SSO credentials. Furthermore, if the infected CI container had access to the host's Docker socket (/var/run/docker.sock), the malware would’ve performed a Docker escape. It identifies and terminates security monitoring containers (such as Step Security’s harden-runner), creating a privileged Alpine container to write passwordless sudo access to the host's /etc/sudoers.d, and altered local DNS resolution to block telemetry reporting domains.

Hades

Discovered on June 8th, 2026, straight after the Miasma variant, the campaign expanded to the Python ecosystem, targeting critical academic genomics and phenotype analysis packages on PyPI (ensmallen, embiggen, pyphetools).

In this attack, a simple Python Import loads a .so extension which executes embedded javascript. The embedded javascript code executes a final Bun payload which exfiltrates to a GitHub endpoint.

In a major evasion upgrade, the attackers did not modify any Python source files. Instead, they embedded the malicious JavaScript loader inside the compiled Rust/C++ binary extension (.abi3.so).

When a researcher imports the package via Python (import ensmallen), it triggers dlopen() on the trojanised .so file. The shared object discreetly initialises and runs an embedded JavaScript engine to execute the payload. This makes the new attack completely invisible to code-reviewers looking at Python source files.

The payload's primary file, _index.js, contains a massive block of comment text representing a fake LLM jailbreak prompt. The decoy simulated classified briefings, asking for technical steps on weaponising biological agents and designing nuclear devices. This was a deliberate attempt to pollute static analysers and AI-assisted tooling, causing them to choke, flag false positives on safety boundaries, or even worse, misclassify the file as a prompt-injection experiment rather than a credential-stealing worm.

Instead of a standard server, the Hades variant registered dozens of GitHub repositories using the compromise-controlled user account felixEvora. The repositories used underworld-themed naming conventions (like lethean-tartarus-61322 and abyssal-acheron-97481) and were described as Hades – The End for the Damned. The exfiltrated data was stored in an encrypted envelope format, signed with GPG keys.

Shai-Hulud-style worms will continue to change shape

The open-sourcing or leaking of a complex piece of malware like the Shai-Hulud worm typically triggers a significant shift in the threat landscape. When a sophisticated framework (originally tightly controlled by an advanced group like TeamPCP) becomes publicly accessible, it lowers the barrier to entry for a much wider, more disorganised pool of actors. Independent operators, smaller cybercriminal syndicates, and even security researchers looking to understand its mechanics can dissect the original codebase. This democratisation of advanced tech means that features previously requiring high-level engineering, such as automated supply-chain propagation or complex credential harvesting, become plug-and-play modules for anyone with basic development skills.

Without a centralised command structure like TeamPCP directing its deployment, the evolution of Shai-Hulud has naturally fragmented into highly specialised or experimental variants (such as IronWorm). Newer threat actors are combining Shai-Hulud’s core self-propagating mechanisms with different payloads or evasion techniques tailored to their specific objectives. For instance, some variants strip away the heavier components to create lightweight stealth tools, while others swap out the exfiltration methods to target different developer ecosystems beyond npm or GitHub, such as PyPI and Cargo. This fragmentation complicates defense strategies, as defenders can no longer rely on a single set of behavioural signatures or specific infrastructure indicators associated with the original group.

Furthermore, this post-TeamPCP era accelerated the timeline of dual-use engineering, where threat actors repurpose and optimise techniques from Shai-Hulud in unexpected ways (as seen in the Suno breach). Independent devs often modify the codebase to patch flaws left by the original authors (such as fixing loud fallback routines or refining how the worm handles OIDC token exchanges). Because these new variants are built and deployed by completely unrelated clusters of users, the attribution of attacks becomes incredibly muddy. The signature architecture of Shai-Hulud is no longer a reliable indicator of who is attacking, but rather a reflection of a shared, open-source repository of commodity supply-chain threats. This is glaringly the case with alleged supply chain competitions organised by BreachForums.

Quick recap of what you’ve read

If the evolution of Shai-Hulud proves anything, it's that attackers are exceptionally creative and relying purely on reactive remediation is a losing strategy. When malware can pass SLSA attestations, bypass package.json inspection via native builds, and hide inside compiled binaries, you simply cannot predict every vector. It only takes one compromised token to trigger a massive downstream disaster. While rapid incident response remains essential, putting heavy effort into proactive preventions, such as universal package cooldown policies and strict pipeline boundaries is the only way to neutralise these threats before they execute. Stopping the attack at the gate will always be easier than cleaning up the damage after a worm gets through.

Join our upcoming webinar

If you found this breakdown useful and want to keep up with the evolving threat landscape of malicious dependencies and open-source malware, join our upcoming webinar: Inside the Open Source Malware Attack Landscape. Cloudsmith will be sitting down with Jenn Gile (Co-Founder of OpenSourceMalware) to discuss real-world attack vectors and how to protect your software pipelines.

[Register for the webinar →]