Shai Hulud 2.0 is active in npm now and it’s spreading through the same packages developers install every day.
This is a supply chain attack that moves through normal development workflows, which means teams are running into it without realising anything is wrong. This activity has already reached Australian organisations.
How they get access
The issue starts when an infected package is installed. The package runs a small script during the install process and that script sets up a larger payload that sits inside the package. Once it runs it looks for GitHub tokens npm tokens cloud credentials and anything else that can give it access to other systems. It also scans the home directory for any leftover secrets.
How it spreads
After it collects those credentials, it uses them to create new repositories and publish modified versions of existing packages. The next developer who pulls an updated package ends up infected even if the original source looked safe. This is why the impact is wide and not necessarily tied to one project or team.
What happens when its access is cut
If it loses access to both its GitHub path and its npm path, it starts wiping data on the infected system.
- On Windows, it tries to delete user files and overwrite disk space.
- On Unix based systems, it tries to shred files inside the home directory.
This is difficult to handle because cutting off the attacker’s access can cause many infected systems to wipe data at the same time.
How it keeps moving
Shai Hulud 2.0 spreads through normal package installs. A developer installs or updates a package and the malware runs in the background. No one has to open anything unusual. Any saved access token for GitHub, npm, or cloud accounts can then be taken and used to move the attack further.
This becomes a bigger problem for organisations that publish their own npm packages. If one account is affected, the malware can republish every package under that account with the same malicious files. Then it keeps moving into internal systems without being noticed.
What teams should check
Start by looking at any npm installs or updates from the past week. Focus on packages that run install scripts because that is where the worm hides. If something looks unfamiliar, remove it, clear the npm cache, delete node_modules, and reinstall from versions you trust.
If a system pulled anything suspicious, rotate the GitHub tokens, the npm tokens and the cloud credentials on that machine. Then check your GitHub organisation for new public repositories you did not create. The worm uses them to store stolen data, so anything unexpected needs a review.
Pin your dependencies to clean versions or roll back to builds from before November twenty one. Avoid updating to new versions until maintainers confirm the package is safe.
Open the package.json files for recently updated projects and look for lifecycle scripts that do not belong there. setup bun is the one that keeps appearing. If you see anything similar, remove the package and reset the environment.
In CI pipelines, limit how install scripts run. Some teams are reducing postinstall and preinstall behaviour or running builds in isolated environments. Short lived automation tokens help because they lose value quickly when stolen.
Keep an eye out for destructive activity. Windows systems show deletion and overwrite commands. Linux and macOS systems show shred activity. If you see either, treat it as urgent and isolate the machine.
