ChainDrop kompromittiert seit dem 4. August 2026 zahlreiche npm-Pakete und stiehlt Zugangsdaten aus Entwickler- und CI/CD-Umgebungen. Microsoft beschreibt den Angriff als groß angelegte Supply-Chain-Kampagne mit einer selbstverbreitenden Mini-Shai-Hulud-Variante. Bestätigt sind laut Microsoft mehr als 400 betroffene Pakete, während BleepingComputer und Aikido von deutlich höheren Zahlen bis über 1.300 Paketen berichten. Teams sollten betroffene Installationen als möglichen System- und Credential-Kompromiss behandeln.
Microsoft beschreibt ChainDrop als selbstverbreitenden npm-Wurm
ChainDrop trifft nicht normale Endnutzer über eine klassische App-Installation. Der Angriff richtet sich gegen das JavaScript-Ökosystem rund um npm, Entwicklerrechner und Build-Systeme. Genau dort liegt das Risiko: Ein einzelner kompromittierter Paket-Install kann Zugangsdaten offenlegen, neue Releases vergiften und weitere Projekte in die Kette ziehen.
Für Software-Sicherheit ist der Fall besonders brisant, weil npm-Pakete tief in modernen Web-, Cloud- und KI-Projekten stecken. Viele Anwendungen ziehen Abhängigkeiten transitiv ein. Entwickler installieren also nicht nur bewusst gewählte Pakete, sondern häufig auch Unterabhängigkeiten, die über andere Bibliotheken ins Projekt kommen.
Microsoft Threat Intelligence nennt mehr als 400 betroffene Pakete aus mehreren voneinander unabhängigen Publisher-Umgebungen. Genannt werden unter anderem keyv, flat-cache, cache-manager und weitere Pakete aus verbreiteten Enterprise-Software-Ökosystemen. Die schädlichen Versionen enthalten laut Microsoft eine Mini-Shai-Hulud-Variante, die über einen npm-preinstall-Hook startet.
Dieser Einstieg ist entscheidend. npm führt preinstall-Skripte aus, bevor eine Installation abgeschlossen ist. Die Malware kann also bereits laufen, bevor Tests, Builds oder nachgelagerte Prüfungen greifen. Microsoft beschreibt eine stark verschleierte JavaScript-Nutzlast, die über die Bun-Laufzeit ausgeführt wird und sich je nach Umgebung anders verhält.
Die zentralen Punkte der Angriffskette:
- preinstall-Hook: Die Malware startet automatisch während npm install oder npm ci.
- Bun-Nutzlast: Ein stark verschleiertes JavaScript-Bundle erschwert Analyse und Erkennung.
- Credential Theft: ChainDrop sucht nach npm-, GitHub-, Cloud-, Kubernetes- und Vault-Zugangsdaten.
- CI/CD-Zugriff: In Build-Jobs bleiben Payloads aktiv, um Workflow-Secrets und Runner-Zugangsdaten zu erreichen.
- Wurmverhalten: Gestohlene npm-Tokens können genutzt werden, um weitere Pakete zu verändern und neu zu veröffentlichen.
- Repository-Persistenz: Microsoft beschreibt zusätzlich Manipulationen an Claude- und VS-Code-Konfigurationspfaden.
| Quelle | Genannte Reichweite | Einordnung |
|---|---|---|
| Microsoft Security Research | mehr als 400 Pakete | konservative Primäranalyse mit technischer Angriffskette |
| BleepingComputer | mehr als 1.300 Pakete und rund 2 Milliarden monatliche Downloads | breitere Berichtsgröße mit laufender Auswertung |
| Aikido laut BleepingComputer | mindestens 868 Pakete in 1.381 Versionen | Paket- und Versionszählung aus Sicherheitsanalyse |
| StepSecurity | 444 Pakete und 2.212 Versionen | eigene Zählung vergifteter Pakete und Versionen |
Die unterschiedlichen Zahlen widersprechen sich nicht zwingend. Bei aktiven npm-Vorfällen zählen Forscher verschiedene Ebenen: einzelne Paketnamen, veröffentlichte Paketversionen, transitive Abhängigkeiten, betroffene Maintainer und Organisationen. Microsoft bleibt in der Primäranalyse bei mehr als 400 Paketen. BleepingComputer nennt mehr als 1.300 Pakete und verweist auf laufende Listen mehrerer Sicherheitsfirmen.
BleepingComputer nennt Keyv, Cacheable, flat-cache und file-entry-cache als prominente Beispiele. Der Angriff soll nach der Kompromittierung des GitHub-Kontos eines Keyv-Maintainers begonnen haben und sich anschließend auf Pakete weiterer Organisationen ausgebreitet haben. Genannt werden unter anderem Deliveroo, Ornikar, OneReach, Picsart, Qlik und ServiceTitan.
Besonders gefährlich ist die Kombination aus legitimer Herkunft und schädlichem Inhalt. Einige Pakete wurden über normale GitHub-Actions-Workflows gebaut und veröffentlicht. Dadurch konnten kompromittierte Releases gültige Provenance-Informationen tragen. Für Verteidiger reicht es deshalb nicht, nur auf den Namen eines bekannten Projekts oder eine formal korrekte Veröffentlichung zu vertrauen.
Der Vorfall reiht sich in eine Serie schwerer Angriffe auf Entwickler-Ökosysteme ein. Microsoft hatte zuletzt bereits mehrere npm-Kampagnen analysiert, darunter Angriffe auf KI- und Entwicklerpakete. Auch die Abschaltung von GitHub Models zeigte, wie stark Entwicklerplattformen inzwischen im Zentrum strategischer Produkt- und Sicherheitsentscheidungen stehen.
Betroffene Systeme brauchen mehr als ein Paket-Update
Der wichtigste operative Punkt: Ein bereinigtes package.json reicht nicht aus. Microsoft empfiehlt, betroffene Entwicklerrechner oder Build-Runner als potenziell kompromittiert zu behandeln, wenn dort ein betroffenes Paket mit aktivierten Lifecycle-Skripten installiert wurde. Das gilt auch dann, wenn das Paket später entfernt oder durch eine saubere Version ersetzt wurde.
Die Sofortmaßnahmen lassen sich in drei Ebenen gliedern:
- Abhängigkeiten prüfen: Lockfiles, Dependency Trees, Artefakt-Repositories, npm- und Yarn-Caches sowie CI-Caches auf betroffene Paketversionen kontrollieren.
- Zugangsdaten rotieren: npm-Tokens, GitHub-Tokens, Cloud-Schlüssel, SSH-Keys, Kubernetes-Zugänge, Vault-Tokens und CI/CD-Secrets von einem sauberen System aus ersetzen.
- Build-Umgebung neu aufsetzen: Persistente Runner, Entwicklergeräte, Container-Basisimages und Golden Images aus vertrauenswürdigen Quellen neu erstellen.
| Bereich | Risiko durch ChainDrop | Empfohlene Reaktion |
|---|---|---|
| Entwicklergerät | lokale Tokens, SSH-Schlüssel und Konfigurationsdateien können gestohlen werden | isolieren, untersuchen, neu aufsetzen |
| CI/CD-Runner | Workflow-Secrets und OIDC-Publishing können offengelegt werden | Secrets rotieren und Runner ersetzen |
| npm-Publisherkonto | weitere Pakete können vergiftet veröffentlicht werden | Releases prüfen und Tokenrechte reduzieren |
| GitHub-Repositories | Konfigurationsdateien für Claude und VS Code können manipuliert werden | unerwartete Commits, Branches und Workflow-Änderungen suchen |
| Cloud-Umgebung | AWS, Kubernetes, Vault und andere Dienste können ausgespäht werden | Zugriffslogs und Secret-Store-Abrufe kontrollieren |
Microsoft nennt außerdem konkrete Schutzmaßnahmen für die npm-Seite. Teams sollen npm CLI 12 und die min-release-age-Funktion prüfen, bekannte gute Versionen pinnen und Caches leeren. Die Idee dahinter ist einfach: Frisch veröffentlichte Paketversionen sollen nicht sofort automatisch in kritische Builds fließen. Ein kurzer Verzögerungspuffer kann bei Supply-Chain-Angriffen entscheidend sein, weil Sicherheitsfirmen viele bösartige Veröffentlichungen innerhalb der ersten Stunden erkennen.
Auch npm install-Skripte müssen neu bewertet werden. Lifecycle-Skripte sind im JavaScript-Ökosystem verbreitet und nicht grundsätzlich bösartig. Sie bauen native Komponenten, erzeugen Dateien oder bereiten Pakete vor. ChainDrop zeigt aber erneut, dass genau diese Mechanik ein direkter Ausführungspfad für Malware ist. In CI/CD-Pipelines kann npm ci mit deaktivierten Skripten für viele Projekte ein sinnvoller Standard sein, sofern Builds dadurch nicht brechen.
Für Security-Teams zählt jetzt die Rückwärtssuche. Entscheidend ist nicht nur, ob eine Anwendung aktuell eine saubere Version nutzt. Wichtig ist, ob ein Entwicklerrechner oder Runner am 4. oder 5. August eine kompromittierte Version gezogen hat. Logs von npm, Paketmanagern, Proxys, Artifact-Repositories, GitHub Actions und EDR-Systemen werden damit zur Grundlage der Bewertung.
Microsoft Defender erkennt mehrere Muster der Kampagne. Dazu gehören verdächtige Node.js-Prozesse, Bun-Aktivität, schädliche npm-Pakete, Credential-Zugriffe und Hinweise auf npm-Supply-Chain-Aktivität in Cloud-Umgebungen. Die Microsoft-Analyse enthält zudem Hunting Queries für Defender-XDR-Kunden. Organisationen ohne Microsoft-Stack sollten dieselben Verhaltensmuster mit ihren eigenen EDR-, SIEM- und Netzwerkdaten suchen.
Der Angriff zeigt auch eine neue Nähe zwischen Entwicklerwerkzeugen und KI-Umgebungen. Microsoft beschreibt Manipulationen an .claude– und .vscode-Konfigurationspfaden. Dadurch entsteht ein zusätzlicher Infektionsweg über spätere Entwickleraktivitäten. Das passt zu einem breiteren Trend, bei dem Angreifer nicht nur klassische Build-Systeme, sondern auch KI-Coding-Tools und Editor-Workflows ins Visier nehmen. Der Anthropic-Fall mit KI-Angriffen auf reale Unternehmen zeigte bereits, wie stark KI-Werkzeuge und reale Sicherheitsprozesse zusammenrücken.
Für einzelne Entwickler ist die praktische Grenze klar: Wer nur eine Anwendung nutzt, die intern irgendwann ein betroffenes npm-Paket einsetzt, muss nicht automatisch selbst handeln. Wer aber am betroffenen Zeitraum Pakete installiert, Builds ausgeführt oder Releases veröffentlicht hat, sollte Lockfiles und lokale Installationen prüfen. Bei Treffer zählt nicht nur Paketwechsel, sondern Credential-Rotation.
Für Unternehmen ist ChainDrop ein Incident-Response-Fall, kein normales Dependency-Update. Die Paketlisten werden weiter aktualisiert. Die Reichweitenzahlen können sich deshalb noch verändern. Belastbar ist bereits jetzt: ChainDrop nutzt npm-Installationen als Einstieg, stiehlt Entwickler- und CI/CD-Geheimnisse und kann über gestohlene Publishing-Rechte weitere Pakete infizieren. Die Priorität liegt auf Lockfile-Prüfung, Cache-Bereinigung, sauberem Rebuild und konsequenter Rotation aller potenziell erreichbaren Zugangsdaten.