Veröffentlicht am 05.08.2026
Wer am 4. August 2026 in einem Node.js-Projekt einfach nur npm install ausführte, hat sich möglicherweise einen Datendieb ins Haus geholt – ohne es zu merken. An diesem Tag begann einer der weitreichendsten Angriffe auf die Software-Lieferkette, die das npm-Ökosystem je gesehen hat. Innerhalb weniger Stunden wurden über 430 Software-Pakete mit zusammen mehr als 2 Milliarden monatlichen Downloads mit Schadcode verseucht. Betroffen sind Pakete, die praktisch in jedem modernen Web-Projekt stecken – oft, ohne dass die Entwickler überhaupt wissen, dass sie da sind.
Der Angriff trägt den Namen „Shai-Hulud“ und funktioniert wie ein digitaler Wurm: Er stiehlt Zugangsdaten, nutzt diese sofort, um sich selbst auf weitere Pakete zu kopieren, und verbreitet sich so von allein weiter. In diesem Artikel erklären wir, was genau passiert ist, ob Ihr Unternehmen betroffen sein könnte und welche konkreten Schritte Sie jetzt gehen müssen.
Am Morgen des 4. August 2026 verschafften sich Angreifer Zugriff auf das GitHub-Konto von Jared Wray, dem Maintainer (also dem verantwortlichen Entwickler) hinter dem populären npm-Paket keyv. Zur Einordnung: keyv allein wird rund 127 bis 153 Millionen Mal pro Woche heruntergeladen. Es ist ein Baustein, der in unzähligen anderen Programmen verwendet wird.
Über den gekaperten Account schleusten die Angreifer einen sogenannten Credential-Stealer ein – ein Schadprogramm, das gezielt Zugangsdaten und Passwörter stiehlt. Betroffen war zunächst keyv@6.0.0, doch es blieb nicht dabei. Kurz darauf folgten weitere weit verbreitete Pakete:
Besonders brisant: flat-cache und file-entry-cache sind sogenannte transitive Abhängigkeiten – das bedeutet, sie werden oft nicht direkt eingebunden, sondern kommen automatisch als Bestandteil anderer Pakete mit. Sie stecken damit tief und unsichtbar in fast jedem Node.js-Projekt. Bis zum Nachmittag waren so über 433 Pakete in mehr als 2.200 vergifteten Versionen betroffen, verteilt auf über 14 Organisationen – darunter auch interne Unternehmenspakete von Firmen wie @servicetitan, @onereach und @qlik.
Um zu verstehen, warum dieser Angriff so gefährlich ist, hilft ein Blick auf die Mechanik. Wenn Sie ein npm-Paket installieren, können darin sogenannte Lifecycle-Skripte hinterlegt sein – kleine Befehle, die automatisch beim Installieren ausgeführt werden. Eines davon heißt preinstall und läuft bevor das eigentliche Paket installiert wird.
Genau diesen Mechanismus nutzten die Angreifer aus. Bei der Installation startete ein Skript namens setup.mjs, das im Hintergrund eine zusätzliche Programmierumgebung (die Bun-Runtime in Version 1.3.13) von GitHub herunterlud. Anschließend führte es den eigentlichen, 728 Kilobyte großen und stark verschleierten Schadcode aus – Dateien mit den Namen Math_Symbol.js beziehungsweise math_init.js.
Dieser Schadcode durchsuchte den Computer systematisch nach wertvollen Zugangsdaten:
Die gestohlenen Daten wurden mit starker Verschlüsselung (AES-256-GCM) gesichert und dann nach außen geschleust – teils über neu angelegte GitHub-Repositories mit dem verräterischen Titel „Shai-Hulud: Here We Go Again“, teils über wechselnde Kontrollserver, deren Adressen sogar über einen Ethereum-Smart-Contract dynamisch verteilt wurden.
Zwei Details machen den Angriff besonders perfide. Erstens: Die Malware platzierte zusätzliche Hooks in den Konfigurationsdateien von Entwickler-Werkzeugen (.vscode/tasks.json und .claude/settings.json), damit sie sich beim erneuten Öffnen des Projekts selbst wieder ausführt – ein Persistenz-Mechanismus. Zweitens: Ein sogenannter Dead-Man's-Switch überwachte das gestohlene GitHub-Token. Sobald jemand dieses Token widerrief, wurde eine Löschfunktion ausgelöst. Deshalb ist die Reihenfolge der Gegenmaßnahmen entscheidend – dazu später mehr.
Man könnte meinen, moderne Sicherheitssysteme hätten so etwas abfangen müssen. Das Tückische: Die Angreifer haben nicht irgendein gefälschtes Paket hochgeladen, sondern die echte, offizielle Veröffentlichungs-Automatik der Projekte übernommen. Dadurch trugen alle vergifteten Pakete eine gültige, von GitHub Actions signierte sogenannte SLSA-Provenance – ein digitaler Herkunftsnachweis, der belegen soll, aus welchem Repository ein Paket stammt.
„Eine Provenance-Signatur belegt, aus welchem Repository ein Paket gebaut wurde. Über den Inhalt des Pakets sagt die Signatur nichts.“ – Dr. Web Magazin
Markus Seyfferth, Chefredakteur von Dr. Web, bringt das Grundproblem auf den Punkt:
„Die Provenance-Signatur auf npm beweist, aus welchem Repository ein Paket stammt, und sonst gar nichts. Solange ein preinstall-Hook beim Installieren fremden Code startet, hilft die sauberste Signatur keinem Betreiber.“
Auch die Sicherheitsfirma StepSecurity bestätigt, dass automatisierte Prüfungen hier machtlos waren:
„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
Betroffen sind grundsätzlich alle, die zwischen dem Morgen des 4. August 2026 und der Bereinigung durch npm eine der infizierten Paketversionen installiert oder aktualisiert haben. Das betrifft insbesondere:
npm install ausgeführt wurdeWenn Ihr Unternehmen selbst keine Software entwickelt, aber eine Website oder Anwendung von einer Agentur oder einem Dienstleister betreiben lässt, sollten Sie diesen umgehend fragen, ob und wie er betroffen ist. Denn viele Web-Projekte basieren im Hintergrund auf Node.js – und damit potenziell auf genau diesen Paketen.
Wenn Sie oder Ihr Team Zugriff auf den Quellcode haben, prüfen Sie in dieser Reihenfolge:
package-lock.json, yarn.lock oder pnpm-lock.yaml und suchen Sie nach den betroffenen Versionen – etwa keyv 6.0.0, flat-cache 6.1.24 oder file-entry-cache 11.1.6.setup.mjs, Math_Symbol.js oder math_init.js..vscode/tasks.json oder .claude/settings.json existieren, die einen Aufruf von setup.mjs enthalten.Falls Sie Anzeichen einer Infektion finden, gehen Sie strukturiert vor. Wichtig: Die Reihenfolge ist entscheidend – wegen des oben beschriebenen Dead-Man's-Switch dürfen Sie nicht einfach sofort alle Tokens widerrufen, sonst wird möglicherweise eine Löschroutine ausgelöst.
~/.local/bin/gh-token-monitor.sh), bevor Sie Zugangsdaten widerrufen.keyv@5.6.0). Die betroffenen Versionen wurden inzwischen größtenteils aus der npm-Registry entfernt.npm install --ignore-scripts, um die automatische Ausführung solcher preinstall-Hooks zu unterbinden.Die Sicherheitsfirma Wiz Research, die den Angriff aktiv untersucht, berichtet zudem, dass die Angreifer ihr Vorgehen im Verlauf anpassten: „The operator has provided a new RSA key, used to encrypt exfiltrated data.“ Das bedeutet: Es handelt sich nicht um einen einmaligen, abgeschlossenen Vorfall, sondern um eine aktive, sich weiterentwickelnde Kampagne. Bleiben Sie wachsam und verfolgen Sie Updates der genannten Sicherheitsanbieter.
Dieser Vorfall ist als kritisch einzustufen und wird aktiv ausgenutzt. Der Diebstahl von Cloud- und CI/CD-Zugangsdaten öffnet Angreifern potenziell die Tür zu Produktionssystemen und damit zu Kundendaten. Genau hier kommt der Datenschutz ins Spiel.
Nach Art. 33 DSGVO besteht eine Meldepflicht an die zuständige Aufsichtsbehörde binnen 72 Stunden, wenn durch den Diebstahl von Zugangsdaten – etwa Cloud-Keys oder Datenbank-Zugängen – ein Risiko für die Rechte und Freiheiten natürlicher Personen entsteht. Da die Malware gezielt Credentials ausliest, die Zugriff auf Kundendatenbanken ermöglichen können, ist im Ernstfall von einem hohen Risiko auszugehen. Das kann zusätzlich eine Benachrichtigung der betroffenen Personen nach Art. 34 DSGVO erforderlich machen.
Prüfen Sie also nicht nur die technische Seite, sondern dokumentieren Sie den Vorfall und bewerten Sie gemeinsam mit Ihrem Datenschutzbeauftragten, ob eine Meldepflicht besteht. Die 72-Stunden-Frist läuft ab dem Zeitpunkt, an dem Ihnen die Verletzung bekannt wird.
Zu beachten ist außerdem: Ab dem 11. September 2026 wird der Cyber Resilience Act (CRA) wirksam. Er verlangt bei aktiv ausgenutzten Schwachstellen in Produkten eine Erstmeldung binnen 24 Stunden. Für Unternehmen, die Software mit solchen Komponenten ausliefern, verschärfen sich die Meldepflichten damit noch weiter.
Der Shai-Hulud-Angriff zeigt eindrücklich, wie verwundbar moderne Software-Lieferketten sind. Ein einziger kompromittierter Entwickler-Account genügte, um innerhalb von vier Stunden über 430 Pakete mit zusammen mehr als 2 Milliarden monatlichen Downloads zu vergiften – und das mit gültigen Herkunftsnachweisen, an denen automatisierte Sicherheitsprüfungen wirkungslos abprallten.
Die Kernbotschaft für Sie als Unternehmen: Verlassen Sie sich nicht allein auf Signaturen und automatische Prüfungen. Wie es Moshe Siman Tov Bustan von OX Security formuliert, braucht es mehr als das bloße Blockieren von Installations-Skripten und Zwei-Faktor-Pflicht für Maintainer – nämlich eine granulare Kontrolle darüber, was ein Paket überhaupt darf.
Konkret heißt das für Sie: Klären Sie mit Ihrem Entwicklungsteam oder Dienstleister, ob Ihre Projekte betroffen sind, führen Sie die oben genannten Prüf- und Schutzschritte in der richtigen Reihenfolge durch, rotieren Sie im Zweifel alle Zugangsdaten und dokumentieren Sie den Vorfall im Hinblick auf Ihre DSGVO-Pflichten. Schnelligkeit und Sorgfalt sind hier gleichermaßen gefragt – dieser Wurm verbreitet sich von allein weiter.