Microsoft Threat Intelligence hat Details zu einem weitreichenden Angriff auf die npm-Lieferkette veröffentlicht, der mehr als 400 Pakete betraf, die scheinbar nicht miteinander verbundenen Herausgebern zugeordnet waren. Dazu gehörten Pakete aus unternehmensbezogenen Softwareökosystemen wie keyv, flat-cache und cache-manager. Die schädlichen Versionen enthielten eine Variante des Mini-Shai-Hulud-Wurms, eine stark verschleierte, auf JavaScript und Bun basierende Payload, die zum Diebstahl von Zugangsdaten und zur automatischen Verbreitung durch die erneute Veröffentlichung schädlicher Updates entwickelt wurde.
Besonders relevant ist die Funktionsweise dieses Angriffs: Die Schadsoftware stiehlt nicht nur Token von einem Entwicklergerät oder aus einer Build-Umgebung, sondern nutzt diese Token auch, um auf npm, GitHub, Amazon Web Services, Kubernetes und HashiCorp Vault zuzugreifen und die von den gestohlenen Identitäten zugelassenen Ressourcen und Geheimnisse zu untersuchen. Laut der am 4. August 2026 veröffentlichten Analyse von Microsoft sollte jede Workstation oder jeder Build-Runner, der ein betroffenes Paket importiert und dabei npm-Lebenszyklus-Skripte aktiviert hat, als potenziell kompromittiert betrachtet werden.
Frühe Ausführung in Entwicklungsumgebungen
Den betroffenen Versionen wurde üblicherweise ein preinstall-Skript hinzugefügt, das vor dem vollständigen Abschluss der Paketinstallation eine Datei namens setup.mjs ausführt. Die Datei startet ein großes, verschleiertes Bun-Paket und ermöglicht so die Ausführung der Payload auf Entwicklergeräten und Build-Knoten, bevor Anwendungstests beginnen oder einige herkömmliche Sicherheitsprüfungen diese Phase erreichen.
Der Wurm untersucht zunächst die Umgebung, um festzustellen, ob er auf einer Entwickler-Workstation oder in einem CI/CD-Job ausgeführt wird. Auf Entwicklergeräten trennt er sich vom ursprünglichen Prozess, um nach Abschluss der Installation im Hintergrund weiterzulaufen. In CI/CD-Umgebungen bleibt er dagegen mit dem Job verbunden, um Workflow-Geheimnisse, Runner-Zugangsdaten und Berechtigungen für die Veröffentlichung über OpenID Connect zu nutzen. Außerdem prüft er, ob bereits eine andere Instanz ausgeführt wird, und beendet sich auf Systemen mit russischer Sprache, wie Microsoft beobachtet hat.
Diebstahl von Zugangsdaten und deren Umwandlung in Verbreitung
Die Payload beginnt damit, lokal verfügbare Zugangsdaten aus Dateien, Umgebungsvariablen und der Befehlshistorie sowie SSH-Schlüssel und Cloud-Tools zu sammeln. Zusätzlich erfasst sie Daten aus dem Speicher von GitHub-Actions-Runnern. Unter anderem versucht sie, ein GitHub-CLI-Token zu erlangen. Anschließend verwendet sie die extrahierten Zugangsdaten, um die APIs von npm, GitHub, AWS, Kubernetes und HashiCorp Vault aufzurufen, Berechtigungen zu überprüfen und weitere Geheimnisse zu sammeln.
Die Ergebnisse werden als komprimiertes JSON mit AES-256-GCM verschlüsselt; der AES-Schlüssel wird zusätzlich per RSA-OAEP-SHA256 verschlüsselt. Anschließend werden die Daten an einen vom Angreifer kontrollierten HTTPS-Endpunkt gesendet. GitHub dient als alternativer Kanal zur Datenexfiltration, wenn der primäre Kanal nicht verfügbar ist. Microsoft zufolge löste die zum Zeitpunkt der Analyse aktive Infrastruktur die Domain npm-cache[.]com auf; frühere Kandidaten waren pypi-get[.]com und js-mirror[.]com.
Der wichtigste Verbreitungsmechanismus besteht darin, npm-Token daraufhin zu prüfen, ob sie Schreibzugriff auf Pakete oder eine Umgehung der Zwei-Faktor-Authentifizierung ermöglichen. Danach lädt der Wurm für jedes für die kompromittierte Identität verfügbare Paket die aktuellste Tarball-Datei herunter. Er kopiert sich selbst in das Archiv, fügt den Setup-Loader und das Lebenszyklus-Skript hinzu, erhöht die Patch-Versionsnummer und veröffentlicht das Paket erneut. Das erklärt, warum schädliche Versionen als gewöhnliche Patch-Updates erscheinen können, ohne dass im Quellrepository ein entsprechender Commit, Pull Request oder passender Release-Tag vorhanden ist.
Zusätzliche Wege über GitHub
Die Payload überprüft die Geltungsbereiche von GitHub-Token, zählt beschreibbare Repositorys und sucht nach Repositorys, in denen Workflows weitere Geheimnisse offenlegen könnten. Außerdem enthält sie einen Pfad, der npm-Pakete angreift, die über GitHub Actions veröffentlicht werden und als vertrauenswürdige Herausgeber gelten. Dadurch können veröffentlichte Versionen eine gültige Provenance erhalten, da die Veröffentlichung von einer legitimen Workflow-Identität stammt.
Der Wurm kann außerdem Konfigurationsdateien in Repository-Zweige einschleusen, darunter Pfade im Zusammenhang mit Claude und Visual Studio Code wie .claude/settings.json, .claude/setup.mjs, .vscode/tasks.json und .vscode/setup.mjs. Diese Änderungen schaffen einen sekundären Infektionsweg, der die Payload während der Nutzung von Claude oder Visual Studio Code erneut ausführen kann, selbst nachdem die Installation des ursprünglichen Pakets abgeschlossen ist. Microsoft zufolge versucht einer der GitHub-Notfallpfade außerdem, eine Komponente zur Überwachung von Token zu installieren, einschließlich eines bedingten Sabotage-Handlers für den Fall, dass das überwachte Token widerrufen wird.
Was empfiehlt Microsoft?
Microsoft empfiehlt, die npm CLI auf Version 12 zu aktualisieren und die Funktion min-release-age zu verwenden. Außerdem sollten Abhängigkeitsbäume, Lockfiles, Artefakt-Repositories und CI-Caches auf die fünf betroffenen Versionen überprüft werden, einschließlich indirekter Verweise. Es sollten bekannte sichere Versionen installiert sowie npm- und yarn-Caches auf Entwicklergeräten und Build-Hosts geleert werden, insbesondere wenn kompromittierte Archive in einen gemeinsamen CI-Cache gelangt sind.
Wenn ein Build-System oder eine Workstation eine betroffene Version importiert hat, müssen Zugangsdaten und Geheimnisse von einem sauberen Gerät aus rotiert werden, da die Ausführung der zweiten Phase Token offenlegen und die Integrität des Build-Prozesses beeinträchtigen kann. Zu den Empfehlungen gehören außerdem die Aktivierung des Cloud-Schutzes für Microsoft Defender Antivirus, Messungen mit Microsoft Defender for Endpoint und Microsoft Defender for Containers sowie die Nutzung des Untersuchungs-Workflows in Microsoft Defender XDR für Entwicklungs- und CI-Ressourcen.
Die Reaktion darf sich nicht auf die Überprüfung der Geräte beschränken. Organisationen, die Softwareartefakte erzeugen, sollten die Absicherung ihres Release-Prozesses, Token-Geltungsbereiche, Workflow-Genehmigungen, geschützte Umgebungen, Release-Provenance und Mechanismen zur Erkennung ungewöhnlicher automatisierter Veröffentlichungen überprüfen, da der Vorfall mit dem Missbrauch von CI/CD-Pipelines über die OIDC-Berechtigungen von GitHub Actions übereinstimmt. Nach der Bereinigung sollten Projekte aus einer vertrauenswürdigen Ausgangsbasis neu erstellt, das Fehlen kompromittierter Artefakte in Caches und Artefakt-Repositories überprüft und Messungen auf Node.js-Reste wie Math_Symbol.js und Math_init.js oder Dateien mit Namen ähnlich math_<guid>.js untersucht werden. Außerdem sollten Basis-Images und modulare Build-Runner neu erstellt werden.