Keyv npm Supply Chain Attack trifft 2 Milliarden Installs

Der Keyv npm supply chain attack kompromittierte ein einzelnes GitHub-Wartungs-Account und nutzte es, um einen Credential-stehlenden Wurm in Hunderte weit verbreitete Caching-Pakete einzuschleusen. Bis zum 5. August zählten Tracking-Dienste 868 Pakete und 1.381 Versionen mit zusammen über 2 Milliarden monatlichen Installationen — der grösste Software-Supply-Chain-Vorfall, den DIESEC 2026 bisher verfolgt hat.

Was ist passiert

Am 4. August 2026 kompromittierten Angreifer das GitHub-Konto von „Jaredwray“, dem Maintainer von keyv, einer Key-Value-Storage-Bibliothek mit rund 127 Millionen wöchentlichen npm-Downloads. Das ist kein isoliertes Paket: Dasselbe Maintainer-Konto kontrolliert auch cacheable, cache-manager, cacheable-request, flat-cache, file-entry-cache und mehrere weitere Caching-Utilities, die im gesamten Node.js-Ökosystem eingesetzt werden. Der Angreifer pushte bösartige Dateien direkt in den Main-Branch und veröffentlichte sofort einen neuen Release: [email protected] plus zehn verwandte Paket-Releases, jeweils mit einem versteckten preinstall-Skript.

Dieses Skript startet eine rund 727KB grosse, verschleierte Payload — ein Ableger der Malware-Familie „Mini Shai-Hulud“, die zuvor mit TeamPCP und Nachahmer-Akteuren in Verbindung gebracht wurde — die GitHub-Token, AWS-/Azure-/GCP-Zugangsdaten, private SSH-Schlüssel und Datenbank-Verbindungsstrings von jeder Maschine abgreift, auf der npm install ausgeführt wird. Da npm Lifecycle-Skripte wie preinstall standardmässig automatisch ausführt, war ausser einer routinemässigen Installation keine weitere Aktion des Entwicklers nötig, um die Payload auszulösen. Innerhalb von rund 30 Minuten verbreitete sich der Wurm über die gemeinsame Paketfamilie des Maintainers; unabhängige Tracking-Dienste meldeten Zahlen von einer bestätigten Untergrenze von 353 vergifteten Versionen über 79 Paketnamen (SafeDep) bis zu einer breiteren Schätzung von 868 Paketen / 1.381 Versionen (Aikido).

Ein Merkmal unterscheidet diesen Vorfall von früheren npm-Vorfällen 2026: Die Payload platziert Persistenz-Hooks direkt in Entwickler-Tools. Forscher fanden einen Claude Code Session-Hook sowie eine VS Code Task, die ausgeführt werden, sobald ein Entwickler den betroffenen Workspace öffnet und als vertrauenswürdig einstuft — der Angriff zielt gezielt auf die „Trusted Workspace“-Annahme, auf die sich KI-Coding-Assistenten und IDEs verlassen.

Warum das wichtig ist

Fünf Pakete haben bestätigte bösartige Versionen mit bekannten Versionsnummern (keyv, cache-manager, cacheable-request, @cacheable/utils, flat-cache); vier weitere desselben Maintainers (cacheable, file-entry-cache, @cacheable/memory, @cacheable/node-cache) sind bestätigt betroffen, aber ohne veröffentlichte fehlerhafte Versionsnummer — Teams können also nicht einfach im Changelog nachsehen, ob sie betroffen sind. Für den deutschen Mittelstand ist die Exposition nahezu universell: Caching-Utilities dieser Art sitzen in der Abhängigkeitsstruktur der grossen Mehrheit von Node.js-Backends, ob selbst entwickelt oder über Frameworks wie Express oder NestJS — kaum ein Team wird „keyv“ bewusst gewählt haben, aber viele werden es drei oder vier Abhängigkeitsebenen tiefer erben.

Der Claude Code- und VS Code-Persistenzmechanismus erhöht die Brisanz zusätzlich. Genau hier laufen DIESECs Software-Supply-Chain-Bogen und der Bogen zu AI-Coding-Assistant-Angriffsflächen (TrapDoor, 26. Mai; Miasma, 4./9. Juni) 2026 direkt zusammen: Angreifer vergiften nicht mehr nur Pakete, sondern die Entwickler-Tools, die diese Pakete inspizieren und bereinigen sollen.

Was Sie jetzt tun sollten

1. Prüfen Sie package-lock.json / yarn.lock auf keyv, cache-manager, cacheable-request, @cacheable/utils, flat-cache, cacheable, file-entry-cache, @cacheable/memory und @cacheable/node-cache. Pinnen Sie die vier mit bestätigt sauberen Versionen auf [email protected], [email protected], [email protected] und [email protected] über einen overrides-Block in der package.json.
2. Prüfen: Wurde in irgendeiner Umgebung seit dem 4. August 2026 npm install gegen diese Pakete ausgeführt? Falls ja, diese Umgebung bis zum Gegenbeweis als potenziell kompromittiert behandeln.
3. Mitigieren: Lockfiles mit npm install --package-lock-only --ignore-scripts neu aufbauen, node_modules löschen, npm cache clean --force ausführen, dann mit npm ci --ignore-scripts neu installieren, damit kein verbleibendes Lifecycle-Skript ausgelöst wird.
4. Überwachen: Alle Zugangsdaten rotieren, die von einem betroffenen Build-Runner oder Entwickler-Arbeitsplatz erreichbar waren — GitHub Personal Access Tokens und App-Token, Cloud-Keys und übernommene Rollen, Kubernetes-Service-Account-Token, CI/CD-Secrets und SSH-Schlüssel. Claude Code- und VS-Code-Workspace-Trust-Einstellungen sowie Auto-Run-Hooks oder -Tasks in seit dem 4. August geklonten oder geöffneten Repositories überprüfen.

DIESEC Einschätzung

Dies ist das bislang klarste Beispiel für ein Muster, das wir bereits im Mai bei TrapDoor markiert haben: Angreifer behandeln KI-Coding-Assistenten und IDEs nicht als Werkzeuge, die es zu vermeiden gilt, sondern als zusätzliche Persistenz-Ebene, die sich ausnutzen lässt — weil ein „vertrauenswürdiger Workspace“ selbst ein privilegierter Ausführungskontext ist, den die meisten Sicherheitsteams noch nicht als solchen modelliert haben.

Nicht sicher, ob Ihre Entwicklungspipeline noch einen offenen Lifecycle-Skript-Ausführungspfad oder eine ungeprüfte Claude-Code-/VS-Code-Trust-Einstellung aus diesem Vorfall hat? Kontaktieren Sie DIESEC für eine schnelle Software-Supply-Chain-Expositions-Analyse.

Quellen: Wiz | The Hacker News
Veröffentlicht: 2026-08-06 | Kategorie: Tägliche News | ~4 Min. Lesezeit