Shai-Hulud & Co.: The software supply chain as a weakness

Today’s applications rely on numerous components, each of which, along with their development environments, represents an attack surface. Regardless of whether companies develop code in-house or rely on third-party vendors, CISOs, security experts, and developers must pay close attention to the software supply chain. These risks include, for example, React2Shell, Shai-Hulud , and XZ Utils — all software supply chain vulnerabilities that started small and later had huge consequences.

See also: Vulnerabilities in npm and yarn platforms allow bypass of Shai-Hulud defenses

Shai-Hulud stands out in particular, marking the end of the “passive era” of supply chain attacks and the beginning of the “active worm era.” This shift promises to have devastating consequences for software production lines. Traditionally, supply chain attacks have been passive traps. An attacker would upload a typosquatted package,such as “reqeusts” instead of “requests,” and wait for a careless programmer to make a mistake. The blast radius was linear and quite slow. Shai-Hulud changed the rules of the game by introducing a worm-like propagation method.

Once it lands on a developer's machine, it actively collects credentials (NPM tokens, GitHub secrets). It uses these stolen credentials to automatically publish infected versions of other legitimate packages managed by the victim.

Unlike spyware, which aims to remain hidden, Shai-Hulud variants include a “dead man switch.” If it detects that it is being blocked or analyzed, it attempts to wipe the victim’s system, completely erasing all traces of it. The target is no longer just the application, but the developer’s identity and the automated CI/CD pipelines that implicitly trust them.

A worm like Shai-Hulud could infect a data scientist’s laptop, scan the local LLM chat history for private package names, and automatically post malicious versions publicly. A worm in this ecosystem wouldn’t just bring down a website, it could also discreetly poison financial models, corrupt medical research data, or insert backdoors into corporate AI training sets—damage that could go unnoticed for years.

See also: Shai-Hulud v2 campaign expands from npm to Maven

Other examples would be Java/JVM or Rust/Go programming languages; here too, the impact would be devastating. The scariest prospect, however, is the convergence of these threats into a multi-language attack on the supply chain. Currently, security teams operate in silos. AppSec monitors the code, CloudSec monitors the cloud, NetworkSec monitors the perimeter. A multi-language attack is designed to seamlessly penetrate these silos.

The attack could start in NPM but end up as a compiled binary backdoor in the cloud production infrastructure. The JavaScript security team will not detect it because it immediately left their domain. The cloud security team will also miss the threat because it was delivered from a trusted CI production line using valid credentials. CISOs need to be aware of this and take appropriate precautions.

The EU Cyber ​​Resilience Regulation (CRA) provides guidance for CISOs. It requires manufacturers, importers and distributors to protect digital products, encouraging them to invest in secure design during development and maintenance. The requirements outlined there must be implemented gradually by the end of 2027 and include the security of networked hardware and software through vulnerability management and their publication or notification to competent authorities.

See also: New version of Shai-Hulud worm spreads via npm, GitHub

In addition, the three aforementioned stakeholders must also document the software components in software bill of materials (SBOMs). The NIS2 Directive, which has now entered into force, contains similar requirements for critical infrastructure operators (KRITIS) to those provided for in the NIS2 Implementing Act (NIS2UmsuCG) and the KRITIS Act regarding products and suppliers.