Published on 5 August 2026
Anyone who simply ran npm install in a Node.js project on 4 August 2026 may have unwittingly invited a data thief into their house – without noticing. That day marked the beginning of one of the most far-reaching software supply chain attacks the npm ecosystem has ever seen. Within just a few hours, more than 430 software packages with a combined total of over 2 billion monthly downloads were infected with malicious code. Affected are packages that sit in practically every modern web project – often without developers even knowing they are there.
The attack goes by the name "Shai-Hulud" and works like a digital worm: it steals credentials, uses them immediately to copy itself onto further packages, and thereby propagates on its own. In this article we explain exactly what happened, whether your company might be affected, and what concrete steps you need to take now.
On the morning of 4 August 2026, attackers gained access to the GitHub account of Jared Wray, the maintainer (that is, the responsible developer) behind the popular npm package keyv. For context: keyv alone is downloaded around 127 to 153 million times per week. It is a building block used in countless other programs.
Through the hijacked account, the attackers injected a so-called credential stealer – a piece of malware specifically designed to steal access credentials and passwords. Initially affected was keyv@6.0.0, but it didn't stop there. Shortly afterwards, further widely used packages followed:
Particularly explosive: flat-cache and file-entry-cache are so-called transitive dependencies – meaning they are often not included directly, but come along automatically as part of other packages. As a result, they sit deep and invisible in almost every Node.js project. By the afternoon, over 433 packages across more than 2,200 poisoned versions were affected, spread across more than 14 organizations – including internal corporate packages from companies such as @servicetitan, @onereach and @qlik.
To understand why this attack is so dangerous, it helps to look at the mechanics. When you install an npm package, it can contain so-called lifecycle scripts – small commands that are executed automatically during installation. One of these is called preinstall and runs before the actual package is installed.
It was precisely this mechanism that the attackers exploited. During installation, a script named setup.mjs launched, which downloaded an additional runtime environment (the Bun runtime, version 1.3.13) from GitHub in the background. It then executed the actual malicious code – a 728-kilobyte, heavily obfuscated payload – files named Math_Symbol.js and math_init.js respectively.
This malicious code systematically searched the computer for valuable credentials:
The stolen data was secured with strong encryption (AES-256-GCM) and then exfiltrated – partly via newly created GitHub repositories with the telltale title "Shai-Hulud: Here We Go Again", partly via rotating control servers whose addresses were even distributed dynamically through an Ethereum smart contract.
Two details make this attack particularly insidious. First: the malware placed additional hooks in the configuration files of developer tools (.vscode/tasks.json and .claude/settings.json) so that it would re-execute itself whenever the project was reopened – a persistence mechanism. Second: a so-called dead man's switch monitored the stolen GitHub token. As soon as someone revoked this token, a deletion function was triggered. This is why the order of the countermeasures is crucial – more on that later.
One might think that modern security systems should have caught something like this. The tricky part: the attackers did not upload some fake package, but took over the projects' genuine, official release automation. As a result, all poisoned packages carried a valid so-called SLSA provenance signed by GitHub Actions – a digital proof of origin intended to demonstrate which repository a package comes from.
"A provenance signature proves which repository a package was built from. It says nothing about the contents of the package." – Dr. Web Magazin
Markus Seyfferth, editor-in-chief of Dr. Web, gets to the heart of the underlying problem:
"The provenance signature on npm proves which repository a package comes from, and nothing else. As long as a preinstall hook launches foreign code during installation, even the cleanest signature helps no operator."
The security firm StepSecurity also confirms that automated checks were powerless here:
"Because the attacker drove the projects' real release automation, every malicious publish carries a genuine SLSA provenance attestation... Any tooling that gates on 'has valid provenance' would have waved keyv@6.0.0 straight through." – StepSecurity
In principle, everyone is affected who installed or updated one of the infected package versions between the morning of 4 August 2026 and the cleanup by npm. This particularly concerns:
npm install was executedIf your company does not develop software itself but has a website or application operated by an agency or service provider, you should immediately ask them whether and how they are affected. Because many web projects are based on Node.js in the background – and therefore potentially on precisely these packages.
If you or your team have access to the source code, check in this order:
package-lock.json, yarn.lock or pnpm-lock.yaml and search for the affected versions – such as keyv 6.0.0, flat-cache 6.1.24 or file-entry-cache 11.1.6.setup.mjs, Math_Symbol.js or math_init.js..vscode/tasks.json or .claude/settings.json exist that contain a call to setup.mjs.If you find signs of an infection, proceed in a structured manner. Important: the order is crucial – because of the dead man's switch described above, you must not simply revoke all tokens immediately, otherwise a deletion routine may be triggered.
~/.local/bin/gh-token-monitor.sh) before you revoke any credentials.keyv@5.6.0). The affected versions have since been largely removed from the npm registry.npm install --ignore-scripts during installations to prevent the automatic execution of such preinstall hooks.The security firm Wiz Research, which is actively investigating the attack, also reports that the attackers adapted their approach over time: "The operator has provided a new RSA key, used to encrypt exfiltrated data." This means: this is not a one-off, closed incident, but an active, evolving campaign. Stay vigilant and follow updates from the security vendors mentioned.
This incident must be classified as critical and is being actively exploited. The theft of cloud and CI/CD credentials potentially opens the door for attackers to production systems and therefore to customer data. This is precisely where data protection comes into play.
Under Art. 33 GDPR, there is an obligation to notify the competent supervisory authority within 72 hours if the theft of credentials – such as cloud keys or database access – creates a risk to the rights and freedoms of natural persons. Since the malware specifically extracts credentials that can enable access to customer databases, a high risk must be assumed in a worst-case scenario. This may additionally make a notification of the affected individuals under Art. 34 GDPR necessary.
So check not only the technical side, but document the incident and assess, together with your data protection officer, whether there is a reporting obligation. The 72-hour deadline runs from the moment you become aware of the breach.
It should also be noted: from 11 September 2026, the Cyber Resilience Act (CRA) takes effect. For actively exploited vulnerabilities in products, it requires an initial report within 24 hours. For companies that ship software containing such components, the reporting obligations become even more stringent as a result.
The Shai-Hulud attack strikingly demonstrates how vulnerable modern software supply chains are. A single compromised developer account was enough to poison over 430 packages with a combined total of more than 2 billion monthly downloads within four hours – and that with valid proofs of origin, off which automated security checks bounced ineffectively.
The core message for you as a company: Do not rely solely on signatures and automated checks. As Moshe Siman Tov Bustan of OX Security puts it, more is needed than merely blocking installation scripts and mandatory two-factor authentication for maintainers – namely granular control over what a package is even allowed to do.
Concretely, this means for you: clarify with your development team or service provider whether your projects are affected, carry out the verification and protection steps outlined above in the correct order, rotate all credentials when in doubt, and document the incident with a view to your GDPR obligations. Speed and diligence are equally required here – this worm propagates on its own.