Over 600 software packages got poisoned in a single hour in the latest wave of the Shai-Hulud npm supply chain attack — and this time, the malware can forge the security badges developers trust to verify safe code. The npm supply chain attack represents a sharp escalation from a campaign that first emerged last September and has steadily grown more sophisticated with each new wave.
What Happened
Threat actors published more than 600 malicious packages to the Node Package Manager index as part of a new Shai-Hulud supply chain campaign. Most of the affected packages belong to the @antv ecosystem, which includes libraries for charting, graph visualization, building flowcharts, and mapping.
Security researchers identified 639 compromised package versions across 323 unique packages. Malicious publishing activity began at approximately 01:56 UTC on May 19, 2026, and ran for roughly one hour. Detection systems flagged most activity within 6 to 12 minutes of publication, with a median detection time of 6.7 minutes.
The campaign’s origin traces back to two long-dormant packages: jest-canvas-mock and size-sensor, neither of which anyone had published in over three years. Those neglected packages gave attackers their entry point. From there, the worm spread rapidly across dozens of widely used libraries.
The Packages at Risk
The scale of potential exposure is significant. Compromising a single npm maintainer account gave attackers access to one of the largest collections of dependent packages on record. An account called atool served as the primary publisher for nearly all the affected libraries, including timeago.js, a JavaScript utility with over 1.5 million weekly downloads.
Other high-download packages caught in this npm supply chain attack include jest-canvas-mock with 2.4 million weekly downloads, echarts-for-react with 890,000 weekly downloads, and size-sensor with 970,000 weekly downloads. These are not obscure tools. They are fixtures of everyday JavaScript development.
How the Malware Works
When a developer installs an affected package, the payload fires immediately. A hook executes before any other step, giving the malicious code immediate access to the machine. It harvests GitHub tokens, npm tokens, SSH keys, cloud provider credentials, and database connection strings.
The malware serializes, Gzip-compresses, AES-256-GCM-encrypts, and RSA-OAEP-wraps the stolen data before sending it out. It routes primary exfiltration over the Session P2P network, a design choice that makes detection and takedown substantially harder.
The malware does not stop at the infected machine. Using stolen npm tokens, it authenticates to the registry as the compromised developer, identifies other packages that developer maintains, injects the malicious payload, and republishes them with bumped version numbers. The entire process runs without any direct intervention from the attacker.
Rolling back the dependency does not fix the problem. The malware embeds backdoors in developer tool settings — including .vscode/tasks.json — which stay on disk even after the npm package is gone. Developers must audit and clean those files to fully eliminate the attacker’s foothold.
The Sigstore Problem
The most alarming development in this latest wave is not the scale. It is the trust bypass. The worm generates cryptographically valid Sigstore provenance attestations for every package it publishes. Using an ephemeral key pair, the payload mints OIDC identity tokens from the compromised CI environment, submits them to Fulcio for signing, and logs entries to the Rekor transparency log. The result: infected packages display a green provenance badge and pass all standard verification checks.
The practical implication for defenders is serious. A package can now carry a valid provenance badge and still steal credentials. The certificate subject is a legitimate CI identity. The Rekor log entry is real. The verification check passes. This forces a hard rethink of how developers assess trust in open-source dependencies.
A Growing Campaign
The Shai-Hulud campaigns started last September and have since hit multiple software ecosystems, including npm, PyPI, and Composer. The malware compromises maintainer accounts or publishing tokens to push legitimate packages with malicious code, then uses stolen credentials to spread to other projects.
Recent waves hit TanStack, UiPath, and Mistral AI packages. The TeamPCP threat group also leaked the malware’s source code on GitHub, which has complicated attribution efforts and likely lowered the barrier for other actors to run similar campaigns.
As a fallback exfiltration channel, the malware uses stolen GitHub tokens to create repositories under victims’ accounts and commit stolen data to them. Researchers have so far found over 2,700 such repositories.
What Developers Should Do
The response steps are urgent for any team that ran npm installs recently. Affected organizations should immediately rotate GitHub tokens, npm tokens, AWS credentials, and Vault tokens exposed in CI/CD environments. Teams should not rely on Sigstore provenance badges alone to assess package safety. Developers should also review npm install logs for unexpected preinstall scripts.
Removing the infected package is not enough. The malware installs OS-level background services on both Linux and macOS that survive package removal. A process called kitty-monitor polls GitHub every hour for signed remote commands. A second process, gh-token-monitor, checks stolen tokens every 60 seconds and alerts the attacker the moment someone revokes one. Teams with any potential exposure should treat all compromised credentials as fully burned and kick off incident response procedures immediately.
Final Thoughts
This npm supply chain attack stands out not just for its speed or scale, but for what it has broken. Sigstore was built to restore trust in open-source packages. This campaign has shown that attackers can turn even a robust verification framework against the developers it was meant to protect. With the malware’s source code now publicly circulating and fresh waves hitting every few weeks, pressure on npm to introduce stronger publish controls keeps growing. Until that happens, developers need to verify the integrity of their publishing pipelines — not just the packages they install.
