09/2026 – Fachartikel Swiss Infosec AG
Am 4. August 2026 kroch ein alter Bekannter zurück ins Ökosystem von npm, dem weltweit grössten Paketverzeichnis für JavaScript: ein selbstverbreitender Wurm aus der Familie Shai-Hulud, benannt nach den riesigen Sandwürmern aus dem Roman «Dune». Die neue Welle wurde von Sicherheitsforschenden als ChainDrop bezeichnet. Sie stahl Zugangsdaten aus Entwicklungs- und Buildumgebungen, verbreitete verseuchte Softwarebausteine selbständig weiter und trug dabei teilweise sogar echte Herkunftsnachweise. Der Vorfall führt vor, was passiert, wenn Vertrauen die einzige Verteidigungslinie ist. 1, 2, 8
Ein Wurm mit Stammbaum
Moderne Software wird selten am Stück geschrieben. Sie entsteht aus Tausenden von quelloffenen Bausteinen, die Entwicklungsteams per Knopfdruck aus Verzeichnissen wie npm beziehen. Genau dieses Modell nutzt die Familie Shai-Hulud aus, und wie in jeder Familie vererbt sich das Handwerk. Der Urahn trat im September 2025 auf. Socket dokumentierte 526 bestätigte name@version-Einträge. Der Schadcode wurde über einen postinstall-Schritt oder beim späteren Laden des Pakets ausgeführt. Im November 2025 folgte Shai-Hulud 2.0. Die von der Kampagne angelegten öffentlichen GitHub-Repositories trugen die Beschreibung «Sha1-Hulud: The Second Coming». Diese Variante hatte dazugelernt: Sie schlug bereits in der preinstall-Phase zu und hinterliess über 25’000 bösartige Repositories auf GitHub. 6, 7
ChainDrop ist die nächste, deutlich weiterentwickelte Variante in dieser Linie. Sie übernimmt zentrale Mechanismen ihrer Vorgänger und ergänzt sie um eigene Mutationen, vom Auslesen von Zugangsdaten direkt aus dem Arbeitsspeicher bis zur Steuerung über die Blockchain. Innert weniger Stunden breitete sie sich über Hunderte Pakete aus. 1, 2, 4
Auch die schwankenden Zahlen sind aufschlussreich: Microsoft berichtete von mehr als 400 betroffenen Paketen. Aikido zählte am 5. August 2026 um 13.15 Uhr CEST 444 Pakete in 1’381 Versionen. Zum Stand vom 4. August 2026, 18.10 Uhr UTC wies StepSecurity ebenfalls 444 Pakete aus, jedoch 2’212 kompromittierte Versionen. Die Quellen erklären diese Abweichung nicht vollständig. Da sich der Wurm autonom weiterverbreitete, blieben alle Zahlen Momentaufnahmen. Laut Aikido verzeichneten die betroffenen Bausteine zusammen mehr als zwei Milliarden Installationen pro Monat. Darunter waren Klassiker wie keyv und flat-cache, die in unzähligen Anwendungen tief vergraben stecken. 1, 4, 5
Der unmittelbar beobachtete Schwerpunkt des Angriffs lag nicht auf Verschlüsselung. Im Zentrum standen der Abfluss von Zugangsdaten aus Entwicklungssystemen, Cloudumgebungen und Veröffentlichungsprozessen sowie die Kompromittierung weiterer Entwicklungsumgebungen und Lieferketten. Der analysierte Schadcode enthielt ausserdem einen destruktiven Mechanismus, der nur unter bestimmten Bedingungen ausgelöst werden konnte. Betroffen ist also nicht nur, wer Software herstellt, sondern auch jede Organisation, deren Lieferanten Software entwickeln. Das dürften die meisten sein. 1, 2, 4
So funktioniert der Angriff
1. Einstieg über gestohlene Zugangsdaten. Nach Einschätzung von Microsoft begann der Angriff nicht mit einer technischen Lücke bei npm, sondern mit gestohlenen Zugangsdaten von Paketverantwortlichen. Elastic Security Labs verortet den Ausgangspunkt beim kompromittierten Konto des keyv-Maintainers. Die Bibliothek verzeichnete mehr als 600 Millionen Downloads pro Monat. 1, 3
2. Ausführung vor nachgelagerten Kontrollen. Die manipulierten Pakete enthielten ein Skript, das npm in der preinstall-Phase automatisch ausführte. Der Schadcode lief damit, bevor nachgelagerte Anwendungstests und viele konventionelle Kontrollen im regulären Buildablauf griffen. Der ursprüngliche Paketinhalt blieb funktionsfähig. Ausserhalb von CI-Umgebungen liess der Wurm die Installation laut Unit 42 ohne Fehler oder Warnungen weiterlaufen. Für die Ausführung lud er die legitime Laufzeitumgebung Bun 1.3.13 aus offizieller Quelle nach. Bun selbst war nicht kompromittiert; der Wurm missbrauchte es lediglich als Werkzeug. 1, 2, 5
3. Diebstahl und Validierung von Schlüsseln. Der Schadcode durchsuchte Arbeitsplätze und Buildumgebungen anhand von mehr als 300 Suchmustern. Er suchte nach Zugangsdaten für npm, GitHub, Cloudplattformen, Kubernetes, Vault und SSH, aber auch für KI- und Coding-Dienste wie Anthropic Claude und OpenAI. Besonders unangenehm: Er prüfte gefundene Zugangsdaten direkt bei den Zielsystemen und nutzte gültige Treffer, um weitere Geheimnisse abzurufen. Auf GitHub-Actions-Runnern las er kurzlebige Zugangsdaten direkt aus dem Speicher des laufenden Runner-Prozesses aus, also genau jene Daten, die mit dem Ende des Buildjobs eigentlich verschwinden sollten. 1, 2, 3
4. Selbstverbreitung. Fand der Wurm ein gestohlenes npm-Token mit Paket-Schreibrechten und der Berechtigung bypass_2fa, konnte er ohne zusätzliche Zwei-Faktor-Bestätigung veröffentlichen. Anschliessend ermittelte er alle Pakete, für die die kompromittierte Identität Veröffentlichungsrechte besass. Er schleuste seinen Schadcode ein, erhöhte die Versionsnummer und veröffentlichte eine neue Version, getarnt als gewöhnliches Wartungsupdate. StepSecurity dokumentierte 444 betroffene Pakete in 2’212 Versionen in weniger als vier Stunden (Stand: 4. August 2026, 18.10 Uhr UTC). 1, 3, 4
5. Persistenz über die Werkzeuge der Entwickelnden. Der Wurm legte Persistenzmechanismen in Konfigurationsdateien von Visual Studio Code und Claude Code an. Wenn sich unter den gestohlenen Zugangsdaten ein GitHub-App-Token befand, schrieb er die entsprechenden Dateien laut Elastic in bis zu 50 Branches je erreichbarem Repository. Elastic bewertete beide Konfigurationen als mögliche Ausführungspfade. Unit 42 entdeckte im untersuchten Exemplar jedoch einen handwerklichen Fehler: Nur der VS-Code-Pfad löste den Schadcode tatsächlich aus. Der Claude-Code-Pfad blieb wirkungslos, weil seine Dateiverweise ins Leere zeigten. Solche Konfigurationsdateien können eine automatische Codeausführung anstossen, werden in vielen Organisationen aber nicht systematisch als sicherheitsrelevante Artefakte geprüft. 2, 3
6. Steuerbare Exfiltration. Die Beute wurde verschlüsselt an einen dynamisch ermittelten HTTPS-Endpunkt übertragen. Fiel dieser Kanal aus, konnte der Wurm öffentliche GitHub-Repositories als alternativen Exfiltrationsweg verwenden. Die primäre Ziel-Domain wurde über einen Smart Contract auf Ethereum ermittelt. Zusätzlich war ein kryptografisch verifizierter GitHub-Eintrag für eine Ersatzdomain vorgesehen. Am 4. August schalteten die Angreifer per Blockchaintransaktion auf eine neue Domain um, ohne die bereits verteilte Schadsoftware verändern zu müssen. Klassische Sperrlisten können mit dieser Beweglichkeit kaum Schritt halten. 1, 2
Der Kreislauf des Wurms: Jede erfolgreiche Ausführung kann Zugangsdaten liefern; geeignete npm-Tokens ermöglichen die Veröffentlichung weiterer manipulierter Paketversionen. Die Zahlen sind zeit- und methodenabhängige Momentaufnahmen.
Der unbequeme Teil: echte Siegel auf bösartiger Ware
Die Branche setzt zunehmend auf digitale Herkunftsnachweise für Software, auch als Software-Provenance bezeichnet. Solche Nachweise ähneln einem Werkszeugnis: Sie belegen, in welchem Projekt und nach welchem Prozess ein Paket erstellt wurde. ChainDrop hat dieses Zeugnis nicht gefälscht. Bei den bestätigten Ausgangsreleases stammten die Nachweise aus den regulären Build- und Veröffentlichungsprozessen der kompromittierten Projekte. 4, 5
Die elf bestätigten Ausgangspakete im keyv-Umfeld wurden am 4. August 2026 direkt aus den gekaperten Projekten veröffentlicht. Nachdem die Angreifer ihren Code eingeschleust hatten, bauten und veröffentlichten die legitimen GitHub-Actions-Workflows die manipulierten Pakete wie reguläre Releases. Diese Versionen trugen deshalb gültige SLSA-Provenance. Zusätzlich enthielt der Wurm einen gezielten Pfad, der über npm Trusted Publishing und Sigstore ebenfalls einen gültigen Herkunftsnachweis hätte erzeugen können. Unit 42 fand den Pfad vollständig implementiert, beobachtete ihn jedoch nicht in Ausführung. Die Signatur kann also gültig und das Herkunftszeugnis korrekt sein, obwohl der Inhalt bösartig ist. Der Nachweis belegt eben die Herkunft, nicht die Unbedenklichkeit. 2, 4, 5
Für viele der anschliessend selbständig veröffentlichten Versionen gab es im Quellrepository keinen zugehörigen Commit, keinen Pull Request, keinen Tag und kein reguläres Release. Das war ein starkes Warnsignal: Die veröffentlichten Tarballs waren ausserhalb des üblichen Entwicklungsprozesses entstanden. Der Abgleich mit dem Quellrepository ist eine eigenständige Prüfung; die technische Gültigkeit eines Siegels ist davon unabhängig. Die Lehre aus beiden Fällen: Fehlt der Herkunftsnachweis oder stimmen Nachweis, Quellrepository und Workflow nicht überein, ist das ein deutliches Warnsignal. Ein vorhandener, gültiger Nachweis beweist jedoch weder die Harmlosigkeit des Pakets noch die Autorisierung der Änderung. Wer lediglich abhakt, ob ein Siegel vorhanden ist, stellt die falsche Frage. 1, 2
Was der Herkunftsnachweis aussagt und was nicht.
Was daran neu ist
Die Geschwindigkeit ist maschinell. Über 2’000 vergiftete Versionen in weniger als vier Stunden überfordern rein manuelle Melde-, Triage- und Freigabeketten. Schutzmassnahmen müssen im Voraus eingerichtet sein, nicht erst im Ereignisfall. 4
Ein formal gültiger Nachweis ist keine Entwarnung. Der Herkunftsnachweis funktionierte technisch wie vorgesehen. Er bestätigte den angegebenen Workflow und die Buildidentität, sagte aber weder etwas über die Autorisierung der Änderung noch über die Harmlosigkeit des Inhalts aus. 2, 4
Die Werkzeuge der Entwickelnden wurden Teil des Angriffs. Konfigurationsdateien von Entwicklungsumgebungen und Codeassistenten können automatische Codeausführung auslösen, werden aber häufig nicht mit derselben Strenge geprüft wie Anwendungscode oder Build-Workflows. 2, 3
Warum das eine Frage des Entwicklungszyklus ist
ChainDrop ist kein Argument gegen quelloffene Software, sondern eines für einen sicheren Entwicklungszyklus (Secure SDLC). Wer Software baut, verantwortet nicht nur den eigenen Code, sondern die gesamte Entstehungskette: Abhängigkeiten, Buildumgebung und Veröffentlichungsprozess.
ISO/IEC 27001:2022 führt den sicheren Entwicklungslebenszyklus in A.8.25 und die Informationssicherheit in der IKT-Lieferkette in A.5.21 als Referenzkontrollen auf. Eine Organisation muss risikobasiert bestimmen, welche Kontrollen erforderlich sind und wie sie ausgestaltet werden. Die Auswahl und Ausgestaltung der Kontrollen sind mit dem Referenzsatz in Anhang A abzugleichen und in der Erklärung zur Anwendbarkeit (Statement of Applicability) zu dokumentieren. 10, 11
ChainDrop zeigt, weshalb beide Kontrollbereiche zusammengehören. Der Wurm gelangte als vergiftetes Paket über die Lieferkette in die betroffene Umgebung. Dort nutzte er Schwächen im Entwicklungsprozess, etwa ungeprüfte Installationsskripte und unzureichend überwachte Buildumgebungen. Mit gestohlenen Veröffentlichungsrechten verwandelte er jedes Opfer anschliessend in ein Lieferkettenrisiko für dessen Kunden. Wer nur einen der beiden Bereiche absichert, bleibt an dieser Nahtstelle verwundbar. 1, 2, 4
Dazu tickt eine regulatorische Uhr. Ab dem 11. September 2026 gelten für Hersteller von Produkten mit digitalen Elementen die Meldepflichten des EU Cyber Resilience Act. Bei aktiv ausgenutzten Schwachstellen und schwerwiegenden Vorfällen, die die Produktsicherheit beeinträchtigen, müssen Hersteller grundsätzlich innerhalb von 24 Stunden nach Kenntniserlangung eine Frühwarnung und innerhalb von 72 Stunden eine vollständige Meldung einreichen. Zusätzlich ist ein Abschlussbericht einzureichen. Bei aktiv ausgenutzten Schwachstellen ist er spätestens 14 Tage nach Bereitstellung einer Korrekturmassnahme fällig; bei schwerwiegenden Vorfällen innerhalb eines Monats. Ein Supply-Chain-Vorfall dieser Art kann daher zusätzlichen regulatorischen Zeitdruck erzeugen. Meldefähigkeit setzt Erkennungsfähigkeit voraus. 9
Sofortmassnahmen für die ersten 90 Tage
- Direkte und indirekte Abhängigkeiten, Lockfiles, Artefaktspeicher und Buildcaches mit den publizierten Listen betroffener Versionen abgleichen. 2, 4, 5
- Betroffene Arbeitsplätze und Buildserver als kompromittiert behandeln und neu aufsetzen; das Löschen des Paketordners genügt nicht. 1, 2
- Zugangsdaten für npm, GitHub, Cloudplattformen, Kubernetes und Vault nur von einem nachweislich sauberen System aus rotieren. 1, 2
- Repositories nach den bekannten Persistenzdateien in den Konfigurationen von Entwicklungsumgebungen und Codeassistenten durchsuchen. 2, 3
- Buildumgebungen auf npm 12 oder neuer aktualisieren und Installationsskripte von Abhängigkeiten nur über eine versionierte, geprüfte allowScripts-Freigabeliste zulassen. Die Freigabeliste mit npm approve-scripts verwalten. Bei älteren npm-Versionen Installationsskripte mit –ignore-scripts deaktivieren und notwendige Ausnahmen kontrolliert freigeben. Native Builds und Pakete mit node-gyp vor Einführung dieser Einschränkungen testen. 12, 14
Länger wirksame Härtung
- Wartefrist für neue Versionen: Frisch publizierte Paketversionen erst nach einer Karenzzeit beziehen, etwa mit min-release-age. Für dringende Sicherheitsupdates einen dokumentierten Ausnahme- und Freigabeprozess vorsehen, beispielsweise mit min-release-age-exclude oder einer zeitlich begrenzten, kontrollierten Lockerung. Die Wartefrist kann auch neue Patch-Versionen zurückhalten. 13
- Egress-Filtering in der Pipeline: Ausgehenden Netzwerkverkehr von Buildsystemen auf notwendige Ziele und Protokolle beschränken. Den verbleibenden Datenverkehr und die angebundenen Dienste zusätzlich auf Anomalien überwachen, etwa ungewöhnliche Uploads, neu angelegte Repositories, unerwartete API-Aufrufe oder neue Ziel-Domains. Egress-Filtering erschwert die Exfiltration, verhindert sie aber nicht vollständig, wenn Angreifer erlaubte Dienste wie GitHub missbrauchen. 1, 2
- Berechtigungen konsequent begrenzen: Token-Berechtigungen minimieren, Freigaben für Workflows und geschützte Umgebungen erzwingen und Branch-Schutzregeln so konfigurieren, dass auch Änderungen von Projektinhabern durch eine zweite Person geprüft werden müssen. 1, 4
- Herkunftsnachweise richtig einordnen: Prüfen, welche Identität, welcher Commit und welcher Workflow attestiert wurden. Diese Angaben mit dem autorisierten Releaseprozess abgleichen, statt lediglich das Vorhandensein einer gültigen Signatur zu prüfen. 1, 2
Fazit
ChainDrop ist kein Einzelfall, sondern der nächste Schritt einer Entwicklung: Früher kaperten Angreifer einzelne Pakete von Hand. Heute verbreitet sich Schadcode mithilfe gestohlener Zugangsdaten selbständig weiter, und zwar in einem Tempo, das rein manuelle Melde-, Triage- und Freigabeketten überfordert. Der Werkzeugkasten des Wurms ist öffentlich verfügbar; Nachahmer sind laut Unit 42 nicht auszuschliessen. 2, 4
Für Organisationen, die Software entwickeln oder einsetzen, verschieben sich damit die Prioritäten. Entscheidend ist nicht mehr nur, ob Abhängigkeiten gescannt werden, sondern ob Build- und Veröffentlichungsprozesse so gestaltet sind, dass ein kompromittiertes Paket nicht automatisch Schlüssel preisgibt, Releases manipuliert und letztlich Kundenumgebungen gefährdet.
Herkunftsnachweise zu prüfen ist weiterhin richtig. Sich allein auf sie zu verlassen, wäre falsch. Denn das Siegel bezeugt, woher ein Paket stammt, und nicht, ob man ihm trauen darf.
Wie die Swiss Infosec AG unterstützt
Wir prüfen Entwicklungs- und Buildumgebungen gezielt auf die hier beschriebenen Angriffspfade. Dazu gehören die Sicherheitsüberprüfung der Buildkette und der Veröffentlichungsprozesse, die Bewertung maschineller Identitäten, der Aufbau einer Governance für Softwarestücklisten (SBOM) und Abhängigkeiten sowie die Vorbereitung auf Lieferkettenvorfälle im Rahmen der Incident Response. Sprechen Sie uns an, auch für eine kurze Ersteinschätzung Ihrer aktuellen Risikosituation.
Kontaktieren Sie uns und erfahren Sie in einem unverbindlichen Beratungsgespräch, was unsere Spezialistinnen und Spezialisten in Cyber- und IT-Sicherheit für Sie tun können: +41 41 984 12 12, infosec@infosec.ch
Swiss Infosec AG; 16.09.2026
Kompetenzzentrum Cyber- und IT Security
Quellen
Die Paket- und Versionszahlen sind Momentaufnahmen aus verschiedenen Erhebungen. Der jeweilige Datenstand ist im Text ausgewiesen.
1. Microsoft Security Blog: ChainDrop supply chain compromise: Anatomy of a self-propagating worm, 04.08.2026.
2. Palo Alto Networks Unit 42: ChainDrop: Inside a Self-Propagating npm Worm, 06.08.2026, abgerufen am 31.08.2026.
3. Elastic Security Labs: Shai-Hulud strikes again: CHAINDROP worm hits 400+ npm packages, 06.08.2026.
4. StepSecurity: ChainDrop npm Worm: Bun-loaded CI/CD credential harvester with Ethereum dead-drop C2, 04.08.2026, aktualisiert am 04.08.2026 um 18.10 Uhr UTC; Zählung: 444 Pakete in 2’212 Versionen.
5. Aikido Security: Keyv and friends compromised in npm supply chain attack, 04.08.2026, aktualisiert am 05.08.2026 um 13.15 Uhr CEST; Zählung: 444 Pakete in 1’381 Versionen.
6. Palo Alto Networks Unit 42: «Shai-Hulud» Worm Compromises npm Ecosystem in Supply Chain Attack, ursprünglich September 2025, aktualisiert bis 03.12.2025; Angaben zur November-Welle vom 25./26.11.2025.
7. Socket: Updated and Ongoing Supply Chain Attack Targets CrowdStrike npm Packages, 16.09.2025; Liste der ersten Shai-Hulud-Welle: 526 bestätigte name@version-Einträge.
8. TrendAI Research (vormals Trend Micro): What We Know About the NPM Supply Chain Attack, 18.09.2025; Namensherkunft «Dune».
9. Europäische Kommission: Cyber Resilience Act: Reporting obligations, Stand 31.07.2026; Meldepflichten ab 11.09.2026.
10. ISO: ISO/IEC 27001:2022, Information security management systems, veröffentlicht 10/2022.
11. ISO/IEC JTC 1/SC 27 Journal: What is Annex A? / Statement of Applicability, Volume 3, Issue 4, Oktober 2023.
12. npm Docs: npm approve-scripts, npm CLI 12.0.2, zuletzt bearbeitet am 23.06.2026.
13. npm Docs: Config, npm CLI 12.0.2; Optionen min-release-age und min-release-age-exclude, zuletzt bearbeitet am 11.02.2026, abgerufen am 31.08.2026.
14. npm Docs: Scripts, npm CLI 12.0.2; Hinweise zu Installationsskripten und nativen Builds, zuletzt bearbeitet am 21.05.2026, abgerufen am 31.08.2026.