Veröffentlicht am 16.08.2026
Am 4. August 2026 reichte bei zahlreichen Software-Projekten ein einziger, an sich harmloser Befehl aus, um Zugangsdaten zu stehlen: npm install. Dieser Befehl lädt bei Node.js-Projekten die benötigten Programmbibliotheken herunter – und genau dieser Installationsvorgang wurde zur Waffe. Ein selbstverbreitender Schädling mit dem Namen ChainDrop hatte sich in mehr als 400 npm-Pakete eingenistet. Wer eines der befallenen Pakete installierte, führte ohne Zutun bösartigen Code aus – kein Anwendungsstart, kein Import, kein Klick nötig.
Das Besondere und Gefährliche: ChainDrop stahl nicht nur Passwörter und Schlüssel, sondern nutzte gestohlene Veröffentlichungsrechte, um sich selbst in weitere Pakete zu kopieren. Ein Wurm im wahrsten Sinne. Sicherheitsforscher von Snyk stellen klar:
„This is an active software supply chain incident, not a proof of concept.“ – Snyk Security Research (Liran Tal und Lion Kontorer)
Auf Deutsch: Das ist ein realer, aktiv ausgenutzter Angriff auf die Software-Lieferkette – kein theoretisches Laborszenario. Dieser Artikel erklärt in verständlicher Form, was geschah, ob Ihr Unternehmen betroffen sein könnte und was jetzt konkret zu tun ist.
npm ist die weltweit größte Sammelstelle für JavaScript-Software-Bausteine. Fast jede moderne Website, jeder Online-Shop und jedes Content-Management-System, das auf JavaScript oder Node.js aufbaut, greift beim Bauen oder Betreiben indirekt auf npm-Pakete zurück – oft auf Hunderte gleichzeitig.
Am 4. August 2026 wurde diese Vertrauensbeziehung ausgenutzt. Laut Microsoft Threat Intelligence gelangten Angreifer zunächst über gestohlene Zugangsdaten eines Paketverwalters (Maintainer) an die Kontrolle über beliebte Pakete rund um die Bibliothek keyv und die sogenannte cacheable-Familie. Snyk bestätigte unabhängig zunächst elf bösartige Veröffentlichungen. Microsoft dokumentierte insgesamt mehr als 400 kompromittierte Pakete über mehrere, voneinander unabhängige Herausgeber.
Der zeitliche Ablauf war rasant: Um 09:35 UTC erschien die manipulierte Version keyv@6.0.0. Zwischen 10:09 und 10:28 UTC folgten zehn weitere vergiftete Versionen. Ein Snapshot von StepSecurity vom selben Tag zählte bereits 444 Pakete und 2.212 vergiftete Versionen. Die Cyber Security Agency of Singapore (CSA) sprach zwei Tage später von mehr als 1.300 betroffenen Paketversionen.
Ein häufiges Missverständnis: Die genannten Zahlen beschreiben die Reichweite im npm-Ökosystem – also wie viele Pakete manipuliert wurden und wie oft sie üblicherweise heruntergeladen werden. Sie sagen nichts darüber aus, wie viele Unternehmen, Systeme oder Datensätze tatsächlich kompromittiert wurden. Es gibt keine bestätigte öffentliche Zahl betroffener Organisationen oder personenbezogener Datensätze. Aussagen wie „zwei Milliarden Betroffene“ sind schlicht falsch – die zwei Milliarden beziehen sich auf monatliche Downloads, nicht auf Opfer.
npm-Pakete dürfen sogenannte Lifecycle-Skripte mitbringen – kleine Programme, die automatisch ausgeführt werden, etwa direkt beim Installieren. Ein solches Skript heißt preinstall. Die manipulierten Pakete ergänzten genau diesen Eintrag: "preinstall": "node setup.mjs".
Das bedeutet: Sobald jemand das Paket installierte, startete automatisch die Datei setup.mjs – ein stark verschleiertes (obfuskiertes) Ladeprogramm. Der Anwender musste die Bibliothek weder in seinen Code einbinden noch die Anwendung starten. Der bloße Installationsbefehl reichte. Das verschleierte Programm lud anschließend eine zweite, auf der Laufzeitumgebung Bun basierende Schadstufe nach.
ChainDrop unterschied gezielt zwischen den Rechnern von Entwicklern und automatisierten Bausystemen (sogenannte CI/CD-Runner, die Code bauen und ausrollen). Er durchsuchte Dateien, Umgebungsvariablen und Kommandozeilenwerkzeuge nach Zugangsdaten für:
Die gesammelten Daten wurden verpackt, komprimiert und mit dem starken Verfahren AES-256-GCM verschlüsselt an Angreifer-Infrastruktur übertragen – unter anderem an die Domain npm-cache[.]com.
Fand ChainDrop einen npm-Token mit Schreibrecht, wurde es richtig gefährlich. Microsoft-Forscher fassen es so zusammen:
„The payload’s most significant capability is automated propagation.“ – Microsoft Security Research
Die wichtigste Fähigkeit war also die automatische Weiterverbreitung: Der Schädling ermittelte, welche weiteren Pakete das Opfer veröffentlichen durfte, lud diese herunter, schleuste seinen preinstall-Hook und die Schadfracht ein, erhöhte die Versionsnummer und veröffentlichte die manipulierten Pakete erneut. So pflanzte sich der Angriff eigenständig fort.
Ein besonders ernüchternder Befund: Einige manipulierte Veröffentlichungen trugen gültige Herkunftsnachweise (sogenannte Provenance über GitHub-Actions). Das klingt vertrauenswürdig, ist aber trügerisch. StepSecurity formuliert es treffend:
„Provenance proves which commit was built. It cannot prove the commit was authorized.“ – StepSecurity / Sai Likhith
Sinngemäß: Der Herkunftsnachweis belegt nur, welcher Codestand gebaut wurde – nicht, ob dieser Code autorisiert oder harmlos war. Wenn der reguläre Bauprozess bereits kompromittierten Code verarbeitet, sieht die Herkunft sauber aus, obwohl sie es nicht ist.
Für deutsche kleine und mittlere Unternehmen gilt: Betroffen ist, wer Node.js/npm einsetzt – direkt oder über einen Dienstleister. Das betrifft insbesondere:
Besonders kritisch sind Entwickler-Rechner und Bau-Server, weil dort häufig Zugangsdaten zu GitHub, Cloud, Datenbanken und Produktivsystemen liegen – genau das Beutegut von ChainDrop.
Entwarnung – aber mit Einschränkung: Eine reine statische Website oder ein klassischer WordPress-/PHP-Auftritt ohne npm-Build ist über diesen Installationsweg nicht unmittelbar betroffen. Dennoch kann ein indirektes Risiko bestehen, wenn Ihr Deployment oder ein eingebundener Dienstleister npm nutzt.
npm ls keyv flat-cache file-entry-cache cacheable-request cacheable @cacheable/utils cache-manager @cacheable/net @cacheable/node-cache @cacheable/memory ecto --allkeyv@6.0.0, @cacheable/net@2.1.1, @cacheable/node-cache@3.1.2, cacheable@2.5.1, flat-cache@6.1.24, @cacheable/memory@2.2.1, cacheable-request@13.0.20, file-entry-cache@11.1.6, @cacheable/utils@2.5.1, cache-manager@7.2.10 und ecto@5.0.1. Prüfen Sie auch transitive (indirekte) Abhängigkeiten, CI-Caches und bereits gebaute Container.node_modules/**/package.json nach "preinstall": "node setup.mjs" sowie nach den Dateien setup.mjs, Math_Symbol.js oder math_init.js. Vergleichen Sie deren SHA-256-Prüfsummen mit den veröffentlichten Indikatoren, etwa 54dc7ea54a1317cca0e890a2770630cf7fa6c97813e0cb9d2caa93012b350668 für setup.mjs.node setup.mjs, einem danach gestarteten bun-Prozess, temporären Verzeichnissen bun-dl-* oder Verbindungen zu bekannten Domains. Microsoft stellt konkrete Suchabfragen für Defender XDR bereit.~/.local/bin/gh-token-monitor.sh, unerwartete .claude/settings.json, .vscode/tasks.json sowie neue, ungeklärte Veröffentlichungen und Workflow-Änderungen in GitHub.Merke: Ein Eintrag im Lockfile beweist noch keine Ausführung von Schadcode – umgekehrt ist ein fehlender Alarm kein Freispruch.
gh-token-monitor und andere Persistenzmechanismen. Achtung: Snyk warnt, dass das Widerrufen eines beobachteten GitHub-Tokens eine hinterlegte Aktion auslösen kann. Die Bereinigung gehört idealerweise in die Hände eines Incident-Response-Teams.keyv@5.6.0, flat-cache@6.1.23, file-entry-cache@11.1.5, cacheable-request@13.0.19, cacheable@2.5.0, cache-manager@7.2.9 und ecto@5.0.0. Der dokumentierte Ablauf: npm install --package-lock-only --ignore-scripts, dann rm -rf node_modules, npm cache clean --force und npm ci --ignore-scripts. Prüfen Sie zuvor die Kompatibilität.allowScripts-Freigabeliste ein. Diese Version wurde am 8. Juli 2026 veröffentlicht und blockiert Lifecycle-Skripte von Abhängigkeiten standardmäßig. Installieren Sie in CI grundsätzlich ohne Lifecycle-Skripte, nutzen Sie exakte Versionen und Lockfiles, vergeben Sie Tokens minimal, vermeiden Sie 2FA-Umgehungen und aktivieren Sie phishing-resistente Mehr-Faktor-Anmeldung.Wichtig: npm 12 ist eine präventive Schutzfunktion, kein ChainDrop-spezifischer Patch. Sie ersetzt keine forensische Untersuchung eines bereits erfolgten Installationsvorgangs. Einen einzelnen Hersteller-Patch für eine CVE gibt es hier nicht – ChainDrop ist eine kompromittierte Lieferkette, keine klassische Softwarelücke.
ChainDrop ist nicht automatisch eine meldepflichtige Datenpanne. Zur Datenschutzverletzung im Sinne der DSGVO wird der Vorfall erst, wenn ein kompromittierter Entwickler-PC oder CI-Runner personenbezogene Daten, Datenbankzugänge oder Secrets mit Zugriff auf personenbezogene Daten erreichen konnte.
Die LDI NRW fasst die Schwelle klar zusammen: Jede Verletzung ist intern zu dokumentieren. Besteht voraussichtlich mehr als nur ein geringes Risiko für die Rechte und Freiheiten natürlicher Personen, muss die zuständige Aufsichtsbehörde unverzüglich und möglichst binnen 72 Stunden informiert werden (Art. 33 DSGVO). Bei voraussichtlich hohem Risiko sind zusätzlich die Betroffenen zu benachrichtigen (Art. 34). Ein Auftragsverarbeiter – etwa Ihre Agentur – muss den Verantwortlichen unverzüglich informieren.
Art. 32 DSGVO verlangt angemessene technische und organisatorische Maßnahmen zur Sicherheit der Verarbeitung. Verstöße gegen die in Art. 83 Abs. 4 genannten Pflichten können mit Geldbußen bis zu 10 Mio. EUR oder 2 % des weltweiten Jahresumsatzes geahndet werden – je nachdem, welcher Betrag höher ist. Die konkrete Höhe ist stets einzelfallabhängig. Dass Aufsichtsbehörden Art. 32 ernst nehmen, zeigt ein früherer Fall: Der LfDI Baden-Württemberg verhängte 2020 gegen die AOK Baden-Württemberg 1,24 Mio. EUR wegen unzureichender Maßnahmen. Dessen damaliger Leiter Dr. Stefan Brink betonte:
„Datensicherheit ist eine Daueraufgabe. Technische und organisatorische Maßnahmen sind regelmäßig den tatsächlichen Verhältnissen anzupassen, um auf Dauer ein angemessenes Schutzniveau sicherzustellen.“
Der AOK-Fall ist kein Supply-Chain-Fall und keine Prognose für ChainDrop – er belegt aber die Erwartung der Aufsicht: dokumentierte Entscheidungswege, zügige Eindämmung, belastbare Risikoanalyse und nachweisbare Abhilfe. Bei konkretem Verdacht sollten Datenschutzbeauftragte und spezialisierte rechtliche Beratung früh eingebunden werden.
ChainDrop ist ein Lehrstück moderner Angriffe: Nicht ein Programmierfehler, sondern die Vertrauenskette selbst wurde missbraucht. Die reine Installation eines Pakets genügte, um Zugangsdaten zu stehlen – und gestohlene Veröffentlichungsrechte machten aus einem Einzelfall einen sich selbst verbreitenden Wurm. Die CSA Singapur stuft den Vorfall als aktiven Supply-Chain-Angriff ein; die Ausnutzung erfolgt real und in freier Wildbahn.
Für Ihr Unternehmen bedeutet das: Wenn npm/Node.js irgendwo in Ihrem Build, Deployment oder bei einem Dienstleister im Spiel ist, hat die Prüfung hohe Priorität – bei einem konkreten Versionsnachweis handeln Sie sofort. Ein reiner statischer oder PHP-Auftritt ohne npm ist über diesen Weg nicht unmittelbar betroffen, doch prüfen Sie das indirekte Risiko über Ihre Dienstleister.
Und bewahren Sie einen kühlen Kopf: Die kursierenden Zahlen beschreiben Reichweite, nicht Opfer. Eine sachliche, gut dokumentierte Prüfung Ihrer eigenen Umgebung ist mehr wert als jede Schlagzeile. Genau dabei unterstützen wir Sie – melden Sie sich, wenn Sie Ihre Build-Pipeline und Ihre npm-Abhängigkeiten sicher überprüfen lassen möchten.