Shai-Hulud und die npm-Supply-Chain-Krise 2026

Wenn du an einem Dienstag 2026 npm install ausgeführt hast, hast du vielleicht die Malware von jemand anderem ausgeliefert. Das ist keine Übertreibung. Zwischen September 2025 und Juni 2026 wandelte sich die npm-Registry vom gelegentlichen Typosquatting-Ärgernis zur Bühne für den ersten echten selbstreplizierenden Wurm, den das JavaScript-Ökosystem je gesehen hat. Die npm-Supply-Chain-Krise 2026 ist die Geschichte davon, wie Angreifer aufhörten, einzelne Entwickler zu phishen, und begannen, das Vertrauen zu bewaffnen, das ein Paket still und leise dreihundert andere mitziehen lässt.

Hier ist, was tatsächlich passierte, wen es traf und die konkreten Schritte, die verhindern, dass deine Pipeline zum nächsten Verbreitungsknoten wird.

Der Wurm, der sich selbst veröffentlicht: Shai-Hulud

Das prägende Ereignis war Shai-Hulud, benannt nach dem Sandwurm aus Frank Herberts Dune. Laut Unit 42 von Palo Alto Networks startete die erste Welle am 15. September 2025 und gilt als der erste echte selbstreplizierende Wurm im npm-Ökosystem.

Die Mechanik ist in ihrer Einfachheit fies. Der Wurm wird während der Installation über die Lifecycle-Skripte des Pakets ausgeführt, sammelt Anmeldedaten vom Host und nutzt dann gestohlene npm-Publish-Tokens, um die anderen Pakete des Opfer-Maintainers mit derselben bösartigen Payload neu zu veröffentlichen. Unit 42 stellte fest, dass er rund die Top-20-Pakete eines Opfers aufzählen und neu veröffentlichen würde, was eine Kaskade erzeugt. Sysdig und andere verfolgten die ursprüngliche Welle auf rund 200 infizierte Pakete, darunter weit verbreitete Bibliotheken wie @ctrl/tinycolor und ngx-bootstrap.

Damit hörte es nicht auf. Die Kampagnenfamilie entwickelte sich durch drei dokumentierte Wellen:

• Original (September 2025): ~200 Pakete, Anmeldedaten-Sammlung plus die Auto-Publish-Schleife.
• Shai-Hulud 2.0 (November 2025): Unit 42 meldete, dass die Payload zur Pre-Install-Ausführung wechselte, was bedeutete, dass sie auf praktisch jedem Build-Server lief, der ein infiziertes Paket verarbeitete, nicht nur auf Entwickler-Laptops.
• Mini Shai-Hulud (Ende April 2026): Erstmals um den 29. April 2026 offengelegt, traf diese Welle zum ersten Mal npm und PyPI gleichzeitig. Die Cloud Security Alliance und Securonix verfolgten sie über rund 172 Pakete und 404 bösartige Versionen, wobei die infizierten Pakete zusammen Hunderte Millionen Mal pro Woche heruntergeladen wurden.

Die Mini-Shai-Hulud-Variante fügte einen erschreckenden neuen Trick hinzu: Persistenz über Konfigurationsdateien von KI-Coding-Agenten, einschließlich Claude Code und VS-Code-Einstellungen. Der Wurm verstand, dass moderne Entwickler in KI-Tooling leben, und pflanzte sich dort ein.

Axios: wenn 100 Mio. wöchentliche Downloads außer Kontrolle geraten

Würmer sind beängstigend, weil sie skalieren. Gezielte Kompromittierungen von Vorzeige-Paketen sind beängstigend wegen des Radius des Schadens. Am 30. März 2026 wurde Axios — der beliebteste HTTP-Client im JavaScript-Ökosystem mit über 100 Millionen wöchentlichen npm-Downloads — kompromittiert und in ein Auslieferungsfahrzeug für einen plattformübergreifenden Remote-Access-Trojaner (RAT) verwandelt.

Microsoft Threat Intelligence schrieb die Axios-Kompromittierung und ihre unterstützende Infrastruktur Sapphire Sleet zu, einem nordkoreanischen staatsnahen Akteur. Wenn eine Abhängigkeit, die unter einem bedeutenden Teil aller Node.js-Anwendungen sitzt, mit einer Hintertür versehen wird, lautet die Frage nicht mehr "sind wir betroffen?", sondern "wie schnell können wir es herausfinden?".

Die Lehre aus Axios: Beliebtheit ist keine Sicherheit. Ein Paket mit neunstelligen wöchentlichen Downloads ist ein attraktiveres Ziel, kein risikoärmeres, gerade weil so viel nachgelagerte Software ihm implizit vertraut.

Red Hat, OIDC und der blinde Fleck in CI/CD

Der lehrreichste Vorfall 2026 ist vielleicht der kleinste im Umfang. Am 1.–2. Juni 2026 kompromittierten Angreifer mindestens 32 Pakete, die unter dem npm-Namespace @redhat-cloud-services veröffentlicht waren — 96 Versionen insgesamt, laut Aikido Security, mit über 116.000 kumulierten Downloads.

Was diesen Fall wichtig macht, ist das Wie. Laut Cybersecurity Dive und Wiz wurden die bösartigen Versionen über GitHub Actions OIDC veröffentlicht, nicht über gestohlene npm-Anmeldedaten. Ein kompromittiertes GitHub-Konto schob unautorisierte Commits in Repositories der RedHatInsights-Organisation, und die CI-Pipeline veröffentlichte das Ergebnis pflichtbewusst. Die Payload war eine Variante von Mini Shai-Hulud — ein Anmeldedaten-stehlender Wurm, der CI-Secrets, Cloud-Anmeldedaten, SSH-Schlüssel und npm-Tokens jagt.

Red Hat erklärte, der bösartige Code sei nie für die Kundennutzung veröffentlicht worden und habe nur interne Entwicklungspakete betroffen. Doch die Erkenntnis ist universell: Wenn deine CI/CD-Identität veröffentlichen kann, dann reicht es, deine CI/CD-Identität zu kompromittieren. Die npm-Supply-Chain-Angriffe 2026 umgehen zunehmend den menschlichen Maintainer komplett und zielen direkt auf die Automatisierung, die in seinem Namen veröffentlicht.

Warum das so schnell so schlimm wurde

Drei strukturelle Realitäten verwandelten isolierte Vorfälle in eine systemische Krise:

• Transitives Vertrauen. Ein typisches Node-Projekt hat Tausende transitiver Abhängigkeiten. Du prüfst deine direkten Abhängigkeiten; deren Abhängigkeiten prüfst du fast nie.
• Lifecycle-Skripte. preinstall- und postinstall-Hooks führen standardmäßig beliebigen Code während der Installation aus. Das ist das Ausführungs-Primitiv, auf das sich jeder dieser Würmer stützte.
• Tokens überall. Langlebige npm-Publish-Tokens und weitreichende Cloud-Anmeldedaten, die in CI-Umgebungen liegen, sind genau das, wofür Anmeldedaten-stehlende Würmer gebaut sind — und dann zur Verbreitung wiederverwendet werden.

So schützt du deine Pipeline jetzt

Du kannst nicht jede transitive Abhängigkeit von Hand auditieren. Du kannst die Angriffsfläche dramatisch verkleinern mit Kontrollen, die direkt auf die Funktionsweise dieser Angriffe abbilden.

Beende die Code-Ausführung zur Installationszeit

• Führe npm install --ignore-scripts in der CI standardmäßig aus und setze die wenigen Pakete auf eine Allowlist, die wirklich Build-Skripte brauchen.
• Setze ignore-scripts=true in deiner Projekt-.npmrc, damit der Standard sicher ist.

Sperre und verifiziere, was du installierst

• Committe deine Lockfile und nutze npm ci, nicht npm install, in automatisierten Builds, damit Versionen exakt gepinnt sind.
• Aktiviere npms --foreground-scripts und überprüfe Pakete, die aus unerwarteten Registries aufgelöst werden (der klassische Dependency-Confusion-Vektor, auf den Microsoft im Mai 2026 hinwies).
• Füge eine Abkühlphase hinzu: vermeide automatisches Upgraden auf Versionen, die in den letzten 24–72 Stunden veröffentlicht wurden, dem Zeitfenster, in dem die meisten dieser bösartigen Versionen entdeckt und zurückgezogen werden.

Behandle CI-Anmeldedaten als die Kronjuwelen

• Ersetze langlebige npm-Publish-Tokens durch kurzlebige, gescopte Tokens und aktiviere npms Trusted Publishing / Provenance, damit Pakete gegen ihren Quell-Build signiert werden.
• Scope GitHub Actions OIDC auf bestimmte Repositories und Umgebungen; der Red-Hat-Fall zeigt, dass zu breite Publish-Identitäten das neue weiche Ziel sind.
• Rotiere alle AWS-Schlüssel, HashiCorp-Vault-Tokens und SSH-Schlüssel, die Build-Runnern ausgesetzt sind, und bevorzuge Just-in-Time-Secrets gegenüber statischen.

Behalte dein KI-Tooling im Auge

Mini Shai-Huluds Persistenz über Claude-Code- und VS-Code-Konfigurationsdateien bedeutet, dass dein Editor und deine Agent-Einstellungen jetzt Teil der Angriffsfläche sind. Halte diese Konfigurationen in der Versionskontrolle, damit unerwartete Änderungen in einem Diff sichtbar werden.

Das Fazit

Die npm-Supply-Chain-Krise 2026 machte eines unbestreitbar: Die Registry ist Infrastruktur, und Infrastruktur wird angegriffen. Shai-Hulud bewies, dass ein Wurm sich von Maintainer zu Maintainer ohne menschliche Hilfe verbreiten kann, Axios bewies, dass die vertrauenswürdigsten Pakete die wertvollsten Ziele sind, und die Red-Hat-OIDC-Kompromittierung bewies, dass Angreifer den Entwickler überspringen und direkt auf den Roboter zielen, der veröffentlicht. Keine der obigen Abwehrmaßnahmen ist exotisch — Install-Skripte deaktivieren, mit npm ci pinnen und langlebige Tokens durch Provenance-gestütztes Publishing ersetzen hätte jede hier beschriebene Welle abgestumpft. Die Teams, die 2026 unversehrt durchkamen, hatten kein Glück. Sie hörten einfach auf, npm install standardmäßig zu vertrauen.

FAQ

Ist Shai-Hulud 2026 noch aktiv? Die Kampagnenfamilie entwickelte sich durch mindestens drei Wellen bis Mitte 2026, mit Mini Shai-Hulud aktiv ab Ende April 2026 und verwandter Aktivität (wie der Red-Hat-Kompromittierung) im Juni. Behandle es als anhaltendes Bedrohungsmuster, nicht als abgeschlossenen Vorfall.

Fängt npm audit diese Angriffe ab? Nicht zuverlässig in Echtzeit. npm audit kennzeichnet bekannte Schwachstellen, nachdem sie katalogisiert sind. Frisch veröffentlichte bösartige Versionen können sich Stunden vor der Offenlegung verbreiten, weshalb Kontrollen zur Installationszeit und Versions-Abkühlphasen wichtiger sind als Audit allein.

Sind PyPI und andere Registries auch betroffen? Ja. Mini Shai-Hulud war die erste Welle, die npm und PyPI in einer einzigen koordinierten Operation traf, daher gelten dieselben Abwehrprinzipien über die Ökosysteme hinweg.