npm führte Ende 2022 „Package Provenance“ ein. Zwei Jahre lang lag die Akzeptanz im Durchschnitt bei 20 bis 50 Paketen pro Woche. Im Jahr 2024 folgte „Trusted Publishing“. Es wurden Blogbeiträge verfasst. Die CISA veröffentlichte Sicherheitshinweise. Die Entwicklung kam kaum in Gang. Schließlich wurde „Trusted Publishing“ mit OIDC im Juli 2025 allgemein verfügbar gemacht.
Dann schlug Shai-Hulud zu. Die wöchentliche Akzeptanz stieg sprunghaft auf 430 Pakete. Innerhalb von 18 Monaten stieg die kumulierte Akzeptanz um das 3,4-Fache. Wir decken immer noch nur 25 % des gesamten Download-Volumens ab – lediglich 11.001 der 51.370 führenden Pakete haben die Lösung übernommen. Doch die Angriffe haben mehr bewirkt als alles, was die Sicherheitsbranche unternommen hat.
Hier sind die Daten.
Was ist „Trusted Publishing“?
Trusted Publishing ersetzt langlebige npm-API-Token durch kurzlebige, pro Ausführung ausgestellte Anmeldedaten, die über OpenID Connect bereitgestellt werden. Anstatt das NPM_TOKEN auf unbestimmte Zeit in Ihrem GitHub-Repo secrets zu speichern, erhält Ihre CI-Pipeline ein Token, das innerhalb weniger Minuten abläuft. Nichts, was gestohlen werden könnte. Nichts, was abgezogen werden könnte.
Die Angriffswelle, die alles verändert hat
26. August 2025: S1ngularity. Angreifer nutzten eine Fehlkonfiguration von GitHub Actions im Nx-Monorepo aus, um Code aus einem bösartigen Fork im vertrauenswürdigen Kontext des Upstream-Repos auszuführen und so das npm-Veröffentlichungstoken zu stehlen. Schädliche Versionen mehrerer Nx-Pakete waren vier Stunden lang aktiv und durchsuchten die Rechner der Entwickler nach Anmeldedaten, SSH-Schlüsseln und Krypto-Wallets – und suchten insbesondere aktiv nach installierten KI-CLI-Tools, um diese mit der Option „--dangerously-skip-permissions“ auszuführen und Inhalte des Dateisystems zu extrahieren. In dieser Woche stieg die Akzeptanz zum ersten Mal spürbar an.
8. September 2025: Debug/Chalk. Ein Maintainer wurde über eine gefälschte npm-Support-E-Mail (gesendet von npmjs.help) Opfer eines Phishing-Angriffs, bei dem seine Anmeldedaten und sein aktueller TOTP-Code abgegriffen wurden. 18 Pakete mit insgesamt über 2 Milliarden wöchentlichen Downloads wurden mit einer Payload zum Diebstahl von Kryptowährung versehen, die unbemerkt Interaktionen mit Browser-Wallets abfing und Gelder umleitete. Die schädlichen Versionen waren zwei Stunden lang aktiv. In dieser Woche: 103 neue Pakete haben Trusted Publishing eingeführt.
15. September 2025: Shai-Hulud-Welle 1. Ein sich selbst replizierender Wurm befiel das npm-Ökosystem. Sobald ein kompromittiertes Paket zusätzliche npm-Token in seiner Umgebung fand, veröffentlichte es automatisch schädliche Versionen aller anderen Pakete, auf die es Zugriff hatte. Ergebnis: Über 700 kompromittierte Pakete, 27.000 schädliche GitHub-Repositorys, 14.000 offengelegte „ secrets “ in 487 Organisationen. Die CISA gab am 23. September eine Warnung heraus. In dieser Woche: 109 neue Pakete.
23. November 2025: Shai-Hulud 2.0. Ein „Pwn Request“ gegen das Repository „asyncapi/cli“ entwendete das CI-Token in weniger als drei Minuten und nutzte es anschließend, um den Wurm über eine bösartige OpenVSX-Erweiterung zu verbreiten. Die Kampagne breitete sich auf über 25.000 bösartige Repositorys aus. Microsoft veröffentlichte am 9. Dezember Leitlinien. In dieser Woche: 372 neue Pakete. Der wöchentliche Durchschnitt der letzten zwei Jahre lag bei etwa 40.
24. November 2025: SHA1-Hulud. Eine parallele Angriffswelle traf Zapier, ENS Domains und andere. In kompromittierten Repositories wurden lang gültige Anmeldedaten gefunden. Das Sicherheitsteam von npm empfahl ausdrücklich „Trusted Publishing“ als Abhilfe. In dieser Woche: 120 neue Pakete.
20.–21. März 2026: CanisterWorm. Das TeamPCP verbreitete über gestohlene Token einen npm-Wurm. In weniger als 60 Sekunden wurden mehr als 28 Pakete infiziert; die Payload sammelte Anmeldedaten und verbreitete sich selbstständig. In dieser Woche: 112 neue Pakete.
31. März 2026: Axios. Sapphire Sleet (Nordkorea) kompromittierte das Konto eines Betreuers und veröffentlichte im Abstand von 39 Minuten zwei mit einer Hintertür versehene Versionen, die jeweils eine gefälschte Abhängigkeit einfügten, über die im Hintergrund ein plattformübergreifender Fernzugriffstrojaner heruntergeladen wurde. Die schädlichen Pakete waren drei Stunden lang online. Axios verzeichnet wöchentlich über 100 Millionen Downloads. In dieser Woche: 138 neue Pakete.
8.–22. April 2026: CanisterSprawl. Ein zweiter npm-Wurm von TeamPCP, der einen neuen ICP-Canister nutzt. Als in infizierten Umgebungen PyPI-Token entdeckt wurden, sprang er über eine .pth-Injektion auf andere Ökosysteme über. In dieser Woche: 163 neue Pakete.
29.–30. April 2026: Mini Shai-Hulud I. TeamPCP verlagerte seinen Fokus von dem Diebstahl von Tokens auf gestohlene CI-Zugangsdaten. Ein ökosystemübergreifender Angriff traf innerhalb von 24 Stunden npm, PyPI und Packagist über kompromittierte CircleCI-Tokens. In dieser Woche: 121 neue Pakete.
7.–11. Mai 2026: Mini Shai-Hulud II / TanStack. Hier ist die Eskalation, die alles verändert: Es wurde kein Token gestohlen. TeamPCP nutzte einen „Pwn Request“, um den GitHub-Actions-Cache zu manipulieren, und wartete dann darauf, dass der legitime Release-Workflow ausgeführt wurde. Als dies geschah – mit id-token: Schreibberechtigungen –, extrahierte vom Angreifer kontrollierter Code aus dem manipulierten Cache das OIDC-Token aus dem Speicher des Runners und tauschte es über den npm-eigenen Token-Endpunkt aus. Die veröffentlichten Pakete enthielten gültige SLSA-Herkunftsbescheinigungen der Stufe 3. „Trusted Publishing“ wurde nicht umgangen. Es wurde als Angriffsvektor genutzt. Über 170 Pakete auf npm und PyPI innerhalb von 5 Stunden.
18.–19. Mai 2026: Mini Shai-Hulud III / Nx & AntV. Die VS-Code-Erweiterung „Nx Console“ wurde mithilfe von Anmeldedaten kompromittiert, die beim TanStack-Angriff gestohlen worden waren – fünf Tage Verweildauer vor der Nutzung. 639 @antv-npm-Versionen wurden über ein gestohlenes Betreuerkonto manipuliert, wobei jeweils eine persistente „kitty-monitor“-Hintertür installiert wurde. In dieser Woche: 144 neue Pakete. In der Woche danach: 430. Ein Allzeithoch.
1. bis 7. Juni 2026: Miasma / Hades. Die Angriffsmethode änderte sich erneut. In Welle 1 wurden 90 bösartige npm-Versionen veröffentlicht, die auf Pakete von Red Hat Cloud Services abzielten – nicht durch den Diebstahl von OIDC-Tokens, sondern durch direkten Missbrauch des OIDC-Veröffentlichungsendpunkts. In Welle 2 kam die „binding.gyp“-Technik hinzu, um die Erkennung durch Installationsskripte zu umgehen. Bis zur vierten Welle (Hades) hatte die Kampagne über die Ausführung von .pth-Startskripten den Sprung zu PyPI geschafft und 37 Wheels in 19 Paketen manipuliert. Red Hat veröffentlichte RHSB-2026-006. In dieser Woche: 209 neue Pakete.
Das Muster und wie es eskalierte
Die ersten Angriffe folgten einem bekannten Muster: Phishing-Angriff auf einen Betreuer, Diebstahl eines langfristig gültigen Tokens, Veröffentlichung von Malware und Verbreitung auf alle anderen Systeme, die mit diesem Token erreichbar sind. Debug/Chalk war ein Phishing-Angriff. Bei Axios handelte es sich um ein kompromittiertes Betreuerkonto.
Die raffinierteren Angriffe richteten sich jedoch gegen die CI-Pipeline selbst. Sowohl S1ngularity als auch Shai-Hulud 2.0 nutzten sogenannte „Pwn Requests“ – bösartige Pull-Requests, die Schwachstellen in den GitHub-Actions-Workflows von „pull_request_target“ ausnutzten, um Angreifercode innerhalb des vertrauenswürdigen Kontexts des Upstream-Repos auszuführen. Sie mussten kein gespeichertes Token stehlen. Es reichte aus, dass der CI-Runner über ein solches verfügte.
Mini Shai-Hulud II war der logische Endpunkt einer Entwicklung. Sobald man die Kontrolle über den Runner erlangt hat, kann man alle vorhandenen Ambient-Daten extrahieren, einschließlich kurzlebiger OIDC-Token. Die von ihm veröffentlichten Pakete wirkten bei jeder automatisierten Überprüfung legitim: gültige Herkunft, echte Identität des Betreuers, korrekte Signatur. Der Angriff hatte sich von der Ausnutzung gespeicherter „ secrets “ hin zur Ausnutzung des Build-Prozesses selbst weiterentwickelt.
Miasma eskalierte noch weiter. Es musste überhaupt kein Token extrahieren: Es missbrauchte direkt den OIDC-Publishing-Endpunkt. Mit jeder Angriffswelle kam eine neue Technik zur Umgehung der Erkennung zum Einsatz. In den Nachanalysen wurden immer wieder dieselben Fehler genannt. Die Angreifer fanden immer wieder neue Wege, die empfohlenen Abhilfemaßnahmen zu umgehen.
Die Angriffsfläche ist mittlerweile deutlich kleiner als noch vor 18 Monaten. Nicht, weil die Sicherheitsbranche die Menschen überzeugt hätte, sondern weil in Paketen Hintertüren eingebaut wurden und die Betreuer daraufhin ihre Konfiguration geändert haben.
Das ist kein Erfolg für die Sicherheitsaufklärung. Es ist vielmehr ein Beleg dafür, wie Sicherheitsentscheidungen in der Praxis tatsächlich getroffen werden.
Wer war das?
Während der „Shai-Hulud 2.0“-Kampagne benannte der Angreifer sein GitHub-Konto in „UnknownWonderer1“ um – mit ziemlicher Sicherheit eine Anspielung auf die Zensunni-Wanderer aus „Dune“: jene verfolgten Nomaden, aus denen die Fremen hervorgingen, die einzige Kultur, die gelernt hatte, in Harmonie mit Shai-Hulud zu leben. Der Name stammt nicht von jemandem, der zufällig in dieses Ökosystem geraten ist. Es ist der Name von jemandem, der sich intensiv damit auseinandergesetzt hat.
Die Art und Weise, wie die Malware konzipiert ist, untermauert diese Einschätzung. S1ngularity hat die Anmeldedaten nicht unbemerkt abgezogen – stattdessen hat es einen Befehl zum Herunterfahren in das Shell-Profil eingeschleust, der den Rechner beim nächsten Öffnen eines Terminals sichtbar zum Absturz bringen würde. Das ist nicht das Verhalten von jemandem, der versucht, unentdeckt zu bleiben. Jede Kampagne blieb weit hinter dem zurück, was sie hätte bewirken können. Ein Wurm, der sich auf über 700 Pakete selbst verbreitet, aber seine Nutzlast zurückhält, trifft eine bewusste Entscheidung.
Außerdem hatten sie ein besseres Verständnis der Anreizstruktur als das Ökosystem selbst. Betreuer werden selten dafür bezahlt, Pakete abzusichern. Die Folgen eines Sicherheitsvorfalls treffen die nachgelagerten Nutzer, nicht die Person, die das Token in der CI zurückgelassen hat. Die Plattformen, die die Macht haben, eine sichere Veröffentlichung vorzuschreiben, spüren die geringsten Auswirkungen, wenn etwas schiefgeht. Es handelt sich um ein klassisches Versagen kollektiven Handelns – und 40.000 ungeschützte Pakete nach drei Jahren mit Sicherheitshinweisen sind genau das Ergebnis dieser Struktur. Dieser Angreifer verstand, warum sich nichts tat. Und er beschloss, eine andere Art von Druck auszuüben.
Warnschüsse
Ich habe damals darüber geschrieben: die Namensgebung, die Zurückhaltung beim Design der Malware und die Art und Weise, wie die Angriffe stets kurz vor der vollständigen Ausnutzung Halt machten. Meiner Einschätzung nach handelte es sich bei Shai-Hulud nicht in erster Linie um eine kriminelle Operation. Es war eine Botschaft – von jemandem, der das Ökosystem gut genug verstand, um genau zu wissen, welche Schwachstellen es zum Reagieren bringen würden.
Die Fremen beten darum, dass der Durchzug des Schöpfers die Welt reinigen möge. Der Angreifer scheint zu einem ähnlichen Schluss gekommen zu sein: Nur sichtbares Leid würde das Ökosystem dazu zwingen, sich mit den Ursachen auseinanderzusetzen, die die Entstehung des Wurms ermöglicht haben. Für die Fremen ist Shai-Hulud nicht einfach nur ein zerstörerisches Tier. Er ist der Schöpfer. Sein Durchzug reißt eine Spur durch die Wüste, doch er reinigt auch und setzt die Gesetze durch, nach denen alles in diesem Ökosystem leben muss.
Sie haben Shai-Hulud nicht einfach nur freigelassen.
Sie entschieden sich dafür, den Wanderer zu spielen, der verstand, warum es so kommen musste.
Warum wir das Problem noch nicht behoben haben
Die Warnung wurde ausgesprochen. Das Ökosystem reagierte nicht schnell genug. Das als Open Source veröffentlichte „Shai-Hulud“-Playbook wurde daraufhin von Akteuren aufgegriffen, die kein Interesse daran hatten, eine Botschaft zu vermitteln – TeamPCP, Sapphire Sleet und andere, die es direkt auf den Diebstahl von Zugangsdaten, Krypto-Wallets und Fernzugriff abgesehen hatten. Frameworks wie Mastra wurden zu Opfern. Der Wurm, der als Demonstration begann, wurde zur Vorlage.
Das Frustrierende daran ist, dass das Zögern nicht auf technische Schwierigkeiten zurückzuführen ist. Trusted Publishing ist kostenlos und dauert zehn Minuten. Das Problem ist, dass die Kosten, die entstehen, wenn man es nicht tut, noch nicht bei der richtigen Person angekommen sind. Die Betreuer tragen das Reputationsrisiko, wenn ihr Paket kompromittiert wird, aber der tatsächliche Schaden trifft nachgelagert Teams, die keine einzige Zeile des betroffenen Pakets geschrieben haben. Diese Diskrepanz ist struktureller Natur. Angriffe lassen die Akzeptanz vorübergehend in die Höhe schnellen, dann lässt die Dringlichkeit nach, und die nächste Gruppe von Paketen greift wieder standardmäßig auf langlebige Token zurück.
Schauen Sie sich die Grafik an. Die Spitzen sind echt. Genauso wie der Rückgang dazwischen.
Und „Mini Shai-Hulud“ brachte eine neue Wendung ins Spiel: Selbst Pakete, die „Trusted Publishing“ nutzen, können kompromittiert werden, wenn die zugrunde liegende CI-Pipeline nicht ausreichend gesichert ist. Das Extrahieren eines OIDC-Tokens aus dem Speicher eines Runners ist schwieriger als das Stehlen eines gespeicherten Geheimnisses. Aber es ist nicht unmöglich, und für den Angriff gibt es nun einen öffentlichen Proof-of-Concept. „Trusted Publishing“ beseitigt einen Angriffsvektor. Es beseitigt jedoch nicht alle.
Die Rechenschaftslücke und wie man sie schließen kann
Axios verzeichnete wöchentlich über 100 Millionen Downloads und hatte „Trusted Publishing“ noch nicht eingeführt, als Nordkorea das System kompromittierte. Jemand hätte ein Jahr zuvor einen PR-Beitrag einreichen können. Niemand tat dies.
Das ist die Lücke in der Rechenschaftspflicht. Die Sicherheitsgemeinschaft veröffentlicht Sicherheitshinweise, verfasst Nachberichte und wartet darauf, dass der nächste Angriff etwas bewegt. Es gibt jedoch eine konstruktivere Variante desselben Drucks: proaktiv die 40.000 Pakete anzugehen, die noch nicht umgestellt wurden – so wie Let’s Encrypt es mit HTTP getan hat. Reicht PRs ein. Eröffnet Issues. Nennen Sie die Pakete mit hohen Downloadzahlen, die immer noch langlebige Token verwenden. Sorgen Sie dafür, dass die sozialen Kosten einer Nichtübernahme von TP höher sind als die zehn Minuten, die die Behebung des Problems in Anspruch nimmt.
Das ist genau die Art von Aktivismus, die das Ökosystem tatsächlich braucht. Nicht noch eine CISA-Empfehlung. Nicht noch ein Blogbeitrag, der gelesen und dann vergessen wird. Konkreter, gezielter, unangenehmer Druck auf bestimmte Betreuer bestimmter Pakete – jene mit mehr als 10 Millionen Downloads pro Woche, die nur noch eine durch Phishing gestohlene Zugangsdaten davon entfernt sind, zum nächsten Sicherheitsvorfall zu werden.
Die Sicherheitsbranche weiß bereits seit drei Jahren, wie das Problem zu lösen ist. Die Frage ist, ob wir bereit sind, es gesellschaftlich inakzeptabel zu machen, dies zu ignorieren.
40.000 der 51.000 beliebtesten Pakete sind noch nicht umgestellt worden
11.001 Pakete nutzen mittlerweile „Trusted Publishing“. Diese 11.000 machen zufällig etwa 25 % des gesamten Download-Volumens aus, da einige der größten Pakete nach jeder Angriffswelle auf dieses System umgestiegen sind. Das bedeutet jedoch, dass 40.369 Pakete (75 % des Download-Volumens) weiterhin mit langlebigen Tokens veröffentlicht werden.
Wenn Sie ein npm-Paket betreuen, kümmern Sie sich sofort darum. Die Dokumentation finden Sie hier. Vier Zeilen YAML und ein Kontrollkästchen. Stellen Sie anschließend sicher, dass Ihre GitHub-Actions-Workflows kein „pull_request_target“ ohne explizite Vertrauensgrenzen enthalten – das ist der Angriffsvektor, den „Mini Shai-Hulud“ genutzt hat, um das OIDC-Token auch nach der Implementierung von TP zu extrahieren.
Wenn Sie auf Pakete angewiesen sind, die noch nicht umgestellt wurden, melden Sie ein Problem. Erstellen Sie einen Pull-Request. Möglicherweise weiß der Betreuer noch nicht, dass es „Trusted Publishing“ gibt, oder braucht einfach jemanden, der ihm klarmacht, dass Untätigkeit unangenehmer ist als die zehnminütige Korrektur.
Der Sandwurm in „Dune“ heißt Shai-Hulud, was so viel bedeutet wie „der große Alte der Wüste“. Die Fremen freuen sich nicht, wenn er etwas zerstört. Sie wissen, dass sein Vorbeiziehen das Ökosystem auf eine Weise prägt, wie es nichts anderes vermag.
Das ist die unangenehme Wahrheit, um die es in diesem Beitrag geht. Die Angriffe haben ihr Ziel erreicht. Der Schmerz hat mehr bewirkt als drei Jahre voller Warnungen.
Wir haben unsere Lektion gelernt. Das Ökosystem reagiert auf Druck, und dieser muss nicht unbedingt von einem Wurm ausgehen. Der Wanderer hat verstanden, warum der Schöpfer kommen musste. Wir arbeiten daran, dass der nächste nicht mehr nötig sein wird.
Mehr dazu in Kürze.
