Es gibt wohl eine neue Shai Hulud-Angriffskampagne auf npm-Pakete. Nach dem Hack eines Entwicklerkontos sind wohl schon über 800 npm-Pakete mit Millionen Downloads kompromittiert. Die Information ist mir zum 4. August 2026 auf der Plattform X untergekommen. Ergänzung: Informationen des JFrog Security Research Teams ergänzt.
Laut diesem Tweet wurden durch den aktuellen Supply-Chain-Angriff auf die npm-Lieferkette mindestens 868 Pakete mit monatlich über 2 Milliarden Installationen durch einen Wurm kompromittiert, der Anmeldedaten stiehlt. Shai-Hulud ist zurück, schreibt der Autor des Tweets.
Auslöser war die Kompromittierung des GitHub-Kontos des Betreuers von "keyv", einer Bibliothek mit rund 127 Millionen wöchentlichen npm-Downloads. Bei einem "npm install"-Befehl wird ein Preinstall-Hook ausgelöst, der einen Stealer ablegt, der Geheimnisse aus npm, GitHub, AWS, Kubernetes und Vault abgreift und sich anschließend auf weitere Maintainer ausbreitet. Die Kollegen von Bleeping Computer haben einige Informationen in diesem Artikel zusammen getragen.
Einschätzung vom JFrog Security Research Team
Ergänzung: Nach Veröffentlichung des obigen Texts hat mich das JFrog Security Research Team kontaktiert und einige Details mitgeteilt. Demnach hat das Security Research Team von JFrog hat eine neue Variante der Schadsoftware Shai-Hulud identifiziert. Diese verbreitet sich über die npm-Registry und hat bereits mehr als 400 Pakete in über 1.700 Versionen infiziert.
Ausgangspunkt waren die weit verbreiteten Caching-Bibliotheken keyv und cacheable. Da keyv als transitive Abhängigkeit in zahlreichen gängigen Werkzeugen steckt und sich der Wurm eigenständig weiterverbreitet, wächst die Zahl der betroffenen Pakete fortlaufend. Wer eine kompromittierte Version installiert hat, sollte die eigene Umgebung als kompromittiert betrachten. Die Untersuchung dauert an. JFrog aktualisiert die Analyse mit jedem neu bestätigten Paket.
Was ist genau passiert?
Die aktuelle Welle begann mit der Kompromittierung der Pakete keyv und cacheable sowie der zugehörigen @cacheable-Paketfamilie. Anders als bei einem klassischen, auf feste Pakete beschränkten Angriff ist die Verbreitung nicht an eine feste Liste gebunden. Ein einziger gestohlener npm-Token mit breiter Schreibberechtigung genügt, um jedes Paket des betroffenen Herausgebers zur nächsten Angriffswelle zu machen.
Der Name Shai-Hulud verweist auf die riesigen Sandwürmer aus Frank Herberts Romanzyklus Dune. Die Variante identifiziert sich selbst über die von ihr angelegten GitHub-Repositorys, deren Beschreibung "Shai-Hulud: Here We Go Again" lautet.
Technischer Hintergrund
Angriffe dieser Art funktionieren, weil moderne Software aus vielen quelloffenen Bausteinen zusammengesetzt ist. Eine einzige manipulierte Bibliothek kann sich über verschachtelte Abhängigkeiten in eine Vielzahl von Projekten ausbreiten, ohne dass die betroffenen Teams dies bemerken. Genau hier wird die Bedeutung von keyv deutlich, das als transitive Abhängigkeit in vielen gängigen Werkzeugen steckt.
Die von den Forschern analysierte Variante verfolgt vier miteinander verbundene Ziele: Sie sammelt Zugangsdaten aus lokalen Umgebungen, CI-Systemen, Cloud-Diensten, Kubernetes und Vault. Die verschlüsselten Ergebnisse exfiltriert sie über einen dynamischen HTTPS-Endpunkt oder eigens angelegte öffentliche GitHub-Repositories. Mit gestohlenen npm-Zugangsdaten veröffentlicht sie infizierte Patch-Versionen jedes beschreibbaren Pakets. Schließlich nutzt sie GitHub-Zugangsdaten sowie GitHub Actions, um weitere Repositorys zu infizieren und zusätzliche Zugangsdaten abzugreifen.
Besonders kritisch ist die Verankerung in Entwicklungsumgebungen. Der Wurm hinterlegt Dateien in erreichbaren GitHub-Branches, sodass bereits das Öffnen eines infizierten Repositorys in VS Code oder der Start einer Claude-Sitzung darin genügt, um den Schadcode auszuführen.
Was JFrog bislang bestätigt
Betroffener Ausgangspunkt. Die weit verbreiteten Caching-Bibliotheken keyv und cacheable sowie die @cacheable-Paketfamilie wurden manipuliert.
Wachsendes Ausmaß. Betroffen sind bereits über 400 Pakete in mehr als 1.700 Versionen, mit fortlaufend steigender Tendenz.
Diebstahl und Weitergabe von Zugangsdaten. Die Malware sammelt Geheimnisse aus lokalen Systemen, CI, Cloud, Kubernetes und Vault und nutzt gestohlene Token zur automatisierten Weiterverbreitung.
Risiko in Entwicklungsumgebungen. Das Öffnen eines infizierten Repositorys in VS Code oder der Start einer Claude-Sitzung reicht zur Ausführung des Schadcodes.
Schutz bei npm 12 und neuer. Ab npm 12 werden preinstall-Lifecycle-Hooks standardmäßig nicht mehr ausgeführt. In diesen Umgebungen wird das System durch diesen Verbreitungsweg nicht infiziert.
Laufende Untersuchung. Die Liste der betroffenen Pakete und Versionen wird fortlaufend aktualisiert.
Einordnung durch das JFrog Security Research Team
Shai-Hulud steht exemplarisch für eine neue Generation von Angriffen auf die Software-Lieferkette, die nicht mehr auf einzelne Ziele beschränkt bleiben, sondern sich automatisiert im Ökosystem ausbreiten. Für Unternehmen unterstreicht der Vorfall, wie wichtig Lückenlosigkeit in der eigenen Software-Lieferkette ist, von der Kontrolle eingesetzter Abhängigkeiten bis zur schnellen Rotation potenziell offengelegter Zugangsdaten. JFrog empfiehlt betroffenen Anwendern, kompromittierte Systeme nicht zu bereinigen, sondern aus sauberen Images neu aufzusetzen und sämtliche erreichbaren Zugangsdaten zu widerrufen und zu erneuern.
Die vollständige Untersuchung und alle Updates zu dieser Shai-Hulud-Variante veröffentlicht das JFrog Security Research Team fortlaufend hier.
MVP: 2013 – 2016
Hier mal der link vom Entdecker
https://www.stepsecurity.io/blog/chaindrop-npm-worm
Eine Offene Software ist halt nicht immer gut.
Gab ja schon mehrere solcher angriffe.
Hat eben alles seine vor und nachteile.
Schwachsinn!
Es muss immer einen Maintainer des Repos die Änderungen freigeben (so meine Infos) oder dieser wurde bereits anders kompromittiert. Also liegt es eher am Maintainer des Repos.
Das hat nix mit Open-Source zu tun!
Ihr beide könntet "richtig liegen" – nur führen beide Einstellungen mE standalone ohne Konsens nicht weiter. "Stop baiting", please.
Ich mag OSS. Auch OSS hat jedoch Vor- und Nachteile. Dabei wäre @DBProgger's "Software […] nicht immer gut" zu präzisieren. Dune – Shai Hulud,"the building of a Dynasty".
Das Problem bei NPM ist vor allem, dass Microsoft als verantwortlicher Entwickler (NPM gehört zu GitHub, was – genau wie Edge, Bing und Copilot – zur CoreAI-Division gehört) nur sehr langsam reagiert. Die jüngste Version 12.0 ist einen wesentlichen Teilaspekt der aktuellen Problematik angegangen, aber da ist noch einiges offen.
Andererseits ist das auch etwas sinnbildlich für den Gesamtzustand der Developer-Divisions bei Microsoft, wie sie momentan sind:
– Die NPM-Angriffe mit Mini-Shai-Hulud und Miasma konnten wir recherchetechnisch mindestens bis September 2025 zurückverfolgen, Microsoft kriegt das also seit gut einem Jahr nicht in den Griff.
– GitHub hat das ganze Jahr über Negativschlagzeilen gemacht mit fehlender Stabilität und Zuverlässigkeit, massiven Sicherheitsproblemen und, wie Tim Warren von TheVerge damals recherchiert hatte, auch einem chaotischen Führungsstil unter Jay Parikh, der selbst nicht sonderlich beliebt sein soll. Und das, obwohl sie mit Microsoft-Größen wie Scott Hanselman verstärkt wurden und dann trotzdem auch in Blogposts halbe Durchhalteparolen aussenden.
– Zwischenzeitlich gabs dann auch die Angriffe auf Sicherheitsforscher, was im Grunde die beleidigte Leberwurst gegenüber der Community aus dem letzten Jahr fortgesetzt hat, wo hochrangige Manager wie Mustafa Suleyman mit Worten wie Zyniker um sich geschmissen haben.
– In der Developer Division selbst, wo .NET, Visual Studio und Co. untergebracht sind, sollen führende Manager links und rechts zurücktreten und Reorganisationen teilweise auf wöchentlicher Basis stattfinden, sodass auch einzelne Projekte nicht mehr konstant und zuverlässig betreut werden. Auch die teaminterne Kommunikation über mehrere Ebene wurde eingeschränkt. Das hatte Jeff Fritz in einem seiner Streams vor gut zwei Wochen berichtet, nachdem er Microsoft Mitte Juli verlassen hatte, und er war nicht nur Teil des .NET-Teams, sondern auch Produzent von Events von der .NET Conf und Teilen von Großevents wie BUILD und Ignite.
– Auch bei .NET ist bei weitem nicht alles in Ordnung. Spannungen, wo sich führende Community-Mitglieder wie Nick Chapsas und Tim Corey geäußert haben, gab es schon das ganze Jahr, und kürzlich kam eben raus, dass Microsoft schon seit letztem Jahr kein Interesse mehr an der .NET Conf hat und sie dieses Jahr nicht mehr unterstützen will, sodass die Community laut Fritz mittlerweile darauf vorbereitet ist, den Weg ohne Microsoft in die Zukunft zu gehen. Sieht man auch an den Open Source-Projekte, wo einige von der technischen Basis her komplett neu geschrieben werden oder vor allem in erster Linie mit AvaloniaUI auf eine plattformübergreifende Lösung innerhalb von .NET umgestellt werden. Das betrifft auch Projekte wie Open Live Writer, wo sich teilweise noch aktive Microsoft-Entwickler innerhalb der .NET Foundation seit Monaten an der Portierung beteiligen, auch wenn OLW vor allem von einem aktuell portiert wird.
Microsoft hat vor allem das Thema, dass es sich, wenn es nicht das XBOX-Team, Windows-Team oder ganz vereinzelte Open Source-Projekte wie die PowerToys betrifft, massiv abgeschottet hat und weiter abschottet. An die Leute aus der Developer Division oder auch das Edge-Team kommt man eigentlich nicht mehr ran (Ausnahme wäre in erster Linie noch WinUI, weil das Windows-Team da mit involviert ist und die auch den direkten Kontakt suchen). Aber ansonsten ist das echt schwer geworden, das war für uns und andere (internationale) Kollegen früher wesentlich einfacher.
868 Pakete? So wenig? Ist doch wohl ein Witz, oder? Bei Socket werden über 2300 Pakete gelistet. npm darf man eigentlich nicht mehr verwenden, das Risiko ist untragbar.
Beim AUR von Arch gab es übrigens inzwischen die 2. oder 3. Welle der Infektionen mit Malware. Ist immer wieder überraschend zu sehen, wie giftig Linuxer werden können, wenn sowas in ihrem kleinen Software-Biotop passiert.
Wenn ich es richtig sehe, hat Arch doch die AUR-Pakete deaktiviert – siehe meinen Kurznachtrag in 400+ Arch Linux AUR Pakete in Lieferkettenangriff kompromittiert, oder habe ich was verpeilt?
Nein aber Linux ist doch sicher! Auch wenn man eine Shell in der eine su Session läuft fernsteuern kann in dem man einfach über ioctrl Tastendrücke simuliert…
Im deutschen Arch-Linux-Forum gibt es unter dem Strang "Sperrung der AUR Paketübernahme" 3 Links, die zeigen sollen, dass es wohl eine weitere Welle von Versuchen gab, Malware in AUR-Pakete zu bringen. Die Links poste ich hier nicht, aber die Titel der Artikel sind:
"Arch Linux Disables AUR Package Takeovers as Attackers Push Malicious Commits" (vom 1. August 2026)
"Arch Linux AUR Under Another Wave Of Malicious Packages, Package Adoptions Halted" (vom 31. July 2026)
"Arch Linux User Repository (AUR) ist erneuten Angriffen ausgesetzt" (vom 3. August 2026)
Mit dieser Schreibweise erreicht Borncity folgernd auch die Response von Jfrog :-) Das erhöht Treffer und Klicks. Super. Aber – öhöm, grml & nerv – könnten wir für Nerds und Dune Fans den Titel final so echt korrigieren?? Überlasse es Dir, mehr Reichweite gab es schon jetzt:
Shaid Hulud = Shai Hulud, oder Shai-Hulud
So schnell tippende GB hätt ich gern als Schwiegerpapa. Cheers, Norddeutsch.
[ Bitte diesen Pedanten löschen ]
Bei mir ist diesbezüglich Hopfen und Malz verloren…