Am 4. August 2026 wurde ein neuer Npm-Wurm Keyv-Links entdeckt, der ursprünglich mit keyv@6.0.0 auftauchte. Von dort aus breitete sich die Schadlogik über viele weitere Pakete aus und erreichte eine beachtliche Zahl von Namen in unterschiedlichen Organisationen. Besonders kritisch: In den betroffenen Installationspfaden wurden sowohl Entwickler- als auch CI-Umgebungen angesprochen – mit dem Ziel, Zugangsdaten abzugreifen und weitere Pakete zu kompromittieren.
Unterschiedliche Sicherheitschecks kamen auf große Schadensumfänge. SafeDep bestätigte 353 vergiftete Versionen unter 79 Paketnamen im npm-Registry-Verzeichnis. Später ermittelten weitere Beobachter eine noch größere Reichweite. Gleichzeitig ist wichtig: Eine vollständig verifizierbare Liste aller kompromittierten Pakete im öffentlichen Stand konnte nicht bis zum Berichtszeitpunkt sauber rekonstruiert werden. Das beeinflusst, wie Teams ihre eigene Exposition prüfen sollten.
Wie der Npm-Wurm Keyv-Links verbreitet wurde
Der Angriff begann nicht als einzelnes, isoliertes Schadpaket, sondern als Release mit einer preinstall-Komponente. Diese preinstall-Logik wurde innerhalb von Umgebungen ausgeführt, in denen npm-Installationen stattfinden – also typischerweise auf Workstations von Entwicklern oder in automatisierten Build- und Continuous-Integration-Prozessen.
Die Schadfunktion zielte darauf ab, Repository-, Registry-, Cloud- und Private-Key-Material zu sammeln. Darüber hinaus nutzte der Code vorhandene npm-Veröffentlichungsrechte, um weitere Pakete gezielt zu vergiften. Damit ähnelt das Muster weniger einem „einmaligen“ Trojaner und mehr einer Kampagne, die systematisch die Lieferkette weiter belastet.
Hunderte Pakete: Größenordnung der kompromittierten Versionen
SafeDep identifizierte 353 vergiftete Versionen, verteilt auf 79 Paketnamen. Zusätzlich deuten Monitoringdaten auf ein breiteres Gesamtbild hin: Eine zweite Auswertung brachte 442 Versionen über 353 Namen hinaus. Später meldete Aikido mindestens 868 Pakete über 1.381 Versionen.
Wichtig für die Einordnung: Diese Zahlen beziehen sich auf maliziöse Paketartefakte (also Versionen), nicht unmittelbar auf konkrete Opfer-Workstations oder CI-Läufe. Um tatsächliche Systemexposition festzustellen, müssen Teams die exakt aufgelösten Abhängigkeiten im eigenen Lockfile und die tatsächlich installierte Version berücksichtigen – plus die Frage, ob lifecycle-Skripte wirklich ausgeführt wurden.
Welche Schadlogik in keyv@6.0.0 steckt
Die erste bestätigte bösartige Veröffentlichung war keyv@6.0.0. Das Release änderte die veröffentlichte Funktionalität vor allem über die Installationskette: Es fügte eine node setup.mjs als preinstall-Befehl hinzu und veröffentlichte zusätzliche Dateien wie setup.mjs und Math_Symbol.js. Der kompilierten Bibliothekscode blieb dabei laut Analyse unverändert.
In einem weiteren Schritt prüft die Stufe-1-Logik, ob Bun im Zielumfeld vorhanden ist. Falls nicht, wird eine spezifische Bun-Version 1.3.13 aus den offiziellen GitHub-Releases heruntergeladen. Anschließend übernimmt ein kompiliertes Bundle mit einer Größe von 727.680 Byte die eigentliche Aufgabe.
Credential-Sammlung und das „Publishing“ in der Supply Chain
Die Payload-Analyse von SafeDep beschreibt eine breite Sammlung: GitHub-, npm-, Cloud-, Vault-, Kubernetes-, Datenbank- und Private-Key-Material können ausgelesen werden. Zusätzlich wurde berichtet, dass GitHub Actions Runner-Speicherbereiche angesprochen werden.
Ein zentraler Punkt ist die Fähigkeit, in der npm-Welt weiterzuschreiben: Der Code enthält Mechaniken, die darauf abzielen, über einen gestohlenen npm-Identitätszugang weitere Releases zu vergiften. Laut SafeDep und Socket passt das Zeitmuster besonders zu automatisierten Propagationsmechanismen und Publishing-Bursts, wobei offen bleibt, ob ein einzelner kompromittierter Identitätszugang ausreichte oder ob mehrere Publisher-Konten separat betroffen waren.
VS Code- und Claude-Code-Hooks als zweiter Ausführungsweg
Über die npm-installationsbasierte Komponente hinaus existiert ein weiterer Risikopfad. Im Repository blieben separate Hooks für Claude Code und Visual Studio Code (VS Code) erhalten. Diese können die Payload ausführen, sobald ein Nutzer der Workspace-Konfiguration vertraut oder die Projektkonfiguration erlaubt.
SafeDep und Socket ordnen diese Mechanik als zusätzliche Möglichkeit ein, Code in lokalen Entwicklerumgebungen nachzuladen – auch außerhalb klassischer CI-Läufe. Praktisch heißt das: Wer betroffene Versionen ausgecheckt, installiert oder in einer IDE-Automatik verarbeitet hat, sollte dies als potenziell credential-exponiert betrachten.
Warum „Zurückziehen“ von Tokens heikel sein kann
Socket empfiehlt, Workstations oder Runner, die eine betroffene Version ausgeführt haben, als Credential-exponiert zu behandeln. Ein weiterer Punkt betrifft den Ablauf der Incident-Reaktion.
SafeDep rät dazu, den sogenannten Credential-Revoke-Watcher zu entfernen, bevor Tokens und Schlüssel rotiert werden. Der Grund: Das eigentliche „Trigger“-Verhalten des Watchers kann durch das Zurückziehen ausgelöst werden. Wenn ein Team zuerst rotiert, kann das ungewollt einen lokal bereitgestellten Angreifer-Handler starten.
Zusätzlich ist zu beachten: npm 12 blockiert unautorisierte dependency lifecycle scripts standardmäßig. In älteren npm-Clients oder in Installationspfaden, die lifecycle scripts weiterhin erlauben, besteht jedoch weiterhin ein Risiko.
Welche Versionen sind betroffen – und warum die Listen nicht reichen
Die npm-Registry änderte sich laut Bericht sehr schnell. Zu einem bestimmten Zeitpunkt wurden frühere Releases in Paketübersichten wieder als latest angezeigt – zumindest für einige Pakete aus der initialen Menge. Genannt wurden u. a. keyv@5.6.0, flat-cache@6.1.23 und cache-manager@7.2.9.
Gleichzeitig konnte die Kampagne nicht vollständig und unabhängig „paketweise“ nachverfolgt werden. Deshalb sollten Checks nicht blind auf Momentaufnahmen beruhen, sondern auf exakten Paketnamen, aufgelösten Versionen und Lockfiles. So vermeiden Teams, dass sie entweder kompromittierte Versionen übersehen oder harmlose Releases fälschlich markieren.
Provenance und Signing: Guter Prozess, unsichere Quelle
Die kompromittierte keyv-Veröffentlichung trug gültige OpenID Connect (OIDC)– und SLSA-Provenance-Metadaten, weil sie über einen legitimen GitHub Actions Release-Workflow lief. Das bedeutet: Der Build- und Signierweg war im Rahmen der Prozesse korrekt. Gleichzeitig lässt das nicht automatisch erkennen, ob die eingehenden Quellen selbst sicher waren.
Auch das Commit, das die Claude-Code- und VS-Code-Hooks platziert haben soll, zeigte laut Bericht eine grüne GitHub-Verified-Markierung und als Autor github-actions[bot]. Solche Signaturen belegen die Integrität der Commit-Signatur, sagen aber nicht zwingend, wer die dahinterliegende Credential-Quelle tatsächlich kontrollierte.
Was Teams konkret ableiten sollten
Da die Schadwirkung sowohl über Installationsskripte als auch über IDE-bezogene Hooks laufen kann, sollten sich Verantwortliche in der Regel auf zwei Ebenen vorbereiten: Ermittlung und Eindämmung.
- Ermittlung: Prüfen Sie anhand Ihrer Lockfiles und der exakt aufgelösten Dependency-Versionen, ob betroffene Artefakte installiert wurden.
- Exekutionsrisiko: Bewerten Sie, ob lifecycle scripts tatsächlich aktiv waren (je nach npm-Version und Installationspfad) und ob Workspaces in VS Code/Claude-Code-Hooks erlaubt wurden.
- Incident-Reaktion: Planen Sie Token- und Key-Rotation so, dass ein eventueller Revoke-Watcher nicht zuvor unfreiwillig getriggert wird.
Ein weiterer Punkt ist die saubere Abgrenzung: Nicht jedes Paket, das mit dem ursprünglichen Maintainer-Kontext in Beziehung steht, war laut Bericht zwangsläufig vergiftet. Adaptionen und die Keyv-5.x-Linie wurden als sauber beschrieben. Das erhöht den Nutzen von versionengenauen Checks.
Einordung: Verbindung zu früheren Vorfällen
Semgrep dokumentierte ähnliche Claude-Code/VS-Code-Hooks, die Dateiname-Logik setup.mjs sowie den Download von Bun 1.3.13 bereits in einem früheren April-Vorfall rund um einen kompromittierten PyPI-Paketkontext. Aikido ordnet die August-Aktivitäten der „Shai-Hulud“-Familie zu. Diese Überschneidungen stützen die Annahme, dass es sich um ein zusammenhängendes Malware-Familienmuster handelt.
Wer hinter dem Zugriff und dem Betrieb stand, bleibt jedoch unklar. Der Bericht nennt keine eindeutig benannte verantwortliche Person oder Organisation für den August-Vorgang.
Fazit: Npm-Wurm Keyv-Links als Weckruf für präzise Supply-Chain-Kontrollen
Der Npm-Wurm Keyv-Links zeigt, wie schnell sich eine credential-stehlende Komponente in der JavaScript-Lieferkette ausbreiten kann – nicht nur über einzelne Pakete, sondern über Versionen und Namespaces in vielen Organisationen. Besonders gefährlich ist die Kombination aus preinstall-basierter Ausführung, umfangreicher Credential-Sammlung und zusätzlichen IDE-Hooks.
Für die Praxis gilt: Verlassen Sie sich nicht auf unvollständige oder schnell veraltende öffentliche Listen. Nutzen Sie Lockfiles, Versionen und überprüfbare Ausführungsbedingungen, um Exposure sauber zu bewerten. So können Teams den Schaden begrenzen und ihre Token- und Key-Rotation in einem Ablauf durchführen, der nicht versehentlich Angreiferlogik triggert.
Quelle: https://thehackernews.com/2026/08/keyv-linked-npm-worm-poisons-hundreds.html
