A self-propagating malware worm dubbed “Shai-Hulud” has compromised over 571 packages in the npm ecosystem, marking what security researchers are calling the most severe JavaScript supply-chain attack observed to date. The attack, which began on September 15, 2025, exploits stolen npm maintainer credentials to inject data-stealing payloads into some of the most widely used JavaScript libraries — and then spreads autonomously to infect even more packages.
The Exploit Mechanics
The attack chain began with the publication of malicious versions of multiple popular npm packages. Once installed, these tampered packages execute a post-install script that launches a multi-stage harvesting operation. The malware uses TruffleHog, an open-source secret scanning tool, to sweep the victim environment for credentials, environment variables, and cloud keys exposed through instance metadata services (IMDS).
What sets Shai-Hulud apart from prior supply-chain incidents is its worm-like self-propagation capability. When the compromised package detects additional npm tokens in the host environment, it automatically publishes malicious versions of every package those tokens can access. This creates a cascading infection that spreads across the npm ecosystem without any human interaction.
Wiz Research, which first documented the campaign, assesses that this is directly downstream of the late-August s1ngularity/Nx compromise — an earlier GitHub token theft that escalated into npm token theft and mass package poisoning. The initial batch of infected packages included multiple victims of that earlier breach, creating a foothold for the broader worm.
Affected Systems
The compromised packages include foundational JavaScript libraries that are dependencies in thousands of projects worldwide. Any development environment, CI/CD pipeline, or production server that installed these packages between September 15 and September 19, 2025, is potentially affected.
The malware exfiltrates harvested data to attacker-controlled public GitHub repositories named “Shai-Hulud.” Beyond simple data theft, the worm also drops two additional scripts: a “workflow script” at /tmp/processor.sh that triggers automated branch creation to exploit GitHub Actions secrets, and a “migration script” at /tmp/migrate-repos.sh that clones private repositories and republishes them as public repositories with a “-migration” suffix.
The migration routine first creates a private repository, then immediately flips its visibility to public — generating two observable GitHub events (CreateEvent followed by PublicEvent) that security teams can use for detection. Some of the payloads appear to be AI-generated, while others show different stylistic patterns, suggesting multiple contributors or evolving tooling.
The Mitigation Strategy
CISA published an official alert and guidance for organizations on September 19, 2025. The recommended immediate actions include:
- Audit dependencies: Check all npm packages installed since September 15, 2025, against the published list of compromised versions
- Rotate credentials: Immediately rotate all npm tokens, GitHub tokens, and any cloud credentials that may have been exposed in CI/CD environments
- Review GitHub repositories: Look for newly created public repositories with “-migration” suffixes, which indicate successful exfiltration
- Scan for Indicators of Compromise: Check for files at
/tmp/processor.shand/tmp/migrate-repos.shon build systems - Enable package locking: Use lockfiles and pin exact package versions to prevent automatic installation of malicious updates
For crypto projects, the risk is amplified. Many Web3 applications rely on JavaScript toolchains for frontend development, smart contract compilation, and testing frameworks. A compromised dependency in a wallet interface or DeFi dashboard could expose private keys or seed phrases.
Lessons Learned
The Shai-Hulud attack demonstrates a troubling evolution in supply-chain threats. Previous incidents like the ua-parser-js and event-stream compromises required manual propagation — attackers had to individually compromise each package maintainer. Shai-Hulud automates this entirely, creating a self-sustaining infection cycle.
For the cryptocurrency ecosystem, where development velocity often outpaces security review, this attack underscores the need for rigorous dependency auditing. Projects building on Ethereum, trading near $4,471 on September 19, and other chains must treat their JavaScript supply chain with the same rigor they apply to smart contract auditing.
User Action Required
If you are a developer working on crypto or Web3 projects, take the following steps immediately: verify your package-lock.json files against the list of compromised packages published by Wiz and Socket Security, rotate any npm or GitHub tokens that were present in environments where compromised packages were installed, and audit your CI/CD pipelines for unusual activity between September 15 and September 19, 2025. Organizations should also consider adopting signed packages and reproducible builds to reduce the attack surface for future supply-chain compromises.
Disclaimer: This article is for informational purposes only and does not constitute financial or investment advice. Always conduct your own research before making any financial decisions.
571 packages and npm still runs postinstall scripts with full system access by default. cargo sandboxs builds and pip has hash pinning. npm just hopes for the best
Tomas N. trufflehog scanning IMDS v1 endpoints on every compromised install means one bad package owns your entire AWS account in minutes. npm needs sandboxed installs
Interesting perspective — I hadn’t considered that angle before
Bear markets are for building — and builders are delivering
The fundamental value proposition of crypto keeps getting stronger
@Olga Smirnova exactly. social engineering combined with technical exploits is the real threat vector now
social engineering plus automated propagation is the worst combo. steal one devs credentials and the worm does the rest across hundreds of packages silently
trufflehog sweeping for cloud keys through IMDS is nasty. any EC2 instance with a compromised npm install exposes your entire AWS account in minutes
Aoife B. IMDS v2 has been available since 2018 and half of AWS customers still run v1 because legacy apps break on upgrade. attackers know this
imds_kill_switch_ IMDS v1 still running on half of AWS is insane. npm worms are just scanning for credentials that cloud providers told us to stop using 4 years ago
the worm spreading through stolen maintainer credentials means one compromised 2FA and suddenly hundreds of packages are infected. npm needs mandatory hardware keys for publish access
Sigrid V. hardware keys for every npm maintainer would kill community contributions. maybe scoped publish tokens with per-package limits instead
Education is still the biggest barrier to mainstream adoption
This is exactly the kind of development the space needs
571 packages compromised and most devs wont even know theyre affected until something gets drained. the blast radius of npm supply chain attacks is unmatched in any ecosystem
571 packages and the npm team still has no automated way to detect credential reuse across maintainers. every fix is reactive after the damage is done
571 packages and npm still has no native dependency freezing. pip has hash pinning, cargo has checksums, npm just hopes for the best
Sanna K. IMDS v2 was supposed to fix this but every brownfield EC2 instance still runs v1. the metadata service is a gift that keeps giving to attackers
571 packages and npm still relies on maintainers rotating tokens manually. cargo has had checksums since day one
imds_pivot_2 cargo has had checksums since day one AND its still smaller than npm by 10x. npm has no excuse at this point. 571 packages and counting
the trufflehog integration is clever from the attacker side. scan for cloud keys through IMDS and you own the entire AWS account in minutes
postinstall scripts running arbitrary code on install is the original sin of npm. 571 packages later and still no sandboxing
Csilla F. postinstall scripts are the original sin but cargo has build scripts too and nobody got wormed at this scale. npm just refuses to learn from other package managers
cargo_envy_ cargo has build scripts but they run sandboxed. npm postinstall runs with full filesystem and network access by default. thats the difference
571 packages compromised and npm still doesnt require hardware keys for maintainers of packages over 100K weekly downloads. insane
571 packages and npm still does not require 2FA for maintainers over 100K downloads. the supply chain is only as strong as the laziest maintainer with a compromised token
Joon L. exactly. cargo and pip at least have optional sandboxed builds. npm gives postinstall full system access by default and nobody questioned it for a decade