Shai-Hulud infiziert Tensorlake-SDK auf npm

Die Tensorlake-SDK-Version 0.5.144 enthielt den Zugangsdaten stehlenden Wurm Shai-Hulud. Obwohl die Schadsoftware nach 11 Minuten erkannt wurde, ist die Zahl der betroffenen Systeme unbekannt.

Shai-Hulud infiziert Tensorlake-SDK auf npmBild: KI-generiert

Schadcode im Tensorlake-SDK

Die npm-Version 0.5.144 des Tensorlake-SDKs wurde mit einer Variante des Wurms Shai-Hulud infiziert. Die als ChainDrop bekannte Schadsoftware stiehlt Zugangsdaten und kann sich über kompromittierte Konten weiterverbreiten.

Tensorlake ist eine Cloud-Native-Plattform für die isolierte Ausführung von KI-Agenten und nicht vertrauenswürdigem oder KI-generiertem Code. Das betroffene SDK dient dazu, entsprechende Umgebungen zu erstellen und zu verwalten.

Das npm-Paket kommt auf ungefähr 12.000 Downloads pro Woche. Das zugehörige GitHub-Repository hat mehr als 1.000 Sterne. Wie viele Systeme die infizierte Version tatsächlich heruntergeladen und ausgeführt haben, ist bislang nicht bekannt.

KennzahlAngabe
Infizierte Version0.5.144
Bereinigte Version0.5.145
Erkennung nach Veröffentlichung11 Minuten
Ungefähre Downloads pro Woche12.000
GitHub-SterneÜber 1.000

Die Sandbox schützt den Installationsprozess nicht

Der kritische Punkt liegt außerhalb der eigentlichen Tensorlake-Sandbox. Das schadhafte Installationsskript läuft auf einer Entwickler-Workstation, einem Anwendungsserver oder einem Build-Runner. Dort übernimmt es die Rechte des Prozesses, der die Installation ausführt.

Sinngemäß erklärte die Sicherheitsfirma Socket: Teams isolieren zwar den von Agenten erzeugten Code, installieren das SDK aber häufig auf Systemen mit Zugriff auf Deployment-Zugangsdaten und andere Geheimnisse. Während der Installation ausgeführter Code erbt die Berechtigungen des installierenden Prozesses.

Damit greift die Schadsoftware an, bevor die Schutzmechanismen für den KI-Agenten überhaupt wirksam werden. Konzepte wie isolierte Cloud-Sandboxes für KI-Agenten bleiben sinnvoll, decken aber nur eine Schicht der gesamten Lieferkette ab.

Welche Daten Shai-Hulud entwendet

Die Malware sucht unter anderem nach Krypto-Wallets, gespeicherten Browser-Passwörtern, GitHub-Actions-Secrets, Cloud-Zugangsdaten und Service-Account-Tokens. Anschließend überträgt sie die gefundenen Informationen an Command-and-Control-Server, über die Angreifer weitere Befehle erteilen können.

ZielMögliches Risiko
GitHub-Actions-SecretsZugriff auf Build-, Veröffentlichungs- und Deployment-Prozesse
Cloud-ZugangsdatenZugriff auf Infrastruktur, Daten und kostenpflichtige Ressourcen
Service-Account-TokensMaschineller Zugriff auf interne Dienste und Schnittstellen
Browser-PasswörterÜbernahme weiterer Benutzerkonten
Krypto-WalletsVerlust digitaler Vermögenswerte

Besonders problematisch ist eine Funktion zur Überwachung gestohlener GitHub-Tokens. Wird ein kompromittiertes Token widerrufen, kann die Schadsoftware unter bestimmten Bedingungen das Home-Verzeichnis des betroffenen Nutzers löschen. Das erschwert eine unkoordinierte Bereinigung.

Die gleiche Shai-Hulud-Variante wurde bereits im August bei Angriffen auf die npm-Pakete keyv und flat-cache eingesetzt. Auf welchem Weg die Angreifer die manipulierte Tensorlake-Version veröffentlichen konnten, ist nicht bekannt.

Infizierte Version wurde entfernt

Socket erkannte das schadhafte Paket 11 Minuten nach seiner Veröffentlichung. Version 0.5.144 wurde anschließend aus der npm-Registry entfernt. Tensorlake veröffentlichte mit Version 0.5.145 eine bereinigte Ausgabe.

Die kurze Erkennungszeit erlaubt keine belastbare Aussage über den Umfang des Vorfalls. Automatisierte Build-Prozesse können neue Pakete unmittelbar nach ihrer Veröffentlichung beziehen. Ob dies bei der infizierten Tensorlake-Version geschehen ist, muss jedes betroffene Unternehmen anhand eigener Protokolle und Abhängigkeitsdateien prüfen.

Konsequenzen für eigene KI-Infrastruktur

Für Unternehmen im DACH-Raum gibt es keinen Hinweis auf eine gezielte regionale Kampagne. Relevant ist der Vorfall dennoch für alle Organisationen, die eigene KI-Agenten entwickeln, Self-Hosting betreiben oder externe SDKs in CI/CD-Pipelines einbinden.

Dependency-Pinning, also das feste Festschreiben geprüfter Paketversionen, reduziert das Risiko unbemerkter Aktualisierungen. Build-Umgebungen sollten isoliert sein und nur minimale Berechtigungen erhalten. CI/CD-Secrets gehören zudem auf einzelne Aufgaben, Repositorys und kurze Laufzeiten begrenzt.

Auch Schnittstellen zwischen Agenten und internen Systemen benötigen eine eigene Sicherheitsprüfung. Die bereits bekannten MCP-Sicherheitslücken in internen KI-Agenten zeigen, dass Sandbox, Werkzeugzugriff und Software-Lieferkette getrennt betrachtet werden müssen.

Vorgehen bei möglicher Installation

Unternehmen sollten zunächst feststellen, ob Version 0.5.144 heruntergeladen und tatsächlich ausgeführt wurde. Betroffene Rechner oder Build-Runner sind als kompromittiert zu behandeln. Empfohlen wird ein Neuaufbau aus einer vertrauenswürdigen Quelle, bevor der Zugriff auf erneuerte Zugangsdaten wiederhergestellt wird.

Vor dem Widerruf betroffener GitHub-Tokens muss die schädliche Überwachungsfunktion neutralisiert sein, da sonst eine Löschung des Home-Verzeichnisses ausgelöst werden kann. Anschließend sollten alle potenziell erreichbaren Geheimnisse erneuert werden, nicht nur die unmittelbar für Tensorlake verwendeten Zugangsdaten.

Der Fall relativiert die Annahme, dass eine isolierte Agentenlaufzeit automatisch die gesamte KI-Infrastruktur absichert. Eigenentwicklung und Self-Hosting können Abhängigkeiten von SaaS-Anbietern verringern. Sie verlagern jedoch Verantwortung auf Paketprüfung, Build-Sicherheit, Rechteverwaltung und eine belastbare Reaktion auf kompromittierte Abhängigkeiten.