Am 4. August 2026 wurde im npm-Ökosystem eine groß angelegte Supply-Chain-Attacke festgestellt: Schadcode, der erstmals in [email protected] entdeckt wurde, verbreitete sich über die Namespaces Keyv und Cacheable hinaus und betraf Hunderte von Paketen zahlreicher Organisationen. Die Malware nutzt den Mechanismus von preinstall-Skripten, um Zugangsdaten aus Entwicklungs- und CI/CD-Umgebungen zu stehlen und veröffentlicht anschließend automatisch kompromittierte Versionen anderer Pakete neu, die über die gestohlenen npm-Tokens zugänglich sind. Jedes System, das eine infizierte Version ausgeführt hat, ist als kompromittiert zu betrachten — dabei muss vor der Rotation von Tokens zunächst der vom Schadcode installierte Überwachungsmechanismus für den Widerruf von Zugangsdaten entfernt werden, sonst löst die Rotation selbst den Handler des Angreifers aus.
Ausmaß der Kampagne und Unterschiede in den Schätzungen
Die Einschätzungen zum Umfang der Infektion unterscheiden sich deutlich zwischen den Forschungsgruppen. Nach Angaben von SafeDep wurden 353 bösartige Versionen in 79 Paketen des npm-Registry verifiziert, während das Monitoring eine breitere Abdeckung mit 442 Versionen in 353 Paketen registrierte. Aikido berichtet von mindestens 868 Paketen und 1.381 kompromittierten Versionen. Keine dieser erweiterten Schätzungen konnte zum Zeitpunkt der Erstellung dieses Beitrags anhand einer vollständigen öffentlichen Liste unabhängig reproduziert werden.
Wesentlich ist: All diese Zahlen beschreiben die Menge bösartiger Artefakte im Registry und nicht die Anzahl kompromittierter Systeme. Ob eine Workstation oder ein CI-Runner tatsächlich infiziert wurde, hängt davon ab, ob genau die kompromittierte Version in den Projektabhängigkeiten aufgelöst wurde und ob deren Lifecycle-Skript ausgeführt wurde.
Technische Anatomie des Angriffs
Primärvektor: npm-Paket
Die erste bestätigte bösartige Version war [email protected]. In der package.json wurde der Befehl node setup.mjs als preinstall-Hook hinzugefügt, und dem Paket wurden die Dateien setup.mjs und Math_Symbol.js beigefügt. Der kompilierte Bibliothekscode blieb dabei unverändert – die Funktionalität des Pakets wurde nicht beeinträchtigt, was die Entdeckung erschwerte.
Nach Angaben von SafeDep prüft die erste Stufe das Vorhandensein der Laufzeitumgebung Bun, lädt bei Bedarf die Version 1.3.13 aus den offiziellen GitHub-Releases herunter und übergibt dann die Ausführung an ein kompiliertes Bundle mit einer Größe von 727.680 Byte. Dieses Bundle sammelt ein breites Spektrum an Geheimnissen:
- GitHub- und npm-Tokens
- Zugangsdaten zu Cloud-Services
- Secrets aus HashiCorp Vault und Kubernetes
- Daten für Datenbankverbindungen
- Private Schlüssel
- Inhalt des Speichers von GitHub-Actions-Runnern
Socket hat unabhängig das Vorhandensein von Funktionen im Code bestätigt, die Pakete im Namen der gestohlenen npm-Identität modifizieren, versionieren und neu veröffentlichen — genau dieser Mechanismus sorgt für die wurmartige Verbreitung.
Zweiter Vektor: Hooks im Repository
Neben dem npm-Paket wurde im Keyv-Repository ein alternativer Ausführungspfad für den Schadcode entdeckt. Die Datei .claude/settings.json enthält einen SessionStart-Hook, der .vscode/setup.mjs aufruft. Die Datei .vscode/tasks.json enthält die Aufgabe „Environment Setup“ mit dem Parameter runOn: folderOpen, die .claude/setup.mjs aufruft. Der Commit, der diese Hooks einführte, trug das grüne Verifikationssymbol von GitHub und war im Namen von github-actions[bot] signiert. Die verifizierte Signatur bestätigt jedoch nur die Gültigkeit der kryptografischen Operation, identifiziert aber nicht, wer die Zugangsdaten kontrolliert hat.
Diese Hooks werden nicht bedingungslos ausgeführt. VS Code blockiert automatische Aufgaben in nicht vertrauenswürdigen Workspaces und fordert standardmäßig eine Bestätigung an. Claude Code wendet einen Vertrauensmechanismus auf Einstellungen an, die aus dem Repository geliefert werden. Ein Entwickler, der routinemäßig dem Projekt vertraut und dies bestätigt, aktiviert damit jedoch die Ausführung des Schadcodes.
Stand 17:40 Uhr IST am 4. August befanden sich beide Hook-Dateien weiterhin im Branch main, und core/keyv/package.json deklarierte nach wie vor die Version 6.0.0 mit dem bösartigen preinstall-Skript.
Umgehung von Vertrauensmechanismen
Der kompromittierte Keyv-Release wurde über einen legitimen GitHub-Actions-Workflow veröffentlicht und erhielt eine gültige OpenID-Connect-(OIDC-) und SLSA-(Supply-chain Levels for Software Artifacts-)Attestierung. Die Attestierung identifizierte den Build-Prozess korrekt, konnte jedoch nicht feststellen, dass der Quellcode, der in diesen Prozess einging, sicher war. Dies verdeutlicht eine grundlegende Einschränkung: Provenienz und Signaturen verifizieren den Build-Pfad, aber nicht den Inhalt dessen, was gebaut wurde.
Bezug zu früheren Angriffen
Semgrep hat identische Claude-Code- und VS-Code-Hooks, den Dateinamen setup.mjs sowie den Download von Bun 1.3.13 bei der Kompromittierung des Pakets lightning in PyPI im April dokumentiert. Aikido ordnet die Aktivität im August der Malware-Familie Shai-Hulud zu. Die Übereinstimmung der Artefakte bestätigt einen Zusammenhang auf Ebene der Malware-Familie, legt jedoch nicht fest, wer hinter der August-Kampagne steht – weder der anfängliche Zugriffsvektor noch der konkrete Akteur wurden identifiziert.
Die vorliegenden Daten erlauben keine Aussage darüber, ob sich der Wurm ausschließlich von einer gestohlenen Publisher-Identität aus verbreitete oder ob unabhängig kompromittierte Konten mehrerer Entwickler eingesetzt wurden.
Bewertung der Auswirkungen
Gefährdet sind alle Teams und Organisationen, die Keyv, Cacheable und verwandte Pakete in ihren Projekten einsetzen. Keyv ist eine weit verbreitete Bibliothek für einen einheitlichen Zugriff auf Datenspeicher, die in der Node.js-Ökosystem häufig verwendet wird. Die Kompromittierung betrifft nicht nur Endanwendungen, sondern auch CI/CD-Pipelines, in denen Lifecycle-Skripte automatisch ausgeführt werden.
Nicht alle Pakete, die mit dem ursprünglichen Maintainer verbunden sind, wurden kompromittiert. Nach Angaben von SafeDep blieben die veröffentlichten Adapter @keyv/* und die Keyv-5.x-Reihe sauber. Das Repository stellt jedoch ein eigenes Risiko dar: Ein späterer Commit platzierte die bösartigen Dateien in allen 19 Paketen des Workspaces, sodass jeder Release, der aus einem kompromittierten Baum gebaut wird, Schadcode enthalten wird.
Empfehlungen zur Reaktion
- Überprüfen Sie die Lockfiles (
package-lock.json,yarn.lock,pnpm-lock.yaml) auf das Vorhandensein exakter Versionen aus dem kompromittierten Set. Verlassen Sie sich nicht auf die aktuellenlatest-Tags – diese wurden im Verlauf des Incidents geändert. Zum Zeitpunkt der Beobachtung waren für eine Reihe von Paketen, darunter [email protected], [email protected] und [email protected], wieder sichere Versionen hergestellt. - Wenn eine kompromittierte Version installiert und ausgeführt wurde, betrachten Sie alle Zugangsdaten auf der Maschine als kompromittiert.
- Vor der Rotation von Tokens müssen Sie unbedingt den vom Schadcode installierten Überwachungsmechanismus für den Widerruf von Zugangsdaten finden und entfernen. Eine Rotation ohne Entfernung dieses Watchers kann den Handler des Angreifers auslösen.
- Aktualisieren Sie den npm-Client auf Version 12, die nicht genehmigte Lifecycle-Skripte von Abhängigkeiten standardmäßig blockiert. Ältere npm-Versionen und alternative Installationswege, die Lifecycle-Skripte zulassen, bleiben verwundbar.
- Verwenden Sie kein Namespace-Blocking als einzige Maßnahme – dies birgt sowohl das Risiko, kompromittierte Versionen zu übersehen, als auch das unbeabsichtigte Blockieren sauberer Releases.
- Überprüfen Sie Klone des Keyv-Repository auf das Vorhandensein der Dateien
.claude/settings.jsonund.vscode/tasks.jsonmit bösartigen Hooks. Erteilen Sie dem Workspace kein Vertrauen, bevor das Repository bereinigt wurde.
Zum Zeitpunkt der Erstellung dieses Beitrags hatten weder der Maintainer des Projekts noch npm noch GitHub eine offizielle Stellungnahme zu dem Vorfall veröffentlicht. Organisationen, die betroffene Pakete verwenden, sollten umgehend ein Audit der Abhängigkeiten anhand der exakten Versionen in den Lockfiles durchführen, vor jeder Rotation von Secrets den Überwachungsmechanismus der Malware entfernen und auf npm 12 umsteigen, um die Ausführung nicht genehmigter Skripte von Abhängigkeiten zu unterbinden – genau dieser Mechanismus war der zentrale Vektor für die Verbreitung des Wurms.
