SAP-Pakete werden zur Falle für Entwickler : „Mini Shai-Hulud“ stiehlt Zugangsdaten und missbraucht KI-Agenten
Ein Angriff auf SAP-nahe npm-Pakete offenbart die leichte Angreifbarkeit moderner Software-Lieferketten: Manipulierte Versionen griffen Entwicklerzugänge, Cloud-Geheimnisse und Repository-Daten ab – und nutzten erstmals auch Konfigurationen von KI-Coding-Agenten zur Ausbreitung.
Sicherheitsanalysten von Aikido Security, SafeDep, Socket, StepSecurity und Wiz warnen vor einer Supply-Chain-Kampagne gegen Pakete aus dem JavaScript- und Cloud-Entwicklungsumfeld von SAP. Die Kampagne nennt sich selbst „mini Shai-Hulud“ und erinnert laut Wiz in mehreren Merkmalen an frühere Operationen von TeamPCP. Veröffentlicht wurden die verdächtigen Versionen am 29. April 2026 zwischen 09:55 und 12:14 koordinierter Weltzeit.
Betroffen waren folgende Pakete:
- mbt@1.2.48
- @cap-js/db-service@2.10.1
- @cap-js/postgres@2.2.2
- @cap-js/sqlite@2.2.2
Schadcode startet schon bei der Installation
Der Angriff setzte nicht erst beim Ausführen einer Anwendung an, sondern bereits beim Installieren der Pakete. Die kompromittierten Versionen enthielten einen neuen „preinstall“-Hook in der Datei „package.json“. Dieser startete „setup.mjs“, einen Loader, der die JavaScript-Laufzeitumgebung Bun nachlud und anschließend das eigentliche Schadprogramm „execution.js“ ausführte.
Socket beschreibt den technischen Eingriff so: Die betroffenen Versionen hätten ein neues Verhalten während der Installation eingeführt, das zuvor nicht zur erwarteten Funktion dieser Pakete gehört habe. Der neue Preinstall-Code habe eine plattformspezifische Bun-Datei von GitHub Releases heruntergeladen, entpackt und sofort ausgeführt. Zusätzlich folgte die Implementierung Weiterleitungen, ohne das Ziel zu prüfen, und nutzte unter Windows PowerShell mit „ExecutionPolicy Bypass“. Das erhöhte besonders das Risiko für Entwicklerrechner und Build-Umgebungen.
Zugangsdaten als Hauptziel
Nach Angaben von Aikido war die Malware darauf ausgelegt, lokale Entwicklerzugänge, GitHub– und npm-Tokens, Geheimnisse aus GitHub Actions sowie Cloud-Zugangsdaten aus Amazon Web Services, Microsoft Azure, Google Cloud Platform und Kubernetes zu sammeln. Die gestohlenen Daten wurden verschlüsselt und in öffentlichen GitHub-Repositories abgelegt, die im Konto des Opfers erstellt wurden. Die Beschreibung lautete: „A Mini Shai-Hulud has Appeared“. Zum Zeitpunkt der Analyse existierten mehr als 1.200 solcher Repositories.
Die 11,6 Megabyte große Payload konnte sich zudem selbst weiterverbreiten. Sie nutzte gestohlene GitHub– und npm-Tokens, um bösartige GitHub-Actions-Workflows in erreichbare Repositories einzuschleusen, dort weitere Geheimnisse abzugreifen und manipulierte Paketversionen in die Registry zu veröffentlichen.
KI-Coding-Agenten als neuer Ausbreitungsweg
Gegenüber früheren Shai-Hulud-Wellen fallen mehrere Punkte auf:
- Alle abgegriffenen Daten werden mit AES-256-GCM verschlüsselt; der Schlüssel wird per RSA-4096 mit einem in der Payload eingebetteten öffentlichen Schlüssel gekapselt und ist damit praktisch nur für den Angreifer lesbar.
- Die Malware läuft auch auf Systemen mit russischer Spracheinstellung.
- Die Payload schreibt sich in jedes erreichbare GitHub-Repository, indem sie eine Datei „.claude/settings.json“ mit Missbrauch des SessionStart-Hooks von Claude Code und eine Datei „.vscode/tasks.json“ mit „runOn“: „folderOpen“ ablegt. Wird das infizierte Repository in Microsoft Visual Studio Code oder Claude Code geöffnet, kann die Malware erneut starten.
StepSecurity ordnet diesen Punkt als neue Qualität ein: „Dies ist einer der ersten Supply-Chain-Angriffe, der Konfigurationen von KI-Coding-Agenten als Persistenz- und Ausbreitungsvektor nutzt.“
OIDC falsch eingegrenzt
Die Ursachenanalyse zeigt, wie klein Konfigurationsfehler in Lieferketten sein können. Bei den drei „@cap-js“-Paketen wurde offenbar das Konto von RoshniNaveenaS kompromittiert. Danach brachten die Angreifer einen veränderten Workflow in einen Nicht-Hauptzweig ein und nutzten ein abgegriffenes npm-OpenID-Connect-Token, um die schädlichen Pakete ohne Herkunftsnachweis zu veröffentlichen.
SafeDep fasst die Schwachstelle in der Vertrauenskette präzise zusammen: Das Team sei im November 2025 auf vertrauenswürdiges Veröffentlichen per npm OpenID Connect umgestiegen. Dadurch könnten GitHub Actions kurzlebige npm-Tokens anfordern, ohne langlebige Geheimnisse im Repository zu speichern. Der Angreifer habe diesen Austausch jedoch manuell in einem Integrationsschritt nachgestellt und das resultierende Token ausgegeben. Das kritische Konfigurationsproblem: Die npm-Konfiguration vertraute jedem Workflow im Repository, nicht nur dem vorgesehenen Release-Workflow im Hauptzweig.
Die Betreuer haben inzwischen sichere Versionen veröffentlicht:
Der Fall zeigt: Paketinstallationen sind längst ein Hochrisikomoment. Unternehmen müssen Build-Systeme isolieren, Tokens strikt begrenzen, OpenID-Connect-Publisher auf konkrete Workflows und Hauptzweige einschränken, Paketversionen prüfen und Entwicklerumgebungen auf versteckte Startmechanismen in Microsoft Visual Studio Code und KI-Agenten kontrollieren.