Mini Shai-Hulud: npm-Wurm frisst die Lieferkette
7 Min. Lesezeit
Am 11. Mai 2026 meldet Microsoft Security Research eine neue Welle des npm-Wurms Shai-Hulud: 170 betroffene npm-Pakete und zwei PyPI-Pakete, verteilt über 404 bösartige Paketversionen. Es ist die erste koordinierte Kampagne, die npm und PyPI gleichzeitig trifft. Bemerkenswert ist nicht die Zahl, sondern die Bauart. Mini Shai-Hulud stiehlt Zugangsdaten und verbreitet sich darüber hinaus selbst weiter, über genau die vertrauenswürdigen Veröffentlichungswege, die moderne Software-Lieferketten zusammenhalten.
Das Wichtigste in Kürze
- Der Wurm propagiert sich selbst: Gestohlene OIDC- und Publishing-Rechte erzeugen neue bösartige Releases unter echten Maintainer-Identitäten, ganz ohne neuen Phishing-Zugang.
- Persistenz jenseits des Pakets: Der Schadcode nistet sich teils in Entwickler-Konfigurationen ein und bleibt aktiv, auch nachdem das infizierte Paket entfernt wurde.
- Tokens sind das Einfallstor: Wer auf npm Trusted Publishing und WebAuthn statt auf langlebige Tokens setzt, schließt den wichtigsten Verbreitungsweg.
Verwandt:Die Splunk-Lücke ohne Login / Maschinen-Identitäten im Offboarding
Eine zweite Welle, größer und koordinierter
Shai-Hulud ist kein neuer Name. Im Zeitraum vom 24. November bis zum 1. Dezember 2025 hatte die erste Welle hunderte npm-Pakete kompromittiert, darunter Komponenten aus den Ökosystemen von Zapier, PostHog, Postman, ENS Domains und AsyncAPI. Die Variante, die Microsoft Anfang Mai 2026 dokumentiert, trägt den Namen Mini Shai-Hulud und geht einen Schritt weiter. Sie trifft mit TanStack, Mistral AI, UiPath, OpenSearch und AntV erneut prominente Projekte und überspannt erstmals beide großen Registries.
Die 404 bösartigen Versionen sind die Zahl der manipulierten Paketstände, verteilt über die 170 npm- und zwei PyPI-Pakete. Mit HTTP-Fehlern hat die Zahl nichts zu tun. Für Security-Teams verschiebt das die Suche: weg vom einzelnen faulen Paket, hin zu einer Kette von Veröffentlichungen, die sich gegenseitig nähren.
Die Mechanik: preinstall läuft vor jedem Test
Der Angriff beginnt an der schwächsten Stelle des Installationsvorgangs. Ein bösartiges preinstall-Skript in der package.json wird automatisch beim Installieren ausgeführt, bevor Tests oder Sicherheitsprüfungen greifen. Dieses Zeitfenster ist der Hebel. In ihm installiert ein Setup-Skript namens set_bun.js bei Bedarf die alternative JavaScript-Runtime Bun und führt darüber den eigentlichen Payload aus der Datei bun_environment.js aus.
Was dann passiert, ist eine systematische Ernte. Der Schadcode lädt einen GitHub-Actions-Runner nach und setzt den Credential-Scanner TruffleHog ein, um Secrets aus Repositorys und Umgebungsvariablen zu ziehen. Die Beute geht an Repositorys unter Kontrolle der Angreifer. Gestohlen werden weit mehr als npm-Tokens: AWS-SSO- und IMDS-v2-Zugänge, Azure-, Google-Cloud- und Kubernetes-Anmeldedaten, SSH-Schlüssel, lokale Konfigurationsgeheimnisse und sogar Krypto-Wallets.
Warum der Wurm überlebt, wenn das Paket längst weg ist
Der eigentliche Sprung gegenüber klassischen Supply-Chain-Angriffen liegt in der Verbreitung. Mini Shai-Hulud nutzt die gestohlenen OIDC- und Publishing-Rechte, um neue bösartige Releases unter den Identitäten echter Maintainer zu veröffentlichen. Über GitHub Trusted Publishing und npm-Lifecycle-Skripte trägt sich der Angriff so durch die vertrauenswürdigen Freigabewege weiter, ohne dass die Angreifer erneut jemanden phishen müssten.
Noch unangenehmer ist die Persistenz. Laut Microsoft verankert sich der Schadcode teils über SessionStart-Hooks in der Datei .claude/settings.json und über die GitHub-GraphQL-Schnittstelle. Damit lebt der Angriff in der Entwicklerumgebung weiter, nicht nur in der Abhängigkeit. Wer das infizierte Paket entfernt und glaubt, fertig zu sein, übersieht den Mechanismus, der bei jedem nächsten Start des Werkzeugs erneut feuert.
Die neue Angriffsfläche: KI-Dev-Tools und alternative Runtimes
Genau hier liegt die Lehre, die über diesen einen Vorfall hinausreicht. Der Wurm bedient sich über klassische npm-Skripte hinaus einer alternativen Runtime mit Bun und der Hook-Dateien moderner KI-Coding-Werkzeuge, eines Persistenzmechanismus, den herkömmliche Audits selten im Blick haben. Eine SBOM listet Abhängigkeiten, sie listet keine Hook-Konfigurationen im Entwickler-Setup.
Für die Incident Response heißt das, den Scope zu erweitern. Wer eine Supply-Chain-Kompromittierung untersucht, muss künftig auch die Konfigurationsdateien von KI-Assistenten, lokale Hook-Dateien und Nicht-Node-Runtimes prüfen. Das ist keine KI-Panik. Es ist die nüchterne Feststellung, dass die CI/CD-Angriffsfläche um Werkzeuge gewachsen ist, die vor zwei Jahren noch nicht auf jedem Entwicklerrechner liefen.
Abwehr: Tokens ersetzen, Identität härten, Pipeline signieren
Die gute Nachricht ist, dass die wirksamsten Maßnahmen Prinzipien sind, keine Produkte. Microsoft und mehrere Sicherheitsfirmen wie Akamai, Snyk und StepSecurity, die parallel zur Kampagne berichteten, kommen zu einem konsistenten Kern. Maintainer sollten npm Trusted Publishing statt langlebiger Tokens nutzen, denn ein gestohlener Token ist der Treibstoff der Selbstverbreitung. Eine WebAuthn-basierte Zwei-Faktor-Authentifizierung schützt besser als TOTP, das sich abphishen lässt. Und Commit-Signaturen machen untergeschobene Releases sichtbar.
Auf der Anwenderseite zählt Tempo. Wer betroffen sein könnte, rotiert exponierte Zugangsdaten sofort, statt zu warten. Eine automatisierte SBOM-Erstellung und agentenloses Scanning helfen, die manipulierten Versionen überhaupt zu erkennen. Regeln zur Angriffsflächenreduktion können obfuskierte Skripte blocken, bevor sie laufen. Für deutsche Unternehmen kommt eine rechtliche Ebene hinzu. NIS2 macht die Sorgfaltspflicht in der Lieferkette zu einer nachweisbaren Anforderung. Ein Vorfall wie dieser ist damit ein technisches und ein Dokumentationsthema zugleich.
Häufige Fragen
Was ist Mini Shai-Hulud?
Mini Shai-Hulud ist eine Variante des npm-Wurms Shai-Hulud aus dem Jahr 2025. Die von Microsoft am 11. Mai 2026 dokumentierte Welle kompromittierte 170 npm- und zwei PyPI-Pakete über 404 bösartige Versionen und verbreitet sich selbstständig über die Veröffentlichungswege der Software-Lieferkette.
Wie infiziert der Wurm ein System?
Über ein bösartiges preinstall-Skript, das beim Installieren eines Pakets automatisch und vor allen Tests ausgeführt wird. Es installiert die Bun-Runtime, lädt einen Payload nach und scannt mit TruffleHog nach Zugangsdaten, die anschließend an die Angreifer abfließen.
Warum reicht es nicht, das infizierte Paket zu löschen?
Weil der Schadcode sich teils außerhalb der Abhängigkeit verankert, etwa über SessionStart-Hooks in der Konfiguration von KI-Coding-Werkzeugen und über die GitHub-GraphQL-Schnittstelle. Diese Persistenz feuert bei jedem Start des Werkzeugs erneut, auch wenn das Paket längst entfernt ist.
Welche Zugangsdaten sind betroffen?
Gestohlen werden npm-Tokens, AWS-SSO- und IMDS-v2-Zugänge, Anmeldedaten für Azure, Google Cloud und Kubernetes, SSH-Schlüssel, lokale Konfigurationsgeheimnisse und Krypto-Wallets. Wer eine Kompromittierung vermutet, sollte exponierte Zugangsdaten sofort rotieren.
Was bedeutet der Vorfall für die NIS2-Pflichten?
NIS2 verlangt eine nachweisbare Sorgfaltspflicht in der Lieferkette. Ein Supply-Chain-Vorfall dieser Art berührt damit über die technische Abwehr hinaus die Dokumentations- und Meldepflichten betroffener Unternehmen.
Lesetipps der Redaktion
SecurityTodayAb wann die Meldefrist-Uhr wirklich ticktSecurityTodayProtective DNS: der Layer, den viele übersehenSecurityTodayKRITIS-Dachgesetz: Wenn Resilienz zur CISO-Pflicht wirdMehr aus dem MBF Media Netzwerk
Schatten-KI im Mittelstand: Was die heimliche Nutzung verrät
Quelle Titelbild: Pexels / Pachon in Motion (px:30547598)
