• 4 min read
ChainDrop npm worm infects 1,300 packages
The ChainDrop npm worm compromised more than 1,300 packages, stealing GitHub, npm, cloud, Kubernetes, and CI/CD credentials.
Image: BleepingComputer
A self-propagating npm malware campaign called ChainDrop has compromised more than 1,300 packages with a combined 2 billion monthly downloads, turning a single maintainer-account breach into a broad software supply-chain attack.
The campaign began after an attacker compromised the GitHub account of the maintainer behind Keyv. It then spread to related caching utilities, including Cacheable, flat-cache, and file-entry-cache, as well as packages associated with Deliveroo, Ornikar, OneReach, Picsart, Qlik, and ServiceTitan.
Multiple application-security companies identified the malware as a Shai-Hulud-based worm. Aikido reported that at least 868 packages across 1,381 versions had been compromised. That figure does not match the broader package count reported for the campaign, suggesting the researchers were measuring different portions or stages of the attack.
Recommended reading
Microsoft pays record $20 million in bug bounties
How ChainDrop infects npm installs
The attackers pushed malicious files into projects' main GitHub branches and generated new npm releases through the projects' legitimate GitHub Actions workflows. As a result, the poisoned packages carried valid provenance information — a sign that normally helps consumers distinguish official builds from tampered artifacts.
Each affected package contains two key files:
- setup.mjs, a dropper
- Math_Symbol.js or, in some packages, math_init.js, the obfuscated information-stealing payload
The package configuration also adds a preinstall script:
''json “preinstall”: “node setup.mjs” ''
That means the dropper runs automatically when someone installs an affected version, before the installation completes.
setup.mjs downloads the Bun JavaScript runtime from an official GitHub release, uses it to launch the malicious JavaScript, and then removes the temporary runtime directory. The payload can also spread the infection to packages maintained by others when those packages are used in a compromised environment.
“Anyone who ran npm install against an affected version would have had setup.mjs execute automatically before their install completed,”
Credentials targeted across developer systems
The malware validates tokens in real time against registry.npmjs[.]org/-/whoami before stealing them. It searches infected developer workstations and CI/CD runners for credentials that could provide access to additional source repositories and npm packages.
The stolen data can include:
- Process environment variables and local configuration or credential files
- GitHub personal access tokens, workflow tokens, and ghp_, gho_, and ghs_ tokens
- npm tokens beginning with npm_
- GitHub Actions secrets, including values marked “isSecret”: true on self-hosted runners
- AWS credentials, SSM Parameter Store values requested with decryption, and Secrets Manager secrets
- Kubernetes secrets from accessible namespaces
- HashiCorp Vault tokens and KV secrets
- Database credentials, private keys, and Stripe, Slack, Twilio, Azure, and Google Cloud credentials
The infostealer encrypts the collected information and sends it to a public GitHub repository described as “Shai-Hulud: Here We Go Again.” Cloud-security company Wiz also identified npm-cache[.]com as an exfiltration domain and recommended treating it as a strong indicator of compromise.
The combination of npm credentials, GitHub tokens, cloud secrets, and CI/CD access gives the worm a path to continue propagating beyond the original package set. In practical terms, a package installation can become a compromise of the build environment and the repositories or services that environment can reach.
What affected projects should do now
Administrators should treat any developer workstation or CI/CD runner that installed an affected version as compromised, even if the package was later removed. The recommended response is to:
- Rebuild the system from a known-safe backup or from scratch.
- Rotate every token accessible from the affected environment.
- Review logs for unauthorized access.
- Inspect source repositories for unexpected commits or other changes.
- Check the published package history and network activity against available indicators of compromise.
The campaign is still unfolding, and the number of affected packages and exact malicious versions may grow. Security companies including Wiz, StepSecurity, Aikido, Socket, and Ox Security have published package lists and indicators such as malicious-file hashes and network data.
The incident also shows why provenance alone cannot establish that a release is safe: attackers used legitimate GitHub Actions workflows to produce releases that retained valid provenance. Dependency allowlisting, integrity checks, and provenance controls remain recommended defenses, but they must be paired with monitoring and rapid credential rotation — the same kind of time-based and release-integrity defenses covered in GitHub and PyPI’s supply-chain changes.
Security Editor
Sophia unpacks the invisible wars happening on our networks. Covering cybersecurity, privacy legislation, and cryptography, she exposes how our data is weaponized and defended. Before joining for(geeks), she spent years as a penetration tester. She's the reason the rest of the team uses physical security keys.
via BleepingComputer
