npm hat Ende 2022 Package Provenance eingeführt. Zwei Jahre lang lag die Einführung bei durchschnittlich 20 bis 50 Paketen pro Woche. Es folgte Trusted Publishing im Jahr 2024. Blogbeiträge wurden verfasst. CISA-Warnungen wurden herausgegeben. Es tat sich kaum etwas. Schließlich wurde Trusted Publishing mit OIDC im Juli 2025 allgemein verfügbar gemacht.
Dann schlug Shai-Hulud zu. Die wöchentliche Einführung sprang auf 430 Pakete. In 18 Monaten ist die kumulative Nutzung um das 3,4-Fache gestiegen. Nach wie vor sind erst 25 % des gesamten Download-Volumens abgedeckt – gerade einmal 11.001 der 51.370 Top-Pakete haben es übernommen. Aber die Angriffe haben mehr bewegt als alles, was die Sicherheitsbranche getan hat.
Hier sind die Daten.
Was Trusted Publishing ist
Trusted Publishing ersetzt langlebige npm-API-Tokens durch kurzlebige Anmeldeinformationen pro Ausführung, die über OpenID Connect ausgestellt werden. Anstatt NPM_TOKEN unbegrenzt in den Secrets Ihres GitHub-Repositorys zu speichern, erhält Ihre CI-Pipeline ein Token, das nach wenigen Minuten abläuft. Nichts zum Stehlen. Nichts zum Exfiltrieren.
Die Angriffs welle, die alles veränderte
26. August 2025: S1ngularity. Angreifende nutzten eine Fehlkonfiguration von GitHub Actions im Nx-Monorepo aus, um Code aus einem schadhaften Fork im vertrauenswürdigen Kontext des Upstream-Repos auszuführen, wodurch das npm-Publishing-Token entwendet wurde. Schadhafte Versionen mehrerer Nx-Pakete waren vier Stunden lang aktiv und durchsuchten Entwickelnde-Maschinen nach Anmeldedaten, SSH-Schlüsseln, Krypto-Wallets – und suchten dabei gezielt nach installierten KI-CLI-Tools, um diese mit --dangerously-skip-permissions auszuführen und Dateisysteminhalte 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) gepatched, die seine Anmeldedaten und das aktuelle TOTP-Token abfischte. 18 Pakete mit über 2 Milliarden kombinierten wöchentlichen Downloads wurden mit einer Krypto-Diebstahl-Nutzlast versehen, die Browser-Wallet-Interaktionen unbemerkt abfing und Gelder umleitete. Schadhafte Versionen waren zwei Stunden lang aktiv. In dieser Woche: 103 neue Pakete übernahmen Trusted Publishing.
15. September 2025: Shai-Hulud Welle 1. Ein sich selbst replizierender Wurm traf das npm-Ökosystem. Wenn ein kompromittiertes Paket weitere npm-Token in seiner Umgebung fand, veröffentlichte es automatisch schadhafte Versionen aller anderen erreichbaren Ziele. Das Ergebnis: über 700 kompromittierte Pakete, 27.000 schadhafte GitHub-Repositories, 14.000 offengelegte Secrets in 487 Organisationen. 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 exfiltrierte das CI-Token in unter drei Minuten und nutzte es anschließend, um den Wurm über eine schadhafte OpenVSX-Erweiterung einzusetzen. Die Kampagne breitete sich auf über 25.000 schadhafte Repositories aus. Microsoft veröffentlichte am 9. Dezember entsprechende Leitlinien. In dieser Woche: 372 neue Pakete. Der wöchentliche Durchschnitt der vorherigen zwei Jahre lag bei rund 40.
24. November 2025: SHA1-Hulud. Eine parallele Welle traf Zapier, ENS Domains und andere. Langlebige Anmeldedaten lagen ungeschützt in kompromittierten Repositories. Das npm-Sicherheitsteam empfahl Trusted Publishing ausdrücklich als Behelf. In dieser Woche: 120 neue Pakete.
20.–21. März 2026: CanisterWorm. TeamPCP setzte über gestohlene Token einen npm-Wurm ein. Über 28 Pakete wurden in unter 60 Sekunden infiziert; die Nutzlast erntete Anmeldedaten und propagierte sich selbst. In dieser Woche: 112 neue Pakete.
31. März 2026: Axios. Sapphire Sleet (Nordkorea) kompromittierte ein Maintainer-Konto und veröffentlichte im Abstand von 39 Minuten zwei mit Backdoors versehene Versionen, die jeweils eine gefälschte Abhängigkeit injizierten, welche unbemerkt einen plattformübergreifenden Remote-Access-Trojaner herunterlud. Die schadhaften Pakete waren drei Stunden lang aktiv. Axios hat über 100 Mio. wöchentliche Downloads. In dieser Woche: 138 neue Pakete.
8.–22. April 2026: CanisterSprawl. Ein zweiter npm-Wurm von TeamPCP, der einen neuen ICP-Canister verwendete. Als in infizierten Umgebungen PyPI-Token entdeckt wurden, wechselte er über eine .pth-Injektion das Ökosystem. In dieser Woche: 163 neue Pakete.
29.–30. April 2026: Mini Shai-Hulud I. TeamPCP wechselte von Token-Diebstahl zu gestohlenen CI-Anmeldedaten. Ein ökosystemübergreifender Angriff traf npm, PyPI und Packagist innerhalb von 24 Stunden über kompromittierte CircleCI-Token.
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 vergiften, und wartete dann darauf, dass der legitime Release-Workflow ausgeführt wurde. Als dies geschah – mit id-token: write-Berechtigungen – extrahierte der vom Angreifenden gesteuerte Code aus dem vergifteten Cache das OIDC-Token aus dem Runner-Speicher und tauschte es über den npm-eigenen Token-Endpunkt aus. Die veröffentlichten Pakete trugen gültige Herkunftsnachweise der SLSA Build Level 3. Trusted Publishing wurde nicht umgangen, sondern als Vektor für den Angriff missbraucht. Über 170 Pakete über npm und PyPI hinweg in 5 Stunden.
18.–19. Mai 2026: Mini Shai-Hulud III / Nx & AntV. Die Nx Console VS Code-Erweiterung wurde unter Verwendung von Anmeldedaten kompromittiert, die während des TanStack-Angriffs gestohlen worden waren – fünf Tage Verweilzeit vor der Nutzung. 639 @antv-npm-Versionen wurden über ein gestohlenes Maintainer-Konto vergiftet, von denen jede eine persistente Kitty-Monitor-Backdoor installierte. In dieser Woche: 144 neue Pakete. In der darauf folgenden Woche: 430. Ein historischer Höchstwert.
1.–7. Juni 2026: Miasma / Hades. Die Angriffsklasse veränderte sich erneut. Welle 1 veröffentlichte 90 schadhafte npm-Versionen, die auf Pakete der Red Hat Cloud Services abzielten – nicht durch Diebstahl von OIDC-Token, sondern durch direkten Missbrauch des OIDC-Publishing-Endpunkts. Welle 2 fügte eine binding.gyp-Technik hinzu, um die Erkennung von Installationsskripten zu umgehen. Bis Welle 4 (Hades) hatte die Kampagne über die .pth-Startausführung auf PyPI übergegriffen und 37 Wheels über 19 Pakete hinweg vergiftet. Red Hat gab RHSB-2026-006 heraus. In dieser Woche: 209 neue Pakete.
Das Muster und wie es eskalierte
Die frühen Angriffe folgten einem bekannten Schema: Phishing bei einem Maintainer, Diebstahl eines langlebigen Tokens, Veröffentlichung von Malware, Verbreitung auf alles, was das Token erreichen kann. Debug/Chalk war ein Phishing-Angriff. Axios betraf ein kompromittiertes Maintainer-Konto.
Die ausgefeilteren Angriffe zielten jedoch direkt auf die CI-Pipeline ab. S1ngularity und Shai-Hulud 2.0 nutzten beide Pwn-Requests – schadhafte Pull Requests, die anfällige pull_request_target-Workflows von GitHub Actions ausnutzten, um Code von Angreifenden im vertrauenswürdigen Kontext des Upstream-Repos auszuführen. Sie mussten kein gespeichertes Token stehlen. Sie benötigten lediglich ein solches im CI-Runner.
Mini Shai-Hulud II war das logische Endglied einer Entwicklung. Sobald man den Runner kontrolliert, lassen sich sämtliche dort vorhandenen Umgebungssicherheitsdaten (Ambient Credentials) extrahieren, einschließlich kurzlebiger OIDC-Token. Die von ihm veröffentlichten Pakete sahen bei jeder automatisierten Prüfung legitim aus: gültige Herkunft, echte Identität des Maintainers, korrekte Signierung. Der Angriff hatte sich von der Ausnutzung gespeicherter Secrets hin zur Ausnutzung des Build-Prozesses selbst entwickelt.
Miasma eskalierte noch weiter. Es war gar nicht mehr erforderlich, ein Token zu extrahieren: Es wurde direkt der OIDC-Publishing-Endpunkt missbraucht. Jede Welle führte eine neue Technik zur Umgehung der Erkennung ein. In den post-mortem-Analysen wurden kontinuierlich dieselben Fehler genannt. Die Angriffe fanden jedoch immer neue Wege, um die empfohlenen Korrekturen zu umgehen.
Die Angriffsfläche ist inzwischen deutlich kleiner als noch vor 18 Monaten. Nicht, weil die Sicherheitsbranche die Leute überzeugt hätte. Sondern weil Pakete mit Backdoors versehen wurden und die Maintainer daraufhin ihre Konfiguration anpassten.
Das ist kein Erfolg für die Sicherheitsaufklärung. Es ist ein Indikator dafür, wie Sicherheitsentscheidungen in der Praxis tatsächlich getroffen werden.
Wer steckte dahinter?
Während der Shai-Hulud 2.0-Kampagne benannte der Angreifer seinen GitHub-Account in UnknownWonderer1 um – fast sicher eine Anspielung auf die Zensunni-Wanderer aus Dune: die verfolgten Nomaden, aus denen die Fremen hervorgingen, die einzige Kultur, die lernte, im Einklang mit Shai-Hulud zu leben. Dieser Name stammt nicht von jemandem, der zufällig in das Ökosystem geraten ist. Es ist der Name von jemandem, der sich intensiv damit auseinandergesetzt hat.
Das Design der Malware untermauert diese Lesart. S1ngularity hat Zugangsdaten nicht heimlich exfiltriert – es hat einen Shutdown-Befehl in das Shell-Profil injiziert, der den Rechner beim nächsten Öffnen des Terminals sichtbar lahmlegt. Das ist nicht das Verhalten von jemandem, der unbemerkt bleiben möchte. Jede Kampagne blieb weit unter dem, was möglich gewesen wäre. Ein Wurm, der sich selbstständig auf über 700 Pakete überträgt, aber seine Nutzlast zurückhält, trifft eine bewusste Entscheidung.
Sie verstanden auch die Anreizstruktur besser als das Ökosystem selbst. Maintainer werden selten dafür bezahlt, Pakete abzusichern. Die Tragweite eines Sicherheitsvorfalls trifft die Downstream-Nutzer, nicht die Person, die das Token in der CI belassen hat. Die Plattformen, die die Macht haben, sicheres Publishing vorzuschreiben, spüren die geringsten Konsequenzen, wenn etwas schiefgeht. Das ist ein klassisches Kollektivgutproblem – und 40.000 ungesicherte Pakete nach drei Jahren voller Warnungen sind genau das, was diese Struktur hervorbringt. Dieser Angreifer hat verstanden, warum sich nichts bewegte. Und er beschloss, eine andere Art von Druck auszuüben.
Warnschüsse
Ich habe damals darüber geschrieben: die Namensgebung, die Zurückhaltung beim Malware-Design und die Tatsache, dass die Angriffe konsequent vor einer vollständigen Ausnutzung stoppten. Meine Einschätzung ist, dass Shai-Hulud primär keine kriminelle Operation war. Es war eine Botschaft – von jemandem, der das Ökosystem gut genug kannte, um genau zu wissen, welche Schwachpunkte man drücken muss, um Bewegung in die Sache zu bringen.
Die Fremen beten darum, dass der Durchzug des Schöpfers die Welt reinigt. Der Angreifer scheint zu einem ähnlichen Schluss gekommen zu sein: Nur sichtbarer Schmerz würde das Ökosystem dazu zwingen, sich dem zu stellen, was den Wurm überhaupt erst möglich gemacht hat. Für die Fremen ist Shai-Hulud nicht einfach nur ein zerstörerisches Tier. Es ist der Schöpfer. Sein Durchzug reißt durch die Wüste, aber er reinigt auch und erzwingt die Gesetze, nach denen alles in diesem Ökosystem leben muss.
Sie haben Shai-Hulud nicht einfach nur losgelassen.
Sie entschieden sich dafür, die Rolle des Wanderers zu spielen, der verstand, warum es kommen musste.
Warum wir das Problem immer noch nicht gelöst haben
Die Warnung wurde ausgesprochen. Das Ökosystem hat sich nicht schnell genug bewegt. Das als Open Source bereitgestellte Shai-Hulud-Playbook wurde daraufhin von Akteuren aufgegriffen, die keinerlei Interesse daran hatten, eine Botschaft zu senden – TeamPCP, Sapphire Sleet und andere, die direkt auf Diebstahl von Zugangsdaten, Krypto-Wallets und Remote-Zugriff aus waren. 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 Zögern liegt darin, dass die Kosten des Nicht-Tuns noch nicht die richtige Person getroffen haben. Maintainer tragen das Reputationsrisiko, wenn ihr Paket kompromittiert wird, aber der tatsächliche Schaden trifft nachgelagerte Teams, die keine einzige Zeile des betroffenen Pakets geschrieben haben. Diese Diskrepanz ist strukturell. Angriffe treiben die Adoption vorübergehend in die Höhe, dann lässt die Dringlichkeit nach, und die nächste Paket-Kohorte fällt wieder standardmäßig auf langlebige Tokens zurück.
Betrachten Sie das Diagramm. Die Ausschläge sind real. Und das Abflauen dazwischen ist es auch.
Und Mini Shai-Hulud brachte eine neue Komplexität ins Spiel: Selbst Pakete, die Trusted Publishing nutzen, können kompromisht werden, wenn die zugrundeliegende CI-Pipeline nicht gehärtet ist. Das Extrahieren eines OIDC-Tokens aus dem Runner-Speicher ist schwieriger als das Stehlen eines gespeicherten Secrets. Aber es ist nicht unmöglich, und für diesen Angriff gibt es inzwischen einen öffentlichen Proof of Concept. Trusted Publishing entfernt einen Angriffsvektor. Es entfernt nicht alle.
Die Rechenschaftslücke und was man dagegen tun kann
Axios hatte über 100 Millionen wöchentliche Downloads und hatte Trusted Publishing noch nicht implementiert, bevor Nordkorea es kompromittierte. Jemand hätte ein Jahr zuvor einen PR einreichen können. Niemand tat es.
Das ist die Rechenschaftslücke. Die Security-Community veröffentlicht Advisories, schreibt Postmortems und wartet auf den nächsten Angriff, um etwas zu bewegen. Es gibt eine konstruktivere Version desselben Drucks: proaktiv auf die 40.000 Pakete zuzugehen, die noch nicht umgestellt haben, so wie Let's Encrypt es damals bei HTTP gemacht hat. PRs einreichen. Issues öffnen. Die Pakete mit hohen Downloadzahlen benennen, die immer noch mit langlebigen Tokens laufen. Die sozialen Kosten dafür, TP nicht zu nutzen, höher machen als die zehn Minuten, die die Behebung dauert.
Das ist die Art von Aktivismus, die das Ökosystem tatsächlich braucht. Kein weiteres CISA-Advisory. Kein weiterer Blogbeitrag, der gelesen und vergessen wird. Spezifischer, gezielter, unangenehmer Druck auf bestimmte Maintainer bestimmter Pakete – genau jene mit über 10 Millionen wöchentlichen Downloads, die nur ein abgefangenes Credential davon entfernt sind, der nächste Vorfall zu werden.
Die Sicherheitsbranche weiß seit drei Jahren, wie die Lösung aussieht. Die Frage ist, ob wir bereit sind, es sozial inakzeptabel zu machen, sie zu ignorieren.
40.000 der 51.000 wichtigsten Pakete haben immer noch nicht gewechselt
11.001 Pakete haben Trusted Publishing eingeführt. Diese 11.000 machen zufällig etwa 25 % des gesamten Download-Volumens aus, da einige der größten Pakete nach jeder Angriffswelle umgestiegen sind. Das bedeutet jedoch, dass 40.369 Pakete (75 % des Download-Volumens) weiterhin mit langlebigen Tokens veröffentlichen.
Wenn du ein npm-Paket maintainst, tu es jetzt. Die Dokumentation findest du hier. Vier Zeilen YAML und ein Häkchen. Stelle dann sicher, dass deine GitHub-Actions-Workflows kein pull_request_target ohne explizite Vertrauensgrenzen verwenden – das ist der Vektor, den Mini Shai-Hulud genutzt hat, um das OIDC-Token selbst nach der Implementierung von TP zu extrahieren.
Wenn du von Paketen abhängst, die nicht umgestellt haben, erstelle ein Issue. Öffne einen PR. Der Maintainer weiß vielleicht nicht, dass Trusted Publishing existiert, oder braucht einfach jemanden, der das Nichtstun unangenehmer macht als die zehnminütige Korrektur.
Der Sandwurm in Dune heißt Shai-Hulud, was „der große alte Mann der Wüste“ bedeutet. Die Fremen feiern nicht, wenn er etwas zerstört. Sie verstehen, dass sein Vorbeiziehen das Ökosystem auf eine Weise prägt, wie es nichts anderes kann.
Das ist die unangenehme Wahrheit im Zentrum dieses Beitrags. Die Angriffe haben funktioniert. Schmerz hat Dinge in Bewegung gesetzt, die drei Jahre voller Advisories nicht bewirken konnten.
Wir haben unsere Lektion gelernt. Das Ökosystem bewegt sich unter Druck, und dieser Druck muss nicht von einem Worm ausgehen. Der Wanderer verstand, warum der Schöpfer kommen musste. Wir arbeiten daran, den nächsten überflüssig zu machen.
Demnächst mehr dazu.
