ChainDrop: Der „Keyv“- und „Cacheable“-Angriff auf die npm-Lieferkette

Am 4. August 2026 traf ein ausgeklügelter Angriff auf die Software-Lieferkette namens „ChainDrop“ das npm-Ökosystem , nachdem das GitHub-Konto eines Betreuers der weit verbreiteten Open-Source-Pakete „Keyv“ und „Cacheable“ kompromittiert worden war . Der daraus resultierende, sich selbst verbreitende Wurm breitete sich auf über 2.251 Versionen von 452 verschiedenen Paketen mit monatlich rund 2 Milliarden Downloads aus und betraf Unternehmen wie Deliveroo, Ornikar, OneReach, Picsart, Qlik und ServiceTitan.

„Keyv“ ist ein einfacher Schlüssel-Wert-Speicher für Node.js mit Unterstützung für mehrere Backends, während „Cacheable“ das zugrunde liegende HTTP-Cache-Framework darstellt. Zusammen dienen diese Pakete als grundlegende Caching-Infrastruktur im gesamten JavaScript-Ökosystem. Beide Pakete werden von demselben Entwickler gepflegt, dessen GitHub-Konto vom Angreifer kompromittiert wurde.

Der Angreifer veröffentlichte die erste schädliche Version, „keyv@6.0.0“, am 4. August 2026 gegen 9:00 Uhr UTC. Die Malware ist ein Ableger der „Mini“-Shai-Hulud-Familie; eine Zuordnung zu TeamPCP ist bislang unbestätigt. Der Wurm verbreitete sich rasch, indem er npm- und GitHub-Tokens aus kompromittierten Umgebungen sammelte und diese nutzte, um weitere manipulierte Versionen zu veröffentlichen. Socket identifizierte 2 .251 manipulierte Versionen in 452 Paketen.

Die Payload stiehlt eine umfassende Bandbreite sensibler Daten, darunter Cloud-Anmeldedaten, CI/CD-Geheimnisse, Entwickler-Token, KI-Konfigurationsdateien und Kryptowährungs-Wallets .Außerdem platziert sie Claude-Code- und Visual-Studio-Code-Hooks für eine dauerhafte Ausführung innerhalb der IDE. Zum Zeitpunkt der Erstellung dieses Artikels wurden dieser Kampagne noch keine CVE-Kennungen zugewiesen.

Übersicht über die Sicherheitslücken

Erster Zugriff

Der Angreifer kompromittierte das GitHub-Konto des Keyv-Betreuers und verschaffte sich so direkten Push-Zugriff auf die Quellcode-Repositorys für Keyv, Cacheable, cache-manager, flat-cache, file-entry-cache sowie zahlreiche verwandte Pakete innerhalb des Monorepos des Betreuers.

Böswillige Veröffentlichung

Ab 9:00 Uhr UTC fügte der Angreifer dem Keyv-Repository Persistenz-Payloads für IDEs hinzu und veröffentlichte anschließend „keyv@6.0.0“ sowie nachfolgende bösartige Versionen. Da die Pakete über ihre legitimen GitHub-Actions-Workflows erstellt und veröffentlicht wurden , enthielten die kompromittierten Releases gültige SLSA-Herkunftsinformationen, wodurch die Kontrollen zur Integritätsprüfung umgangen wurden. Jedes manipulierte Paket enthielt in seiner `package.json` einen Eintrag „preinstall“: „node setup.mjs“, wodurch der Dropper automatisch ausgeführt wurde, bevor ein `npm install` abgeschlossen war.

Verbreitung des Wurms

Die Fähigkeit der Malware zur Selbstverbreitung ermöglichte es ihr, Pakete anderer Betreuerzu infizieren , deren Projekte von einem zuvor kompromittierten Paket abhängig waren. Durch das Sammeln gültiger npm-Veröffentlichungstoken von CI/CD-Runner-Systemen und Entwickler-Workstations veröffentlichte der Wurm nachgelagerte Pakete mit der eingeschleusten schädlichen Nutzlast erneut und erzeugte so eine kaskadierende Kette von Kompromittierungen. Dieser Mechanismus ermöglichte es dem Angriff, den ursprünglichen Keyv/Cacheable-Namespace zu verlassen und sich über Organisationsgrenzen hinweg auszubreiten.

Betroffene Pakete

Zu den wichtigsten kompromittierten Paketen gehörten:

Der Wurm breitete sich anschließend auf Pakete innerhalb von Organisationen wie Ornikar aus (darunter @ornikar/eslint-config-*, @ornikar/prettier-config, @ornikar/babel-preset-* und viele weitere), Qlik (@nebula.js/nucleus), HubSync (@hubsync/web-sdk-react) und zahlreiche andere. Eine vollständige, kontinuierlich aktualisierte Liste wird von Wiz Research in ihrem öffentlichen GitHub-Repository geführt.

Wichtig: Die npm-Registry hat sich während des Vorfalls rasch verändert. Am 4. August um 17:40 Uhr IST wurden für mindestens neun Kernpakete, darunter keyv@5.6.0, flat-cache@6.1.23 und cache-manager@7.2.9, frühere, fehlerfreie Versionen als aktuellste Versionen wiederhergestellt. Unternehmen müssen die Betroffenheit anhand der genauen Paketversionen überprüfen, die in den Lockfiles aufgeführt sind, und nicht anhand der aktuellen Registry-Tags.

Malware-Analyse

Übersicht über die Payload

Die Malware wird in einer zweistufigen Architektur bereitgestellt:

Stufe 1 – setup.mjs (Dropper): Dieses schlanke Node.js-Skript dient als anfängliche Payload. Es prüft, ob die Bun-JavaScript-Laufzeitumgebung vorhanden ist, und lädt, falls nicht, Bun v1.3.13 aus den offiziellen GitHub-Releases herunter. Anschließend übergibt es die Ausführung an das Haupt-Infostealer-Bundle, bevor es das temporäre Laufzeitverzeichnis löscht, um die forensischen Spuren zu minimieren.

Stufe 2 – Math_Symbol.js / math_init.js (Infostealer): Ein stark verschleiertes, 727.680 Byte großes kompiliertes Bundle, das über die Bun-Laufzeitumgebung ausgeführt wird. Dies ist die zentrale Engine zum Ausspähen von Anmeldedaten. Beide Dateinamen (Math_Symbol.js und math_init.js) wurden in freier Wildbahn beobachtet und enthalten identische Funktionalität mit demselben SHA-1-Hash.

Ziele des Anmelde- und Passwortdiebstahls

Der Infostealer listet systematisch folgende Daten auf und exfiltriert sie:

• Cloud-Anmeldedaten: AWS-Zugriffsschlüssel, SSM-Parameter-Store-Werte (mit „WithDecryption: true“), AWS Secrets Manager-Geheimnisse, Azure- und GCP-Anmeldedaten
• CI/CD-Geheimnisse: GitHub-Actions-Geheimnisse, einschließlich der Extraktion von „isSecret":true“-Werten aus dem Speicher selbst gehosteter Runner, GitHub-Workflow-Token
• Entwickler-Token: GitHub Personal Access Tokens (Präfixe „ghp_“, „gho_“, „ghs_“), npm-Publishing-Token (Präfix „npm_“), wobei jedes Token vor der Exfiltration in Echtzeit gegen registry.npmjs.org/-/whoami validiert wird
• Infrastruktur-Geheimnisse: Kubernetes-Geheimnisse aus allen zugänglichen Namespaces, HashiCorp-Vault-Token und KV-Geheimnisse, Terraform-Anmeldedaten, SSH-Schlüssel, Datenbank-Verbindungszeichenfolgen
• KI- und IDE-Konfiguration: Claude-API-Konfigurationsdateien, Anmeldedaten für KI-bezogene Dienste
• Kryptowährungs-Wallets: Lokale Wallet-Dateien und Schlüssel
• Anmeldedaten für Dienste: API-Schlüssel von Stripe, Slack, Twilio und anderen Drittanbietern
• Komplette Prozessumgebung: Alle Umgebungsvariablen des kompromittierten Prozesses

Persistenzmechanismen

Das Keyv-Repository enthielt separate Hooks für Claude Code (.claude/settings.json) und Visual Studio Code (.vscode/). Diese Persistenzmechanismen auf IDE-Ebene können die Payload ausführen, sobald ein Benutzer dem Arbeitsbereich vertraut oder die Projektkonfiguration zulässt, und bieten so einen sekundären Ausführungspfad, der unabhängig von den Lebenszyklus-Skripten von „npm install“ ist.

Die Malware installiert zudem einen Watcher zur Überwachung des Widerrufs von Anmeldedaten – eine Falle, die bei der Rotation von Tokens einen vom Angreifer bereitgestellten lokalen Handler auslöst. Betroffene müssen diesen Watcher entfernen, bevor sie Anmeldedaten rotieren.

Befehls- und Kontrollsystem

Die Malware ruft ihre C2-Domains über einen „eth_call“ aus einem Ethereum-Smart-Contract (StringListStore) ab, anstatt sie in die Nutzlast einzubetten. Diese Blockchain-basierte C2-Auflösung ermöglicht es dem Betreiber, die Infrastruktur zu aktualisieren, ohne die Malware ändern zu müssen. Die On-Chain-Historie zeigt, dass der Vertrag ursprünglich mit drei Domänen konfiguriert war, bevor er so aktualisiert wurde, dass er nur noch npm-cache[.]com zurückgibt. Der Vertragsinhaber wurde von einer Adresse finanziert, die zuvor wegen Betrugsaktivitäten markiert worden war.

Exfiltration

Gestohlene Daten werden mit einem hybriden AES-256- und RSA-4096-Verfahren verschlüsselt und anschließend über zwei Kanäle exfiltriert:

• Öffentliche GitHub-Repositorys, die unter kompromittierten Identitäten erstellt wurden und die Beschreibung „Shai-Hulud: Here We Go Again“ tragen
• Die Domain npm-cache[.]com

Die ersten Commits in den Exfiltrations-Repositories enthalten die Drohung: „IfYouBlockThisAPIKeyItWillCrashTheLiveProductionServersOfAllThirdPartyClients.“

Bekannte Indikatoren für eine Kompromittierung (IoCs)

Erkennung und Bedrohungssuche

Sicherheitsteams sollten die folgenden Erkennungsmaßnahmen umsetzen:

• Abhängigkeitsprüfung: ScannenSie alle „package-lock.json“, „yarn.lock“, „pnpm-lock.yaml“ und „bun.lockb“-Dateien auf betroffene Pakete und Versionen. Verlassen Sie sich nicht auf aktuelle Registry-Tags – verwenden Sie ausschließlich die in den Lockfiles festgelegten Versionen.
• Dateisystem-Indikatoren: Durchsuchen Sie Entwicklungsarbeitsplätze, CI/CD-Runner und Build-Server nach den Dateien „Math_Symbol.js“, „math_init.js“ und „setup.mjs“ in den „node_modules“-Verzeichnissen sowie in temporären Verzeichnissen, die dem Muster „/tmp/bun-dl-*/“ entsprechen.
• Netzwerküberwachung: Lösen Sie Warnmeldungen bei ausgehenden Verbindungen und DNS-Abfragen an npm-cache[.]com, pypi-get[.]com, js-mirror[.]com sowie an die in den oben genannten IOCs aufgeführten Ethereum-RPC-Endpunkte aus. Achten Sie auf die User-Agent-Zeichenkette „Bun/1.3.13“.
• GitHub-Prüfung: Überprüfen Sie Organisationen auf unerwartete öffentliche Repositorys mit der Beschreibung „Shai-Hulud: Here We Go Again“ oder auf Commits, die die Einschüchterungszeichenfolge enthalten.
• Überwachung von Preinstall-Skripten: Überprüfen Sie die „package.json“-Dateien in allen Projekten auf unerwartete Einträge in Preinstall-Skripten, die auf „setup.mjs“ verweisen.
• Vertrauenswürdigkeit des IDE-Arbeitsbereichs: Überprüfen Sie auf nicht autorisierte .claude/settings.json- und .vscode/-Konfigurationen, die möglicherweise externe Payloads laden könnten.

Abhilfemaßnahmen und Behebungen

Sofortmaßnahmen

• Betroffene Versionen identifizieren und entfernen: Überprüfen Sie alle Umgebungen und entfernen Sie alle Installationen der bösartigen Paketversionen. Führen Sie ein Upgrade auf saubere, verifizierte Versionen durch.
• Entfernen Sie zuerst den Watcher für die Sperrung von Anmeldedaten: Führen Sie keine Token-Rotation durch, bevor Sie die Malware entfernt haben. Die Payload installiert einen Watcher, der bei der Sperrung von Token ausgelöst wird. Eine vorzeitige Rotation der Anmeldedaten kann zur Ausführung eines vom Angreifer bereitgestellten Handlers führen. Beseitigen Sie die Malware vollständig von den betroffenen Systemen, bevor Sie mit der Rotation der Anmeldedaten fortfahren.
• Gehen Sie von einer vollständigen Kompromittierung der Anmeldedaten aus: Wenn eine betroffene Version installiert war, behandeln Sie alle Anmeldedaten, auf die diese Umgebung Zugriff hat, als gestohlen. Dazu gehören Cloud-Anmeldedaten, npm-Token, GitHub-PATs, SSH-Schlüssel, CI/CD-Geheimnisse, Datenbank-Anmeldedaten und API-Schlüssel von Drittanbietern.
• Rotieren Sie alle kompromittierten Anmeldedaten: Führen Sie nach der Entfernung der Malware folgende Rotation durch: alle npm-Publishing-Token, GitHub-Personal-Access-Token und OAuth-Token, AWS-IAM-Zugriffsschlüssel, Anmeldedaten für Azure- und GCP-Dienstprinzipale, Kubernetes-Dienstkontotoken, HashiCorp-Vault-Token, Datenbankpasswörter, SSH-Schlüssel sowie API-Schlüssel von Drittanbietern (Stripe, Slack, Twilio usw.).
• npm-/GitHub-Token widerrufen und neu ausstellen: Verwenden Sie die npm- und GitHub-Admin-Konsolen, um alle potenziell kompromittierten Token zwangsweise zu widerrufen. Generieren Sie neue Token mit den minimal erforderlichen Berechtigungsumfängen.

Systemwiederherstellung

• Betroffene Systeme neu aufsetzen: Behandeln Sie jede Entwicklungsworkstation, jeden CI/CD-Runner oder jeden Build-Server, auf dem ein schädliches Paket installiert wurde, als potenziell kompromittiert. Führen Sie eine Neuinstallation anhand eines bekanntermaßen sauberen Images oder Snapshots durch.
• Lokale Caches bereinigen: Leeren Sie den npm-Cache (npm cache clean --force), den Yarn-Cache, den pnpm-Store und den Bun-Cache, um zwischengespeicherte schädliche Pakete zu entfernen.
• Virtuelle Umgebungen löschen und neu erstellen: Führen Sie nicht einfach ein Downgrade der betroffenen Pakete durch. Löschen Sie die „node_modules“-Verzeichnisse und erstellen Sie die virtuellen Python-Umgebungen vollständig neu.

Überprüfung der Cloud-Umgebungen und des Quellcodes

• Überprüfen Sie Cloud-Umgebungen: Durchsuchen Sie AWS CloudTrail, Azure-Aktivitätsprotokolle und GCP-Audit-Protokolle auf unbefugte API-Aufrufe, die aus dem Zeitraum der Paketinstallation stammen. Achten Sie auf unerwartete Erstellungen von IAM-Benutzern oder -Rollen, auf Zugriff auf den SSM-Parameterspeicher mit Entschlüsselung sowie auf Zugriff auf den Secrets Manager.
• GitHub-Audit-Protokolle überprüfen: Untersuchen Sie die Audit-Protokolle Ihrer Organisation auf unerwartete Repository-Erstellungen, Token-Generierungen und Workflow-Änderungen.
• Nach Repositorys zur Datenexfiltration suchen: Suchen Sie nach öffentlichen Repositorys, die unter den Identitäten Ihrer Organisation mit der Beschreibung „Shai-Hulud: Here We Go Again“ erstellt wurden.

Absicherung der Lieferkette

• Fixieren Sie Abhängigkeiten: Verwenden Sie in allen „package.json“-Dateien exakte Versionsangaben und committen Sie Lockfiles in die Versionskontrolle.
• Upgrade auf npm 12: npm 12 blockiert standardmäßig nicht genehmigte Skripte für den Lebenszyklus von Abhängigkeiten und verhindert so die automatische Ausführung von Skripten vor der Installation. Ältere npm-Clients sind weiterhin anfällig.
• SLSA und OIDC durchsetzen: Verlangen Sie SLSA-Herkunftsbescheinigungen und überprüfen Sie diese bereits bei der Erstellung. Beachten Sie jedoch, dass diese Kampagne gezeigt hat, dass die Herkunftsangabe allein nicht ausreicht, wenn der Angreifer die Build-Pipeline kontrolliert – die Herkunftsangabe muss mit einer Identitätsüberprüfung kombiniert werden.
• Erlauben Sie die Zulassungsliste für Abhängigkeiten: Beschränken Sie zulässige Paketquellen und -versionen mithilfe von Tools wie Socket, Semgrep Supply Chain oder den Richtlinien Ihrer Artefakt-Registry.
• Implementieren Sie eine Überprüfung der Paketintegrität: Verwenden Sie npm-Audit-Signaturen und überprüfen Sie die Integritäts-Hashes der Registry, sofern dies unterstützt wird.
• Aktivieren Sie MFA für alle Betreuerkonten: Verlangen Sie hardwaregestützte MFA für alle npm- und GitHub-Konten mit Veröffentlichungsberechtigungen.
• Blockieren Sie bösartige Domains: Fügen Sie die oben aufgeführten IOCs zu Ihren Blocklisten am Netzwerkperimeter und Ihren DNS-Filterlösungen hinzu.

Wenn Sie Bedenken hinsichtlich einer der in diesem Bulletin beschriebenen Bedrohungen haben oder Hilfe bei der Ermittlung der Maßnahmen benötigen, mit denen Sie sich vor den für Ihr Unternehmen relevantesten Bedrohungen schützen können, wenden Sie sich bitte an Ihren Kundenbetreuer oder kontaktieren Sie uns, um zu erfahren, wie Sie Ihr Unternehmen schützen können.