Das npm-Paket tensorlake ist über die manipulierte Version 0.5.144 zum Träger des Credential-Stealing-Wurms Shai-Hulud geworden. Die Schadsoftware sammelte Zugangsdaten, übertrug Secrets, richtete Persistenz ein und konnte weiteren Code von einem externen Server ausführen. Die betroffene Version wurde inzwischen aus dem npm-Register entfernt; die Maintainer haben den Quellcode zurückgesetzt und Version 0.5.145 als korrigierte Ausgabe veröffentlicht.
Das ist keine lediglich theoretisch ausnutzbare Schwachstelle. Die bösartige Ausgabe wurde tatsächlich aus dem Tensorlake-Repository veröffentlicht und über npm verteilt. Betroffen sind Systeme, auf denen 0.5.144 installiert und deren Installationsskript ausgeführt wurde. Wer durch eine Sperrdatei bei der als sauber geltenden Version 0.5.143 geblieben ist, fällt nicht allein aufgrund der Paketabhängigkeit in diese Gruppe.
Wie viele Installationen die kompromittierte Version erreichte, ist bislang nicht belegt. Das Paket kam zuletzt auf mehr als 12.000 wöchentliche und etwa 106.000 monatliche Downloads. Diese Werte beschreiben jedoch die allgemeine Nutzung und dürfen nicht mit der Zahl infizierter Systeme gleichgesetzt werden.
Ein Preinstall-Hook öffnete die Entwicklerumgebung
Tensorlake ist ein TypeScript-SDK für Tensorlake-Anwendungen, Sandboxes und Cloud-Dienste. Die manipulierte Version enthielt einen Preinstall-Hook, der zunächst die Datei package/lib/setup.mjs startete. Dieser verschleierte Loader führte anschließend über die Bun-Laufzeit den eigentlichen Wurm in package/lib/Math_Symbol.js aus.
Angriffskette von tensorlake 0.5.144
Die Grafik zeigt den Weg von der Installation der kompromittierten Paketversion über den Preinstall-Hook bis zu Datendiebstahl, Persistenz und Weiterverbreitung.
Damit lag die entscheidende Angriffsvoraussetzung im normalen Paketmanagement: 0.5.144 musste in einer Umgebung installiert werden, in der npm-Skripte ausgeführt werden durften. Die Malware lief dann mit den Rechten des jeweiligen Prozesses. Auf einem isolierten Testsystem ist der erreichbare Datenbestand entsprechend kleiner als auf einer Entwickler-Workstation oder einem CI-Runner, der Zugriff auf Veröffentlichungs-Tokens, Cloud-Konten und Produktionsinfrastruktur besitzt.
Nach Analysen von Socket suchte der Wurm unter anderem nach npm- und GitHub-Tokens, AWS-Zugangsdaten, SSH-Schlüsseln, .env-Dateien, Kubernetes-Konfigurationen sowie Zugangsdaten für HashiCorp Vault. Hinzu kamen Kryptowallets, Daten aus Messaging-Anwendungen und Konfigurationsdateien für Anthropic Claude, Cursor, Kiro, Windsurf und Zed. Außerdem setzte die Malware das Werkzeug HackBrowserData ein.
Für den Vorfall gibt es keine angegebene CVE oder CVSS-Bewertung. Das ist folgerichtig: Im Mittelpunkt steht kein gewöhnlicher Programmierfehler im SDK, sondern eine tatsächlich veröffentlichte, absichtlich schädliche Paketversion.
Der Wurm nutzte gestohlene Identitäten zur Weiterverbreitung
Shai-Hulud beschränkte sich nicht auf das Auslesen lokaler Daten. Der Wurm ermittelte Pakete, die mit der Veröffentlichungsidentität des Opfers verbunden waren, erzeugte Sigstore-Provenienz und veröffentlichte seinerseits kompromittierte Versionen. Hinweise auf gefälschte Copilot- und Dependabot-Abläufe sprechen zudem dafür, dass er GitHub-Actions-Workflows in erreichbaren Repositories platzierte.
StepSecurity zufolge landeten die bösartigen Dateien unter dem Namen eines Maintainers im Hauptzweig von tensorlakeai/tensorlake. Der erste manipulierte Commit erfolgte am 7. Oktober 2026 um 01:20 Uhr UTC. Einen Tag später veröffentlichte der Release-Workflow Version 0.5.144 auf npm. Aus den vorliegenden Angaben lässt sich jedoch nicht abschließend ableiten, welcher konkrete Zugangspunkt zuerst kompromittiert wurde.
Zur Persistenz schrieb die Malware außerdem Dateien nach .claude/settings.json und .vscode/tasks.json in erreichbare Repositories. Dadurch konnte sie erneut starten, sobald ein Projekt in Claude Code oder Visual Studio Code geöffnet wurde. Das Entfernen des npm-Pakets beendet diese Ausführungskette daher nicht zwingend.
Der Command-and-Control-Endpunkt iseekaigogo[.]com wurde über einen Ethereum-Smart-Contract aufgelöst. Als Ausweichweg konnte GitHub dienen: Dort legte die Malware verschlüsselte, gestohlene Daten in einem öffentlichen Repository ab.
Der Token-Widerruf kann selbst zur Falle werden
Besonders relevant für die Incident Response ist eine Komponente namens gh-token-monitor. Sie fragte mit dem gestohlenen GitHub-Token wiederholt die Schnittstelle api.github.com/user ab. Wurde der Token widerrufen, konnte der Monitor über PowerShell vom Angreifer gelieferten Code ausführen. Den vorliegenden Analysen zufolge gehört dazu eine destruktive Routine, die das Home-Verzeichnis des betroffenen Benutzers löscht.
Die übliche Sofortreaktion – gestohlene Tokens unverzüglich zu sperren – braucht deshalb eine kontrollierte Reihenfolge. Ein betroffenes System sollte zuerst vom Netz getrennt und der Monitor auf dem isolierten Host neutralisiert werden. Erst danach sollten die Zugangsdaten von einem sauberen System aus widerrufen und ersetzt werden. Das ist kein Argument für Verzögerungen, sondern gegen einen unkoordinierten Widerruf auf einer noch aktiven, kompromittierten Maschine.
Gültige Provenienz belegt nicht die Unversehrtheit des Quellcodes
Der Vorfall legt eine Grenze von Build-Provenienz offen. Eine gültige Attestierung kann belegen, aus welchem Repository und über welchen Workflow ein Paket gebaut wurde. Wenn aber bereits der Quellcode im Repository oder der veröffentlichende Workflow manipuliert ist, dokumentiert die Provenienz lediglich einen formal nachvollziehbaren Weg für schädlichen Code.
Das ist bei diesem Angriff operativ wichtiger als die bloße Frage, ob npm eine Signatur oder Herkunftsinformation anzeigt. Der Wurm konnte selbst Sigstore-Provenienz für weiterverbreitete Pakete erzeugen. Vertrauenswürdig ist die Kette daher nur, wenn auch Repository-Zugriffe, Commits, Workflow-Änderungen und Maintainer-Identitäten kontrolliert werden.
Ein Versionswechsel allein bereinigt keine Infektion
Organisationen sollten zunächst in Lockfiles, Build-Protokollen, npm-Caches und Artefakten prüfen, ob tensorlake@0.5.144 tatsächlich aufgelöst und installiert wurde. Auch kurzlebige CI-Runner sind relevant, wenn ihre Tokens oder erzeugten Artefakte weiterverwendet wurden.
Bei bestätigter Installation ist das System als vollständig kompromittiert zu behandeln. Nach der Isolation müssen der Token-Monitor sowie die Persistenz über Claude- und VS-Code-Konfigurationen untersucht werden. Anschließend sind sämtliche für den Prozess erreichbaren Secrets von einem sauberen Gerät aus zu rotieren. Dazu gehören insbesondere npm- und GitHub-Tokens, Cloud-Zugänge, Vault- und Kubernetes-Zugangsdaten, SSH-Schlüssel und Inhalte aus Umgebungsdateien. Veröffentlichte Pakete, GitHub-Actions-Workflows und Repository-Änderungen der betroffenen Identitäten sollten ebenfalls kontrolliert werden.
Version 0.5.145 ersetzt die manipulierte Ausgabe; 0.5.143 gilt ebenfalls als sauber. Das Update beseitigt aber weder bereits kopierte Zugangsdaten noch angelegte Persistenz. Der praktische Schaden hängt deshalb nicht nur davon ab, ob das Paket installiert wurde, sondern vor allem davon, welche Berechtigungen die jeweilige Entwicklungs- oder CI-Umgebung dem Installationsprozess zugänglich gemacht hat.
Jens analysiert seit Jahren digitale Märkte, Preisbewegungen und Plattform-Strategien. Als Betreiber mehrerer datengetriebener Systeme wertet er täglich große Mengen an Produkt- und Trenddaten aus. Sein Fokus liegt auf Einordnung statt Hype: Was bedeutet eine Entwicklung wirklich für Nutzer, Preise und Märkte?
