… and the next supply chain attack!

Just at the beginning of the week, we wrote that the next attack would not be long in coming. And it was already on its way!

At first, we thought the reports about this worm were an exaggerated version of the last attack. But it actually seems to be a much worse version of the previous one. What happened this time?

Playbook

In the previous, fascinatingly composed attack, infected NPM packages were used to steal developers’ credentials and export them to public repositories. This is unpleasant and annoying, but if noticed in time, it can still be repaired by renewing all credentials that have become public and monitoring the access points/systems accordingly; it’s not child’s play, it’s not free, but it’s doable.

However, this case is much more serious because the attack was supplemented with a worm element. After the credentials were published, the system used them to spread to other repositories. It slipped into package.json by adding bundle.js as a postinstall script. This then carried out the malicious actions unobserved and even persisted in its own branches with its own workflows. Details are all described in this article.

As a result, tokens and credentials are collected and published. But that’s not all. With the help of workflows, the worm attempts to convert/clone private repositories into public versions and spread itself accordingly by injecting itself into all packages it can access and publishing the infected packages.

Indicators

To find out if you are already affected, you need to search for bundle.js in the package.json files. By Monday (September 22, 2025), we will provide an extension for our ts-scan tool that reads the package.json anyway during scanning and can then issue appropriate warnings _before_ executing the build so that the build can be aborted. To use this interactive element, manual execution is recommended. We are currently working on an extension for automated scanning of entire repo trees.

In addition, the organization’s existing repositories or repository lists should be examined for repositories with the name Shai-Hulud—Dune fans will be able to recognize it. Such repositories are clear indications of an infection. Also look for branches with the name. These may contain workflows that perform further malicious actions. Another indicator at the repository level are public repositories named *_migration.

Protection

We cannot repeat it often enough: the security benefits of setting up a package proxy are unbeatable! Even if it is quick and easy to install something on the fly, the opportunity costs are simply too high. If your development team does not yet use proxy package servers or if they simply pass on new package requests without checking them—e.g., the default setting for AWS CodePipeline proxies—change this as soon as possible! We are happy to support you in this.

If builds use the public registry, it is recommended to immediately stop all pipelines to prevent further spread. The next step is to identify possible infections (see above, Indicators). Our ts-scan tool can be used for this purpose.

The infected repositories must be cleaned up accordingly; ideally, compromised repositories should be rolled back to the state beforethe infection. To be clear: they should be deleted and restored from the backup to the state prior to the infection (September 13, 2025).

In addition, all developers who have worked with these repositories must discard their current development status and clone the restored repositories again. If they have worked on the infected repositories, they should also reset their development computers beforehand.

As long as build environments allow everything – the problem that the Node build process can be compromised is not new, see for example this eight-year-old Stackoverflow article – building packages will remain a dangerous business. An integrity check before building would be a good idea here. Other ecosystems, such as Swift or Rust, solve this by only allowing building in sandboxes. This is a clear call to the Node community to take care of the security of their system! (Hello @OpenSSF?)

Outlook

Attackers are enormously creative. And they are not going to slow down. Increasing political tensions are broadening the base on which bad actors feel comfortable and where devising new attack vectors or mechanisms pays off. As already pointed out in the penultimate post, we can therefore expect further actions and scenarios that we cannot yet foresee today. To avoid becoming a victim, it is advisable to prepare yourself. Think ahead during good times and identify potential gaps and assess the consequences. Threat modeling is the order of the day.

This is not rocket science. In fact, it is relatively simple. You just have to do it. And if you want to learn how, you can take advantage of our free threat modeling course (currently German only).

But once you’ve done it, it’s not over. You should also follow up on the tasks. This works wonderfully with the new version of TrustSource, for example. In the new Risk Management Module, tasks can be scheduled and those responsible can be directly linked to the identified risks. With the appropriate reports and overviews, every CTO can thus keep a firm grip on their development organization.

Feel free to contact us to define the right roadmap for your organization.