When SHA1 Hulud Malware attacks, it doesn't usually make a lot of noise to warn people. It sneaks into the places that developers trust the most. The whole npm community learned this the hard way in late 2025. What started as a strange find in September turned into one of the most disturbing supply chain attacks we've seen in years.
This time, it affected more than 25,000 GitHub repositories and went deeper than anyone thought it would. Even for people who have dealt with supply chain problems before, this one felt different, almost personal.
Developers who had seen the first wave hoped the worst was over, but the second wave of attacks showed that Sha1 Hulud Malware is smarter and stronger than before. I can still remember the first time I saw the news. It was like déjà vu mixed with anxiety because the methods looked familiar but much better than the first time.
A Look Back at the First Sha1 Hulud Event
Researchers had already found the first worm in September 2025, before the second wave hit. Security teams saw that more than 500 npm packages had been infected with malware. Not small, random packages, but a mix of well-known and niche modules that fit right into the way developers work every day.
When Sha1 Hulud Malware attacks, it knows exactly where to go.
CISA warned that the malware was actively looking for cloud credentials. AWS, GCP, Azure, GitHub tokens, environment variables, and anything else that lets you in. Securelist later confirmed that the infected packages ran scripts that were hard to understand and hard to read. These scripts used tools like TruffleHog to look through secrets and send them to GitHub repositories that attackers controlled.
Things were already bad. Most developers thought this was just another one-time problem that the package maintainers would fix. But the peace didn't last long.
November came, and Shai Hulud came back stronger than ever.
The second wave came two months later. The energy felt different this time. Companies like Wiz looked into the attack and found that the malware was now using scripts that were already on the computer. That makes everything different. Preinstall scripts run before the installation process itself, so attackers don't even have to hide their payload in normal build steps. They take charge before anything else happens. Timing is one of the most powerful weapons that the Sha1 Hulud malware uses.
Reports kept mentioning file names like setup_bun.js and bun_environment.js. These files ran code in the background that not only stole secrets but also changed GitHub repositories. The malware created bad workflows, registered infected machines as self-hosted runners called SHA1HULUD, and used discussion.yaml workflows to steal secrets through GitHub Actions artifacts.
The fact that it cleaned up after itself made the attack even more disturbing. There was nothing sloppy about this. It was planned.
The Size of the Outbreak
There weren't just a few repos. During the second wave, Wiz said that more than 25,000 repositories had been hacked. At one point, about 1,000 new bad repos showed up every half hour. When Sha1 Hulud Malware hits, it spreads very quickly.
Snyk identified over 600 affected npm packages, many tied to widely trusted ecosystems. Bitget News went even further and talked about how the malware has a fallback feature that makes it even more destructive. It might delete writable files in a user's home directory if it can't steal their credentials. A bad wiper that is hidden in a package manager dependency. Every engineering team should be worried about that.
How the Attack Works
Knowing how the attack was set up helps developers see how sneaky and effective the spread was. Every time Sha1 Hulud Malware strikes, the chain goes like this:
1. Packages with Trojans
Attackers take control of maintainer accounts or upload bad versions of well-known packages like those from PostHog, Postman, Zapier, and others.
2. Running Before Installation
The preinstall script runs right away, even if it was installed by mistake. setup_bun.js runs the bad code in bun_environment.js.
3. Collecting Secrets
The malware looks for API keys, session tokens, cloud environment variables, and GitHub credentials. It checks both developer machines on the network and CI systems.
4. Injection of GitHub Workflow
The system that got infected turns into a self-hosted runner called SHA1HULUD. Then it adds a file called discussion.yaml to the workflow to upload stolen secrets.
5. Destruction When Blocked
If the malware can't get the credentials, it might delete files in the developer's home directory.
6. Self-Propagation
It uses stolen npm tokens to republish infected packages so that they can spread even more.
This whole chain can happen again in minutes every time the Sha1 Hulud malware strikes.
Why This Second Wave Is So Risky
The preinstall mechanism alone makes the attack surface much bigger. CI systems, automated deployments, and development machines all become unsafe. It is stealthy because bad workflows can look a lot like good automation. It combines stealing credentials with possible sabotage. And it's very hard to stop it from spreading because it spreads so quickly.
Because of all this, the second wave is much worse than the first.
How it affects developers in the real world
This attack wasn't just a theory. Developers who used trusted packages accidentally downloaded bad versions of them. Some companies found workflow files in their GitHub repositories that they didn't recognize. Some people found that secrets had been sent to remote repositories. When Sha1 Hulud Malware attacks, it follows the path of trust.
Teams suddenly had to switch credentials between cloud providers, check every workflow, look for strange runners, and check dependencies that were very deep. For a lot of engineers, this was the first time they understood how much they relied on npm's security.
Evolution of the Sha1-Hulud Attack: source
In this case, the harmful script was found in bun_environment.js and produces
repositories with randomized names holding exfiltrated data, labeled “Sha1-Hulud: The Second Coming,” unlike the prior attack’s <user>/shai-hulud structure.
What Developers Can Do to Stay Safe
There is no one-size-fits-all solution, but developers should take strong steps to protect themselves, especially now that Sha1 Hulud Malware is hitting multiple times:
• Check all dependencies
• Change your GitHub and cloud passwords right away. Look for suspicious YAML files in GitHub workflows. Turn on MFA for npm and GitHub. Keep an eye on outbound traffic and webhook activity. Pin packages to safe versions that have been verified.
• Get rid of old tokens and OAuth apps that you don't use anymore.
• Look for files like setup_bun.js.
• Look for GitHub runners that you didn't expect to host themselves.
Small steps, but steps that need to be taken.
Why This Matters More Than Code
This attack shows a much deeper truth. Supply chain security is no longer something that people talk about in the background. It has to do with cloud security, CI pipelines, developer trust, and even the most basic tools we use every day. When Sha1 Hulud Malware hits, it goes after the core of modern development.
It reminds businesses that developer machines and build systems are very valuable. They need as much security as production servers do. Losing a developer credential can be just as bad as losing a database.
Last Thing
We live in a time when malware can hide in the tools we use to make software. The second wave showed how quickly something can spread without anyone noticing. When Sha1 Hulud Malware attacks, it leaves a trail that goes far beyond just one bug or package. Stay careful, stay up-to-date, and don't ever think that trusted dependencies are safe without checking.
Questions and Answers
Q: What is the Sha1 Hulud virus?
A: It is a type of malware that acts like a worm and steals cloud credentials from npm packages and uploads them to GitHub-controlled repositories.
Q: How many packages were hacked?
A: The first wave hit more than 500 packages. The second wave affected more than 600 packages and tens of thousands of repositories.
Q: What makes the second wave worse?
A: It uses preinstalled scripts, adds harmful GitHub workflows, steals secrets quietly, and does damage if it fails to steal credentials.
Q: What can developers do to keep themselves safe?
A: Check dependencies, change credentials, lock down GitHub, check workflows, and pin safe package versions.
Q: Is the attack still going on?
A: Yes. Wiz and Snyk both say that things are still going on.
You can also read these important cybersecurity news articles on our website.
· Apple Update,
Author: Hoplon Infosec
Bio: Cybersecurity professional with 20 years’ experience protecting organizations from breaches, supply chain risks, and digital threats. Connect with me on LinkedIn.
Address: 1415 W 22nd St Tower Floor, Oak Brook, IL 60523, United States
Phone: +1 773-904-313 , Contact: info@hoploninfosec.com
About/Privacy: At Hoplon Infosec, we provide expert insights into cybersecurity. Our editorial policy: all articles are written by in-house specialists or thoroughly reviewed by them to ensure accuracy, credibility, and up-to-date information.
