Why Shai-Hulud matters
Shai-Hulud is not just another malicious package campaign. It is a self-propagating software supply-chain worm that abuses the trust relationships behind modern software development: npm maintainers, GitHub workflows, CI/CD runners, package registries, cloud credentials, publishing tokens, and developer machines. Its significance comes from the fact that it does not merely steal secrets from one compromised environment. When it finds the right credentials, it can use them to publish poisoned versions of legitimate packages, turning trusted maintainers into unwilling distribution channels.
The first major Shai-Hulud wave appeared in September 2025, when malicious versions of popular npm packages were published with install-time scripts that harvested credentials and pushed stolen data into public GitHub repositories. GitHub later described Shai-Hulud as a self-replicating worm that infiltrated npm through compromised maintainer accounts, while security researchers treated it as one of the most serious JavaScript supply-chain incidents in recent memory.
The real target was the software factory
The most important thing to understand about Shai-Hulud is that its primary target was not a finished application. It targeted the software factory itself. Developer laptops, CI runners, GitHub Actions workflows, npm publishing identities, and cloud-connected build environments often hold exactly the credentials attackers want: npm tokens, GitHub personal access tokens, cloud API keys, SSH keys, repository secrets, deployment credentials, and internal source-code access.
That is why Shai-Hulud was so dangerous. A normal malware infection might compromise one host. A software supply-chain worm can compromise the systems that produce software for thousands or millions of downstream users. Once a legitimate maintainer account or publishing workflow is hijacked, malicious releases can appear authentic because they come from real packages, real maintainers, and real automation.
How the original Shai-Hulud attack worked
The original campaign relied on malicious npm package versions that executed during installation. Once installed, the payload searched the local environment for secrets and developer credentials. It looked for GitHub tokens, npm tokens, cloud credentials, and other sensitive material that could be used for further access. If it found GitHub credentials, it could create public repositories under the victim’s account and upload stolen data. If it found npm publishing credentials, it could modify and republish packages controlled by that victim.
This behavior made Shai-Hulud worm-like. It did not depend only on a central command-and-control server or manual operator decisions. Its propagation logic was built into the malware. A single infected maintainer with broad package access could become a bridge into dozens or hundreds of additional packages. CISA’s alert on the September 2025 campaign warned organizations to review dependency lockfiles, cached packages, GitHub settings, credentials, and cloud access because the incident affected both direct and transitive dependencies.
Shai-Hulud 2.0: a more mature cloud-native worm
In November 2025, researchers documented a second major wave known as Shai-Hulud 2.0. This version was more mature, more automated, and more cloud-native. Datadog reported that Shai-Hulud 2.0 backdoored 796 unique npm packages, representing more than 20 million weekly downloads in total. Its main payload functioned as a credential stealer that exfiltrated secrets through public GitHub repositories.
Microsoft’s analysis of Shai-Hulud 2.0 described a campaign that used malicious preinstall scripts, located or installed the Bun JavaScript runtime, and then executed payloads through Bun. That detail matters because many security tools were still focused primarily on Node.js execution patterns. By shifting execution paths, the malware increased the chance that it would run unnoticed inside developer and CI environments.
Shai-Hulud 2.0 also attempted to install GitHub self-hosted runners on compromised machines. That was a major escalation. A GitHub runner can provide a familiar and trusted execution channel inside an organization’s development workflow. Instead of relying only on suspicious external infrastructure, the malware abused the same automation systems that engineering teams already depend on.
GitHub as an exfiltration layer
One of Shai-Hulud’s most distinctive tactics was its use of GitHub as an exfiltration mechanism. Rather than simply sending stolen data to a suspicious external server, the malware created repositories under victim-controlled GitHub accounts and used them to store stolen secrets. This made the activity harder to spot because GitHub traffic is normal in developer environments.
That design choice was clever and dangerous. Many organizations allow developer machines and CI systems to communicate freely with GitHub. Blocking GitHub entirely is rarely practical. The better defensive question is behavioral: should a package installation script be creating repositories, uploading files, calling GitHub APIs, or touching cloud credential files at all? In most environments, the answer should be no.
Mini Shai-Hulud and the abuse of trusted publishing
In May 2026, a newer campaign called Mini Shai-Hulud showed that the threat had evolved beyond classic npm token theft. The Hacker News reported that Mini Shai-Hulud compromised TanStack, Mistral AI, Guardrails AI, UiPath, OpenSearch, and other packages. The campaign abused GitHub Actions workflows and OpenID Connect publishing flows, allowing attackers to publish malicious package versions that appeared to come from legitimate automation.
This is one of the most important lessons from Mini Shai-Hulud. Provenance can prove that a package came from a workflow, but it does not automatically prove that the workflow was safe. If the workflow can be triggered from the wrong branch, influenced by a poisoned cache, abused through broad OIDC trust, or executed with attacker-controlled inputs, then the resulting package can still be malicious while looking formally legitimate.
In other words, trusted publishing is useful, but it is not a complete defense. It must be tightly scoped to specific repositories, protected branches, workflow files, jobs, and release events. Broad trust is still trust, and Shai-Hulud shows how quickly broad trust can become broad compromise.
The May 2026 resurgence
The campaign continued to evolve in May 2026. BleepingComputer reported a new Shai-Hulud wave involving more than 600 malicious npm packages, much of it connected to the @antv ecosystem. SecurityWeek reported that a fresh Mini Shai-Hulud attack hit more than 320 npm packages, along with GitHub Actions and a VS Code extension.
The Register reported that 314 npm packages were infected after another account compromise, including popular JavaScript packages such as size-sensor, echarts-for-react, timeago.js, and @antv packages. The same reporting described credential harvesting across GitHub, npm, AWS, Azure, Google Cloud, Docker, Stripe, and other developer tooling.
This resurgence shows that Shai-Hulud should not be viewed as a single historical incident. It is better understood as a reusable attack pattern. Once source code, tactics, or working payloads circulate, copycat and derivative campaigns can continue even if the original operators disappear.
From package malware to ecosystem malware
The phrase “npm malware” is technically accurate, but too narrow. Shai-Hulud is ecosystem malware. It attacks the connective tissue between package registries, source-code hosting, CI/CD workflows, developer identity, cloud infrastructure, and AI-assisted coding environments.
That makes its blast radius difficult to measure. A malicious dependency may never reach production, but the build machine that installed it may still leak secrets. A poisoned package version may be removed quickly, but stolen tokens may remain useful until rotated. A GitHub repository created by the malware may be deleted, but any secrets it exposed should be treated as compromised. A developer may think the issue is resolved after removing the infected package, while the attacker may already have access to cloud resources or publishing rights.
This is why response must focus on credentials, not just packages. Removing a malicious dependency is necessary, but it is not enough. The real question is what the infected environment could access while the payload was running.
The destructive turn
Later Shai-Hulud variants added destructive behavior. Datadog reported that Shai-Hulud 2.0 could attempt to delete the user’s home directory if it could not successfully replicate or exfiltrate data. That kind of fallback behavior changes the incident-response model because defenders must contain the host carefully before triggering actions that may activate destructive logic.
This does not mean organizations should delay containment. It means they should sequence containment intelligently. Isolate affected machines, stop suspicious processes, preserve evidence where necessary, identify the exact payload behavior, and then rotate or revoke exposed credentials in a controlled way.
Why AI developer tools are now part of supply-chain security
Recent Shai-Hulud reporting also points toward AI-assisted development tools as a new attack surface. The Register reported that recent activity involved attempts to influence local project settings for tools such as Claude Code and Codex. SecurityWeek also reported that the fresh campaign touched GitHub Actions and a VS Code extension.
This is a major warning. AI coding agents and IDE extensions often run with broad local context. They can read repositories, execute tools, edit files, inspect project configuration, and interact with developer environments. If malware can alter their configuration or influence their execution context, it can potentially turn a productivity tool into another execution path.
The larger implication is clear: software supply-chain security now has to include AI-agent configuration, IDE extensions, local automation files, project-level settings, and developer-tool permissions. The developer workstation has become a production-adjacent asset.
Attribution and intent
Attribution remains complicated, but several public reports connect Mini Shai-Hulud activity to the TeamPCP threat group. The Hacker News described the Mini Shai-Hulud campaign as a TeamPCP operation, and SecurityWeek reported that TeamPCP released Shai-Hulud source code before newer clone activity appeared.
The motivation appears broader than ordinary credential theft. Shai-Hulud is built to harvest high-value developer secrets, persist in build infrastructure, publish malicious packages, and spread through trusted identities. That makes it useful for espionage, extortion, source-code theft, downstream compromise, and long-term software supply-chain access.
What organizations should do
The first priority is exposure discovery. Organizations should search dependency lockfiles, internal package mirrors, build caches, artifact repositories, and CI logs for known malicious package versions. They should review both direct and transitive dependencies because Shai-Hulud spreads through trusted packages that may sit several layers deep in a dependency tree.
The second priority is credential containment. Every environment that installed a malicious package version should be treated as potentially compromised. That includes developer laptops, CI runners, ephemeral build containers, package-publishing workflows, and cloud-connected automation. GitHub tokens, npm tokens, cloud keys, SSH keys, registry credentials, deployment secrets, and CI secrets should be reviewed and rotated based on exposure.
The third priority is publishing hardening. GitHub’s response plan for a more secure npm supply chain emphasized moving away from legacy classic npm tokens, reducing reliance on long-lived credentials, expanding trusted publishing, strengthening MFA, and improving package-publishing controls. Those are not cosmetic changes. Shai-Hulud proved that long-lived credentials with broad publishing rights are one of the most dangerous assets in modern software delivery.
The fourth priority is CI/CD trust scoping. Trusted publishing should be limited to specific protected branches, workflow files, release jobs, and tightly controlled repository events. Workflows that can request publishing tokens should not run from untrusted pull requests, mutable caches, broad repository events, or attacker-controlled build contexts. Provenance should be treated as evidence, not as a guarantee of safety.
The deeper lesson
Shai-Hulud is a warning about automation without containment. Modern software delivery depends on automated installs, automated tests, automated builds, automated dependency updates, automated publishing, and automated deployments. Shai-Hulud succeeded because many of those automated systems had inherited too much trust.
The durable defense is not just better detection signatures. Signatures help, but Shai-Hulud’s strength is that it abuses legitimate systems for malicious purposes. The real answer is to reduce what any single token, machine, workflow, dependency, or package-install script can do. Build environments should have minimal secrets. Package install scripts should be restricted in CI. Egress should be monitored. Publishing identity should be short-lived and context-bound. Developer machines should be treated as part of the security perimeter, not as informal endpoints outside it.
Conclusion
Shai-Hulud marks a turning point in software supply-chain malware. It steals secrets, publishes poisoned packages, abuses GitHub and npm workflows, reaches into cloud environments, persists through CI/CD infrastructure, and now appears to be adapting toward AI-assisted developer tooling. Its evolution from the September 2025 npm worm to Shai-Hulud 2.0 and Mini Shai-Hulud shows a clear trajectory: faster propagation, broader ecosystem reach, deeper abuse of legitimate identity systems, and more aggressive payload behavior.
The right takeaway is not that npm is uniquely unsafe. The larger point is that every software ecosystem built around maintainers, package registries, CI workflows, cloud credentials, and developer automation faces the same structural risk. Shai-Hulud exposed that risk with unusual clarity. Organizations that learn from it will stop treating the software supply chain as a background dependency-management problem and start treating it as a live attack surface.
Previous post