The JavaScript ecosystem is dealing with another major supply-chain incident. A second wave of the Sha1-Hulud malware, initially launched in September, has compromised thousands of projects by abusing malicious NPM packages. Over the past week, researchers have confirmed widespread credential theft, large-scale repository compromise, and automated propagation through developer tooling. For many organisations, this has been an unwelcome reminder of how fragile dependency chains can be.

How the second wave of Sha1-Hulud works

This campaign uses malicious preinstall scripts placed inside compromised NPM packages. These scripts run automatically whenever the package is installed. They execute before many scanning tools or protective controls have a chance to intervene. Once active, the malware attempts to collect a wide range of credentials. These include GitHub tokens, cloud access keys, and NPM authentication tokens.

It also registers the victim’s machine as a self-hosted GitHub Actions runner. This gives the attacker a remote execution point inside the victim’s build environment. The malware then uses any recovered NPM tokens to publish altered versions of the victim’s own packages. This allows the infection to spread quickly and with very little manual effort. In some cases, the malware also attempts destructive actions if it cannot exfiltrate data successfully.

Scale and impact on software supply chains

The reach of this incident has been significant. Tens of thousands of GitHub repositories have had secrets uploaded to public locations controlled by the attacker. Many affected maintainers discovered the issue only after seeing unexpected workflows, rogue runners, or unusual package versions in their accounts.

Victims range from individual developers to major software vendors who depend on widespread, trusted software dependencies that are affected by the attack. Many developers are now forced to expend considerable time and effort rotating credentials, reviewing build pipelines, and checking package histories to confirm the extent of the compromise. Developers did not act recklessly. They relied on a trusted ecosystem that is designed to install and execute third-party code with minimal friction.

The risks of modern development practices

This incident highlights a long-standing challenge in software development. Modern applications depend on large numbers of open-source packages, which are often maintained by small teams or individual volunteers. Installation is automated, and execution during installation is normal. Developers expect convenience and speed, however these latest attacks demonstrate that attackers can take advantage of these qualities and propagate malware quickly. Unlike a traditional supply chain attack, the compromise of one NPM package can wreak havoc on layers upon layers of dependencies and software products. It’s dependencies all the way down.

Defending against this type of attack is complex. Preinstall scripts are a legitimate part of NPM, and blocking them entirely would break many packages, however doing so may be a necessity if attacks like this are likely to repeat. Developers may restrict outbound network access from build environments, and use credentials with short expiry periods for automation.

Are developers at fault?

There is a temptation to ask what organisations should have done differently. It’s fair to say that victims acted responsibly for the most part. Developers used reputable packages with millions of installations, packages which are embedded into the fabric of the modern software ecosystem. They followed normal development practices and had no reasonable way to spot the compromise before it occurred.

Nevertheless, this second wave of attack could make the case for more stringent oversight and processes used to evaluate the suitability of packages in software supply chains. Certification or governance of open-source packages, specifically in terms of access management and code review could provide assurance up-chain, however it’s important to remember that most of these packages are maintained on a voluntary basis. Who will pay for a maintainer to meet the compliance requirements of global enterprises and hobbyist developers?

What actions should be taken?

Teams affected by this incident will need to focus on containment. This includes rotating credentials, removing rogue workflow files, rebuilding compromised machines and repositories, and auditing package changes. For others, it is worth reviewing how dependency installation is handled and where sensitive credentials are stored.

To remove affected packages, run:

npm cache clean –force

rm -rf node_modules

Developers should roll back packages to known safe versions, or versions before 21^st November 2025 if unsure.

Further actions should be taken to investigate development code, build and infrastructure environments where compromised packages are found.

Closing Thoughts

This second wave of Sha1-Hulud shows how quickly a supply-chain compromise can escalate. It also shows how difficult such attacks are to defend against, even for well-resourced teams. The software ecosystem is built upon open-source code maintained on a voluntary basis, and enforcing governance and process on these maintainers is not feasible without compensation. The strengths and benefits of modern software stacks also bring a new dimension of security considerations.

Incidents like this may continue to happen without upheaval of accepted software practices, which will be unwelcome and difficult in many ways. At Sentrium, we spend a lot of time helping organisations understand the practical realities of security in complex environments, and events like this reinforce why awareness and steady improvement matter. If you’d like to discuss how these issues relate to your own environment, we would love to hear from you.