Keyv-npm-Wurm vergiftet Hunderte Pakete und legt Claude-Code-Hooks aus
Ein Credential-stehlender npm-Wurm hat sich über das Paket keyv hinaus in Hunderte weitere npm-Pakete verbreitet und dabei Claude-Code- und VS-Code-Hooks hinterlassen, die den Schadcode auslösen können.
Ein Credential-stehlender npm-Wurm, der zuerst im Paket keyv@6.0.0 auftauchte, hat sich am 4. August 2026 über die Namespaces Keyv und Cacheable hinaus auf Hunderte weitere Pakete verschiedener Organisationen ausgebreitet. Besonders relevant für Entwicklerteams: Das Keyv-Repository enthielt zusätzlich Claude-Code- und Visual-Studio-Code-Hooks, die den Schadcode auslösen können, sobald ein Nutzer den Arbeitsbereich vertraut oder die Projektkonfiguration erlaubt.
Was ist passiert?
Der Sicherheitsdienstleister SafeDep verifizierte 353 vergiftete Versionen über 79 Paketnamen im npm-Registry, mit einem breiteren beobachteten Fußabdruck von 442 Versionen über 353 Namen. Aikido berichtete später von mindestens 868 betroffenen Paketen über 1.381 Versionen, wobei diese größere Zahl zum Zeitpunkt der Berichterstattung nicht unabhängig über eine vollständige öffentliche Liste reproduzierbar war.
Die schädliche Version nutzte ein Preinstall-Skript, um im Entwickler- und CI-Umfeld (Continuous Integration) ein Credential-stehlendes Bundle auszuführen. Laut SafeDep und Socket kann dieses Bundle Zugangsdaten für Repositories, Paket-Registries, Cloud-Dienste und private Schlüssel abgreifen und anschließend vorhandene npm-Publish-Rechte nutzen, um weitere Pakete zu vergiften.
Die erste bestätigte schädliche Veröffentlichung war keyv@6.0.0, das ein Preinstall-Kommando node setup.mjs hinzufügte. Stufe eins prüft auf das Vorhandensein von Bun, lädt bei Bedarf Version 1.3.13 von den offiziellen GitHub-Releases der Runtime herunter und übergibt an ein 727.680 Byte großes kompiliertes Bundle, das GitHub-, npm-, Cloud-, Vault-, Kubernetes-, Datenbank- und private Schlüsseldaten sammelt.
Wer ist betroffen?
Betroffen sind Entwickler-Workstations und CI-Runner, auf denen eine der vergifteten Paketversionen installiert wurde. Socket empfiehlt, jede Workstation oder jeden Runner, der eine betroffene Version ausgeführt hat, als credential-kompromittiert zu behandeln. Die Registry änderte sich während des Vorfalls so schnell, dass keine feste, kampagnenweite Paketliste als "latest" markiert Pakete zuverlässig abbildete: Um 17:40 Uhr indischer Zeit am 4. August zeigten npm-Paketseiten bei mindestens neun Paketen aus SafeDeps ursprünglichem Set wieder frühere Versionen als "latest" an, darunter keyv@5.6.0, flat-cache@6.1.23 und cache-manager@7.2.9.
Nicht betroffen sind Systeme, die npm 12 oder neuer verwenden, da diese Version nicht genehmigte Dependency-Lifecycle-Skripte standardmäßig blockiert. Ältere npm-Clients und andere Installationspfade, die Lifecycle-Skripte weiterhin erlauben, bleiben exponiert.
Wie kritisch ist das?
Die Kampagne betrifft die Software-Lieferkette direkt und kann sich selbstständig weiterverbreiten, da gestohlene npm-Publish-Rechte genutzt werden, um zusätzliche Pakete zu vergiften. Die Kombination aus Credential-Diebstahl und automatisierter Weiterverbreitung macht den Vorfall besonders kritisch für Entwicklungsumgebungen. Da die vollständige Kampagne nicht paketweise unabhängig kartiert werden konnte, müssen Expositionsprüfungen über exakte Paketnamen, aufgelöste Versionen und Lockfiles erfolgen, nicht über eine zwischengespeicherte Liste aktueller Tags.
Was sollten Admins jetzt tun?
- Package-Lock-Dateien und exakte installierte Versionen von keyv, cacheable und verwandten Paketen prüfen, nicht nur die aktuell als "latest" markierte Version
- Jede Workstation oder jeden CI-Runner, der eine betroffene Version ausgeführt hat, als credential-kompromittiert behandeln
- Vor dem Rotieren von Zugangsdaten zuerst den Credential-Revocation-Watcher der Malware entfernen, da eine vorzeitige Rotation einen vom Angreifer bereitgestellten lokalen Handler auslösen kann
- Anschließend GitHub-, npm-, Cloud-, Vault-, Kubernetes- und Datenbank-Zugangsdaten rotieren, die auf betroffenen Systemen vorhanden waren
- Prüfen, ob npm 12 oder neuer im Einsatz ist, das nicht genehmigte Lifecycle-Skripte standardmäßig blockiert
- Vorhandene Claude-Code- und VS-Code-Projektkonfigurationen in betroffenen Repositories auf unerwartete Hooks prüfen
- CI-Pipelines auf ungewöhnliche Preinstall-Skripte oder unerwartete Netzwerkzugriffe während der Installation kontrollieren
Einordnung für Unternehmen
Für kleine und mittlere Unternehmen mit eigener Softwareentwicklung oder Nutzung von Node.js-basierten Tools ist der Vorfall relevant, sobald Entwickler-Workstations oder CI-Systeme npm-Pakete aus dem betroffenen Zeitraum installiert haben. Die Kombination mit KI-Coding-Tool-Hooks (Claude Code, VS Code) zeigt, dass Supply-Chain-Angriffe zunehmend gezielt auf moderne Entwicklungsumgebungen zugeschnitten werden. Teams, die diese Tools einsetzen, sollten die Projektkonfigurationen aktiv prüfen, nicht nur auf verdächtige Abhängigkeiten warten.
Passende Anleitungen auf S-EDV
- GitHub/npm 12: Install-Skripte werden blockiert – Direkter Bezug zur zentralen Schutzmaßnahme gegen diese Art von Angriff.
- KI-Coding-Agenten: Malware und Prompt-Injection als Risiko – Passt thematisch zu den missbrauchten Claude-Code-Hooks.
