Was ist da eigentlich passiert?

Stellen Sie sich vor, Sie kaufen im Supermarkt eine Packung Müsli von einer Marke, der Sie vertrauen. Was Sie nicht wissen: Jemand hat heimlich in der Fabrik ein paar Zutaten ausgetauscht. Das Müsli sieht normal aus, schmeckt normal, aber es enthält etwas, das da nicht hingehört.

Genau das ist Ende November 2025 im JavaScript-Ökosystem passiert. Ein Schadprogramm namens Shai-Hulud 2.0 hat sich in über 796 beliebte npm-Pakete eingeschlichen. Diese Pakete werden zusammen mehr als 20 Millionen Mal pro Woche heruntergeladen. Das bedeutet: Unzählige Entwickler haben sich unwissentlich einen digitalen Schädling auf ihre Rechner geholt.

Der Name "Shai-Hulud" stammt übrigens aus dem Science-Fiction-Roman "Dune" und bezeichnet dort riesige Sandwürmer. Ein passender Name, denn dieser Wurm gräbt sich durch das gesamte npm-Ökosystem.

Wie funktioniert der Wurm? Eine Schritt-für-Schritt-Erklärung

Der Einstiegspunkt: Das Preinstall-Script

Wenn Sie ein npm-Paket installieren, können verschiedene Skripte automatisch ausgeführt werden. Eines davon ist das sogenannte "Preinstall-Script", es läuft, bevor das eigentliche Paket installiert wird.

Denken Sie an einen Einbrecher, der nicht durch die Haustür kommt, sondern durch ein Kellerfenster einsteigt, noch bevor die Alarmanlage scharf geschaltet ist. Genau so funktioniert Shai-Hulud 2.0: Der Schadcode wird ausgeführt, bevor die meisten Sicherheitsprogramme überhaupt aktiv werden.

Der Wurm fügt zwei Dateien in infizierte Pakete ein:

• setup_bun.js – diese Datei bereitet alles vor
• bun_environment.js – hier steckt der eigentliche Schadcode

Warum Bun? Ein cleverer Trick

Hier wird es interessant: Der Wurm installiert eine alternative JavaScript-Laufzeitumgebung namens "Bun". Warum? Weil die meisten Sicherheitsprogramme auf Node.js ausgerichtet sind.

Ein Vergleich aus dem Alltag: Wenn die Polizei nach einem roten Auto sucht, fährt der Dieb einfach mit einem blauen. Die meisten Überwachungstools schauen auf Node.js-Prozesse und Bun rutscht einfach unter dem Radar durch.

Was der Wurm auf Ihrem Rechner macht

Sobald der Wurm aktiv ist, beginnt er systematisch nach wertvollen Informationen zu suchen. Er durchforstet Ihren Computer wie ein Einbrecher, der alle Schubladen durchwühlt:

Lokale Dateien durchsuchen: Der Wurm kennt die üblichen Verstecke für Zugangsdaten. Er schaut in Ordner wie ~/.aws/ (Amazon Web Services), ~/.azure/ (Microsoft Azure) und ~/.npmrc (npm-Konfiguration). Das sind die Orte, wo Entwickler typischerweise ihre Zugangsdaten speichern.

Cloud-Dienste anzapfen: Besonders clever: Der Wurm fragt die sogenannten "Metadata Services" von Cloud-Anbietern ab. Das sind interne Dienste, die Cloud-Anwendungen Informationen über sich selbst geben. Stellen Sie sich vor, Sie rufen bei einer Bank an und die geben Ihnen einfach alle Kontodaten, weil Sie so tun, als wären Sie ein legitimer Mitarbeiter.

Secret-Stores plündern: Viele Unternehmen speichern ihre Geheimnisse in speziellen Tresoren wie AWS Secrets Manager oder Azure Key Vault. Der Wurm versucht auch dort einzubrechen.

TruffleHog einsetzen: Ironischerweise nutzt der Wurm ein Tool, das eigentlich für Sicherheitsprüfungen gedacht ist. TruffleHog sucht normalerweise nach versehentlich veröffentlichten Passwörtern und hier wird es zum Werkzeug der Angreifer.

Wie verbreitet sich der Wurm weiter?

Die GitHub-Methode

Gestohlene Daten müssen irgendwo hin. Shai-Hulud 2.0 nutzt dafür einen überraschenden Weg: öffentliche GitHub-Repositories. Der Wurm erstellt neue Repositories mit der Beschreibung "Sha1-Hulud: The Second Coming" und lädt dort die erbeuteten Zugangsdaten hoch.

Das ist wie ein Dieb, der seine Beute nicht in einem Versteck lagert, sondern einfach auf einen öffentlichen Parkplatz stellt und nur dass er weiß, wo er suchen muss, und andere es für Müll halten.

Automatische Weiterverbreitung

Das wirklich Gefährliche an Shai-Hulud 2.0 ist seine Fähigkeit zur Selbstvermehrung. Wenn der Wurm npm-Zugangsdaten auf Ihrem Rechner findet, nutzt er diese, um bis zu 100 weitere Pakete zu infizieren und das sind die Pakete, die Sie veröffentlicht haben.

Stellen Sie sich einen Virus vor, der nicht nur Sie krank macht, sondern auch automatisch Briefe an alle Ihre Kontakte verschickt, die den gleichen Virus enthalten. Genau so funktioniert dieser Wurm.

Die erste Version von Shai-Hulud konnte nur 20 Pakete infizieren. Version 2.0 hat dieses Limit auf 100 erhöht, d.h. der Wurm ist also fünfmal ansteckender geworden.

Eine besonders fiese Eigenschaft

Es gibt noch einen besonders unangenehmen Trick: Die "Cross-Victim-Exfiltration". Der Wurm speichert Ihre gestohlenen Daten nicht in Repositories, die mit Ihrem Namen verbunden sind. Stattdessen landen Ihre Geheimnisse in Repositories anderer Opfer.

Das bedeutet: Selbst wenn Sie Ihre eigenen GitHub-Repositories durchsuchen, finden Sie möglicherweise keine Hinweise darauf, dass Ihre Daten gestohlen wurden.

Wer ist betroffen?

Die Liste der kompromittierten Pakete liest sich wie ein Who's Who des JavaScript-Ökosystems:

• Zapier – beliebte Automatisierungsplattform
• ENS Domains – wichtig für Blockchain-Anwendungen
• PostHog – Analytics-Tool
• Postman – API-Entwicklungswerkzeug
• AsyncAPI – Dokumentations-Framework

Insgesamt wurden die Daten von über 500 GitHub-Nutzern gestohlen, die zu mehr als 150 verschiedenen Organisationen gehören. Auf dem Höhepunkt des Angriffs erschienen etwa 1.000 neue kompromittierte Repositories alle 30 Minuten.

Welche Arten von Zugangsdaten wurden gestohlen?

Eine Analyse der gestohlenen Daten zeigt folgendes Bild:

• 79,9% waren Zugangsdaten für SaaS-Dienste wie Jira, Slack oder Datadog
• 15,6% waren Git-Tokens für GitHub, GitLab oder Bitbucket
• 3,0% waren CI/CD-Tokens für automatisierte Deployments
• 1,4% waren Cloud-Zugangsdaten für AWS, Azure oder Google Cloud
• 0,2% waren KI-Zugangsdaten für OpenAI, Amazon Bedrock oder Claude

Die letzte Kategorie mag klein erscheinen, ist aber besonders brisant: Eines der kompromittierten Zapier-Pakete wird für KI-Integrationen verwendet.

Was passiert, wenn der Wurm keine Zugangsdaten findet?

Hier zeigt Shai-Hulud 2.0 sein wahres Gesicht: Wenn der Wurm keine verwertbaren GitHub- oder npm-Zugangsdaten findet, löscht er einfach Ihr Home-Verzeichnis. Alle Ihre Dateien sind dann weg.

Das ist wie ein Einbrecher, der sagt: "Wenn ich nichts Wertvolles finde, zünde ich das Haus an." Diese destruktive Komponente ist neu in Version 2.0 und zeigt, wie aggressiv die Angreifer geworden sind.

Wie ist das überhaupt passiert?

Der Ursprung: Nicht rotierte Tokens

Die Geschichte beginnt eigentlich schon früher. Im August 2025 gab es einen Angriff namens "s1ngularity", bei dem Zugangsdaten gestohlen wurden. Das Problem: Nach diesem Vorfall wurden die betroffenen Tokens nicht alle gewechselt.

Stellen Sie sich vor, jemand hat Ihren Hausschlüssel kopiert. Sie wissen davon, aber Sie tauschen das Schloss nicht aus. Natürlich kommt der Dieb wieder und zwar mit dem gleichen Schlüssel.

GitHub Actions als Einfallstor

Eine zentrale Rolle spielten GitHub Actions, das sind automatisierte Workflows, die Code testen, bauen und veröffentlichen. Die Angreifer nutzten diese Systeme, um Geheimnisse aus Repositories zu stehlen und an sich selbst zu schicken.

Das Perfide: Diese automatisierten Systeme haben oft weitreichende Berechtigungen, weil sie ja im Namen der Entwickler arbeiten sollen. Diese Berechtigungen wurden missbraucht.

Wie kann ich mich schützen?

Sofortmaßnahmen

1. Pakete prüfen Schauen Sie in Ihre package.json und package-lock.json. Suchen Sie nach den Dateien setup_bun.js oder bun_environment.js. Wenn Sie diese finden, haben Sie ein Problem.

2. Tokens rotieren Wenn Sie npm- oder GitHub-Tokens verwenden, wechseln Sie diese jetzt. Nicht morgen, nicht nächste Woche – jetzt.

3. Repositories überprüfen Suchen Sie in Ihren GitHub-Repositories nach Branches mit dem Namen "shai-hulud" oder nach Workflows mit verdächtigen Triggern.

Langfristige Schutzmaßnahmen

Trusted Publishing nutzen

npm bietet mittlerweile "Trusted Publishing" an. Statt langlebiger Tokens, die gestohlen werden können, werden hier kurzlebige Tokens verwendet, die nur für eine spezifische Aktion gültig sind.

Das ist wie der Unterschied zwischen einem Generalschlüssel (den jemand kopieren kann) und einem Einmalcode (der nach Verwendung ungültig wird).

Wartezeit für neue Pakete

Paketmanager wie pnpm und yarn bieten die Option, neue Paketversionen erst nach einer Wartezeit zu installieren. Elastic nutzt beispielsweise eine 14-Tage-Regel: Neue Versionen werden erst nach zwei Wochen automatisch übernommen.

Das gibt der Community Zeit, verdächtige Pakete zu entdecken, bevor sie sich überall verbreiten.

Keine Zugangsdaten im Code

Das klingt selbstverständlich, passiert aber ständig: Zugangsdaten werden direkt im Code oder in Konfigurationsdateien gespeichert. Nutzen Sie stattdessen sichere Secret-Management-Systeme.

Abhängigkeiten minimieren

Jedes npm-Paket, das Sie installieren, kann weitere Pakete mitbringen. Je mehr Pakete, desto größer die Angriffsfläche. Fragen Sie sich bei jeder Abhängigkeit: Brauche ich das wirklich?

Wie erkennen Sicherheitstools solche Angriffe?

Das Problem mit einfachen Warnungen

Ein einzelner Alarm ist oft nicht aussagekräftig. "Programm X hat eine Netzwerkverbindung hergestellt", das machen tausende Programme ständig. Die Kunst liegt darin, Muster zu erkennen.

Sicherheitstools wie Datadog Workload Protection nutzen sogenannte "Execution Contexts". Sie schauen sich nicht einzelne Aktionen an, sondern den gesamten Ablauf: Wurde TruffleHog im Kontext einer npm-Installation ausgeführt? Das ist verdächtig. Wurde es von einem Sicherheitsteam gestartet? Das ist normal.

Erkennungsregeln für Shai-Hulud 2.0

Sicherheitsfirmen haben spezifische Regeln für diesen Wurm veröffentlicht. Diese suchen nach Mustern wie:

• Curl oder Wget, die von Node.js-Prozessen gestartet werden
• TruffleHog-Ausführungen
• Zugriffe auf Browser-Credentials
• Ungewöhnliche Netzwerkverbindungen zu bekannten Exfiltrations-Diensten

Was können wir aus dem Vorfall lernen?

Vertrauen ist gut, Kontrolle ist besser

Das npm-Ökosystem basiert auf Vertrauen. Wir vertrauen darauf, dass Pakete das tun, was sie versprechen. Shai-Hulud 2.0 zeigt, dass dieses Vertrauen missbraucht werden kann.

Das bedeutet nicht, dass wir aufhören sollten, npm zu nutzen. Aber wir sollten bewusster damit umgehen, so wie wir auch nicht jeden E-Mail-Anhang öffnen.

Automatisierung braucht Grenzen

CI/CD-Pipelines sind fantastisch, um Routineaufgaben zu automatisieren. Aber sie brauchen klare Grenzen. Welche Berechtigungen hat ein Workflow wirklich nötig? Je weniger, desto besser.

Nach einem Vorfall aufräumen

Der vielleicht wichtigste Punkt: Nach dem s1ngularity-Angriff wurden Tokens nicht konsequent gewechselt. Diese Nachlässigkeit hat Shai-Hulud 2.0 erst möglich gemacht.

Wenn Sie von einem Sicherheitsvorfall erfahren, egal wie klein er scheint, rotieren Sie alle betroffenen Zugangsdaten. Sofort.

Fazit: Der Wurm wird wiederkommen

Shai-Hulud 2.0 ist wahrscheinlich nicht das Ende. Die Angreifer haben gezeigt, dass ihre Methoden funktionieren. Wir können weitere Varianten und Nachahmer erwarten.

Die gute Nachricht: Die Community reagiert. npm führt neue Sicherheitsfunktionen ein, Paketmanager bieten bessere Schutzmechanismen, und Sicherheitsforscher teilen ihr Wissen öffentlich.

Am Ende liegt es an jedem einzelnen Entwickler: Halten Sie Ihre Zugangsdaten sicher, prüfen Sie Ihre Abhängigkeiten und bleiben Sie wachsam. Der nächste Wurm kommt bestimmt.

Häufig gestellte Fragen

Wie finde ich heraus, ob ich betroffen bin?

Am einfachsten geht das über die öffentlichen Indicator-of-Compromise-Listen, die von Sicherheitsfirmen wie Datadog und Wiz bereitgestellt werden. Sie können Ihre installierten Pakete gegen diese Listen prüfen. Schauen Sie außerdem nach verdächtigen Dateien wie setup_bun.js oder bun_environment.js in Ihren node_modules. Einige Anbieter wie Entro Security haben auch Online-Tools veröffentlicht, bei denen Sie prüfen können, ob Ihre GitHub-Daten in den kompromittierten Repositories aufgetaucht sind.

Ich habe ein betroffenes Paket installiert – was soll ich jetzt tun?

Zunächst: Keine Panik, aber handeln Sie schnell. Rotieren Sie alle Zugangsdaten, die auf dem betroffenen System gespeichert waren – npm-Tokens, GitHub-Tokens, Cloud-Credentials, alles. Prüfen Sie Ihre GitHub-Repositories auf verdächtige Branches oder Workflows. Scannen Sie Ihr System nach den bekannten Schadcode-Dateien. Und informieren Sie Ihr Team, falls Sie in einem Unternehmen arbeiten. Je schneller Sie handeln, desto geringer der potenzielle Schaden.

Warum nutzt der Wurm GitHub für die Datenexfiltration statt eines eigenen Servers?

Das ist tatsächlich ziemlich clever. Verbindungen zu GitHub sehen in den meisten Unternehmensnetzen völlig normal aus – Entwickler kommunizieren ja ständig mit GitHub. Ein eigener Server würde viel eher auffallen. Außerdem ist GitHub sehr zuverlässig und schnell. Und selbst wenn einzelne Repositories entdeckt und gelöscht werden, können die Angreifer einfach neue erstellen. Es ist wie ein Briefkasten, zu dem nur der Dieb den Schlüssel hat – er steht mitten in der Stadt, aber niemand schöpft Verdacht.