Ein npm install gehört für Entwickler zum Alltag. In diesem Fall kann genau dieser Befehl ausreichen, um einen Entwicklungsrechner oder CI-Runner zu kompromittieren. Die betroffene Anwendung muss das Paket weder importieren noch starten.
Am 4. August 2026 wurden manipulierte Versionen von keyv, cacheable, cache-manager, flat-cache, file-entry-cache und zahlreichen weiteren npm-Paketen veröffentlicht. Die Schadsoftware läuft über ein eingeschleustes preinstall-Skript, sucht nach Zugangsdaten und versucht anschließend, weitere Pakete über gestohlene npm-Berechtigungen zu infizieren.
Die Kampagne läuft zum Zeitpunkt dieses Artikels noch. Socket erfasste in seinem aktuellen Datensatz 2.236 kompromittierte Paket-Artefakte aus 444 unterschiedlichen npm-Paketen. OX Security spricht von einer neuen Shai-Hulud-Kampagne. Andere Analysen verwenden unter anderem den Namen ChainDrop oder ordnen den Angriff lediglich technisch dem bekannten Shai-Hulud-Muster zu.
Stand: 4. August 2026, 20:30 Uhr CEST. Die Zahlen und Listen können sich weiter ändern. Für eine Prüfung sollte immer zusätzlich die laufend aktualisierte Kampagnenseite von Socket herangezogen werden.
Was ist passiert?
Der Angriff begann nach aktuellem Kenntnisstand mit kompromittierten Veröffentlichungsrechten im Umfeld der weit verbreiteten Pakete keyv und cacheable.
Die erste bestätigte schädliche Veröffentlichung war keyv@6.0.0 um 09:35 Uhr UTC. Wenige Minuten später folgte mit @thiennq/docs-viewer@1.6.2 bereits ein Paket außerhalb dieses ursprünglichen Umfelds. Ab 10:09 Uhr UTC erschienen weitere manipulierte Versionen aus der Cacheable-Paketfamilie.
Die Schadsoftware verbreitet sich danach selbst:
- Ein infiziertes Paket wird installiert.
- npm führt das eingeschleuste
preinstall-Skriptsetup.mjsaus. - Das Skript lädt eine passende Bun-Laufzeit in Version 1.3.13 nach.
- Darüber wird die zweite Schadstufe gestartet, meist
Math_Symbol.jsodermath_init.js. - Die Malware sucht nach Cloud-Zugangsdaten, npm-Tokens, GitHub-Tokens und weiteren Secrets.
- Mit gefundenen npm-Berechtigungen lädt sie legitime Pakete des Opfers herunter, ergänzt den Schadcode, erhöht die Versionsnummer und veröffentlicht die manipulierte Fassung erneut.
Das erklärt, warum innerhalb weniger Stunden so viele Pakete und Versionen betroffen waren. Es handelt sich nicht nur um den klassischen Fall eines einzelnen übernommenen Pakets. Der Schadcode nutzt die Rechte seiner Opfer, um die Lieferkette weiter zu vergiften.
Warum dieser Angriff besonders kritisch ist
Die Installation reicht aus
Viele Entwickler prüfen bei Sicherheitsmeldungen zuerst, ob eine betroffene Bibliothek im eigenen Code tatsächlich verwendet wird. Das greift hier zu kurz.
Der schädliche Code hängt an preinstall. Er läuft während der Installation, bevor die eigentliche Bibliothek genutzt wird. Ein kompromittierter CI-Lauf, ein lokales npm install oder ein automatisches Dependency-Update kann daher bereits genügen.
Die Pakete liegen oft tief im Dependency Tree
Pakete wie keyv, flat-cache und file-entry-cache werden häufig nicht direkt installiert. Sie kommen als transitive Abhängigkeit über andere Werkzeuge in das Projekt. Socket nennt als Beispiel die Kette von ESLint über file-entry-cache und flat-cache bis zu keyv.
Ein Blick in die eigene package.json reicht deshalb nicht. Entscheidend sind der Lockfile und der tatsächlich installierte Abhängigkeitsbaum.
Eine gültige Provenance ist kein Sicherheitsnachweis
Bei keyv@6.0.0 war die npm-Provenance laut Socket gültig. Das bedeutet, dass der veröffentlichte Build nachvollziehbar aus dem angegebenen Workflow stammte. Es bedeutet nicht, dass der zugrunde liegende Quellstand oder Workflow sicher und autorisiert war.
Das ist ein wichtiger Unterschied: Provenance kann die Herkunft eines Builds belegen. Sie bewertet aber nicht, ob ein Angreifer vorher Kontrolle über Repository, Branch, Token oder CI-Prozess erlangt hat.
Die Malware versucht dauerhaft zu bleiben
Mehrere Analysen beschreiben zusätzliche Dateien in .claude und .vscode. Darüber kann Schadcode beim Start einer Claude-Code-Sitzung oder beim Öffnen eines Projektordners in Visual Studio Code erneut ausgeführt werden.
Zusätzlich wurde ein sogenannter Token-Monitor beobachtet. Dieser prüft regelmäßig, ob ein gestohlenes GitHub-Token noch funktioniert. Wird es widerrufen, kann ein vom Angreifer gelieferter Handler ausgeführt werden. Das macht die Reihenfolge der Incident Response wichtig.
Bestätigte Kernpakete und frühe Folgeveröffentlichungen
Die folgenden Versionen gehören zum zuerst beobachteten Kern der Kampagne. ecto@5.0.1 folgte wenig später als frühe Weiterverbreitung außerhalb der ursprünglichen Paketfamilien:
| Paket | Betroffene Version |
|---|---|
keyv | 6.0.0 |
cacheable | 2.5.1 |
cacheable-request | 13.0.20 |
cache-manager | 7.2.10 |
flat-cache | 6.1.24 |
file-entry-cache | 11.1.6 |
@cacheable/net | 2.1.1 |
@cacheable/node-cache | 3.1.2 |
@cacheable/memory | 2.2.1 |
@cacheable/utils | 2.5.1 |
ecto | 5.0.1 |
Bei den @keyv/*-Paketen ist die Lage differenzierter. Socket berichtet, dass mehrere Versionen 6.0.0 kurz vor keyv@6.0.0 veröffentlicht wurden, in den untersuchten Tarballs aber kein ausführbarer preinstall-Payload bestätigt wurde. Wegen der kompromittierten Umgebung sollten diese Veröffentlichungen trotzdem nicht ungeprüft eingesetzt werden.
Zusätzliche betroffene Versionen, die in der OX-Liste fehlen
OX Security weist selbst darauf hin, dass seine Tabelle nur einen Ausschnitt darstellt. Beim Abgleich mit dem aktuellen Socket-Datensatz finden sich mehrere zusätzliche Versionen.
| Paket | In der OX-Tabelle genannt | Zusätzlich im Socket-Datensatz bestätigt |
@thiennq/docs-viewer | 1.6.4 | 1.6.2, 1.6.3 |
babel-plugin-linaria-css-to-undefined | 0.3.1 bis 0.3.9, 0.3.12 | 0.3.10, 0.3.11, 0.3.13 bis 0.3.17 |
frontend-orb | 4.4.1 bis 4.4.10, 4.4.13 | 4.4.11, 4.4.12, 4.4.14 bis 4.4.18 |
native-frontend-orb | 1.1.4 bis 1.1.11, 1.1.14 | 1.1.12, 1.1.13, 1.1.15 bis 1.1.19 |
pob-test-package-in-monorepo | 5.2.1 bis 5.2.9, 5.2.12 | 5.2.10, 5.2.11, 5.2.13 bis 5.2.16 |
pob-test-typescript-package-in-monorepo | 4.2.1 bis 4.2.10, 4.2.13 | 4.2.11, 4.2.12, 4.2.14 bis 4.2.17 |
Diese Tabelle ist bewusst kein Ersatz für die vollständige Kampagnenliste. Sie zeigt das eigentliche Problem: Bei einer aktiven, selbstverbreitenden Kampagne veraltet eine statische Aufzählung innerhalb kurzer Zeit.
Der ausgewertete Socket-Snapshot enthält unter anderem besonders viele Veröffentlichungen in den Scopes @servicetitan, @onereach, @or-sdk, @ornikar, @qlik, @nebula.js und @hubsync. Das bedeutet nicht automatisch, dass die Systeme der genannten Unternehmen selbst übernommen wurden. Nach aktuellem Stand verbreitete sich die Malware über gestohlene Veröffentlichungsrechte einzelner npm-Identitäten.
Die vollständige und laufend aktualisierte Liste ist hier verfügbar:
https://socket.dev/supply-chain-attacks/keyv-and-cacheable-compromise
So prüfst du ein Projekt auf betroffene Abhängigkeiten
1. Installierten Dependency Tree prüfen
Im Projektverzeichnis:
npm ls keyv cacheable cacheable-request flat-cache file-entry-cache cache-manager \
@cacheable/memory @cacheable/net @cacheable/node-cache @cacheable/utils --allDer Befehl zeigt auch transitive Abhängigkeiten. Ein Fehlercode von npm ls muss nicht automatisch einen Treffer bedeuten. npm meldet damit auch allgemeine Probleme im Abhängigkeitsbaum. Relevant sind die ausgegebenen Paketnamen und Versionen.
2. Lockfiles durchsuchen
grep -RInE '"(keyv|cacheable|cacheable-request|flat-cache|file-entry-cache|cache-manager)"' \
package-lock.json npm-shrinkwrap.json pnpm-lock.yaml yarn.lock 2>/dev/nullBei Monorepos sollte die Suche auf alle Workspace- und Lockfile-Verzeichnisse ausgeweitet werden.
3. Nach den bekannten Payload-Dateien suchen
find . -type f \( \
-name 'Math_Symbol.js' -o \
-name 'math_init.js' -o \
-name 'router_runtime.js' \
\) \( \
-path '*/node_modules/*' -o \
-path '*/.claude/*' -o \
-path '*/.vscode/*' \
\) -print 2>/dev/null4. Nach dem eingeschleusten Installationsskript suchen
grep -RInE '"preinstall"[[:space:]]*:[[:space:]]*"node setup\.mjs"' \
node_modules 2>/dev/null5. Git-Historie und Editor-Konfiguration prüfen
Beobachtet wurden Commits mit dem Autor claude <claude@users.noreply.github.com> und der Nachricht chore: update config.
git log --all --author='claude@users.noreply.github.com' --oneline
git grep -nE 'node \.(claude|vscode)/setup\.mjs' $(git rev-list --all) 2>/dev/nullBei großen Repositories kann der zweite Befehl länger dauern.
6. CI-Logs prüfen
Suche in den Logs seit dem 4. August 2026, 09:35 Uhr UTC nach:
setup.mjs
Math_Symbol.js
math_init.js
bun-v1.3.13
bun-dl-
npm-cache.comEin Download von Bun ist nicht grundsätzlich schädlich. In Kombination mit einem unbekannten setup.mjs während einer npm-Installation ist er jedoch ein ernstes Warnsignal.
7. Bekannte Persistenz-Artefakte prüfen
Linux:
test -e ~/.local/bin/gh-token-monitor.sh && echo "Treffer: gh-token-monitor.sh"
test -d ~/.config/gh-token-monitor && echo "Treffer: gh-token-monitor-Konfiguration"
systemctl --user status gh-token-monitor.service 2>/dev/nullmacOS:
launchctl print "gui/$(id -u)/com.user.gh-token-monitor" 2>/dev/nullKein Treffer bedeutet nicht automatisch, dass das System sauber ist. Die Kampagne wurde in mehreren Wellen beobachtet und kann unterschiedliche Artefakte hinterlassen.
Was tun, wenn eine betroffene Version installiert wurde?
Ein einfaches Downgrade reicht nicht. Wenn das preinstall-Skript bereits gelaufen ist, muss der betroffene Rechner oder Runner als kompromittiert behandelt werden.
1. System isolieren
Stoppe betroffene CI-Pipelines und trenne den Rechner oder Runner kontrolliert vom Netzwerk. Arbeite nicht normal weiter und führe keine weiteren Builds auf dem System aus.
Wegen des beobachteten Token-Monitors ist es sicherer, den Host zuerst zu isolieren und anschließend Zugangsdaten von einem separaten, vertrauenswürdigen System aus zu widerrufen. Eine Token-Rotation direkt auf dem möglicherweise infizierten Rechner ist keine saubere Lösung.
2. Betroffene Systeme neu aufsetzen
Bei Entwicklerrechnern und besonders bei CI-Runnern ist ein Neuaufbau aus einem bekannten, sauberen Image die belastbarste Maßnahme. Nur node_modules zu löschen entfernt weder mögliche Editor-Hooks noch Persistenz außerhalb des Projektverzeichnisses.
3. Erreichbare Zugangsdaten widerrufen
Behandle alle Secrets, die auf dem Host vorhanden oder abrufbar waren, als kompromittiert. Dazu gehören insbesondere:
- npm-Tokens und Trusted-Publishing-Berechtigungen
- GitHub Personal Access Tokens, Deploy Keys und
GITHUB_TOKEN - AWS-, Azure- und Google-Cloud-Zugangsdaten
- HashiCorp-Vault-Tokens
- Kubernetes-Service-Account-Tokens und Kubeconfigs
- CI/CD-Secrets auf Organisations- und Repository-Ebene
- Datenbankzugänge und API-Schlüssel weiterer Dienste
Widerrufe die alten Zugangsdaten vollständig und erstelle neue. Eine reine Passwortänderung reicht nicht, wenn weiterhin Tokens oder Schlüssel aktiv sind.
4. npm-Veröffentlichungen und GitHub-Aktivitäten prüfen
Kontrolliere:
- unerwartete npm-Versionen, die am 4. August 2026 veröffentlicht wurden
- neue oder unbekannte npm-Tokens
- neue GitHub-Repositories, Branches oder Commits
- Änderungen an
.claude/settings.jsonund.vscode/tasks.json - ungewöhnliche Workflows, Secrets oder OIDC-Konfigurationen
- öffentliche Repositories mit Kampagnen-Markern wie
Shai-Hulud: Here We Go Again
5. Sauber neu installieren
Erst nach Bereinigung und Credential-Rotation sollte das Projekt aus einem bekannten, vertrauenswürdigen Stand neu aufgebaut werden. Prüfe Lockfile, Registry-Quelle und Integritätswerte. Verwende keine Cache-Artefakte aus dem kompromittierten Runner.
Schutz vor ähnlichen npm-Angriffen
Vollständig verhindern lässt sich ein Supply-Chain-Angriff nicht. Die Auswirkungen lassen sich aber deutlich begrenzen.
npm 12 einsetzen und Installationsskripte prüfen
npm 12 blockiert Installationsskripte von Abhängigkeiten standardmäßig, sofern sie nicht über allowScripts freigegeben wurden. Offene Freigaben lassen sich anzeigen mit:
npm install-scripts lsErlaubnisse sollten möglichst auf die geprüfte Version begrenzt werden:
npm install-scripts approve canvas sharpEin pauschales approve --all nimmt dem Schutz einen großen Teil seiner Wirkung. Jedes Paket mit Installationsskript sollte begründet werden können.
Installationsskripte in älteren npm-Versionen abschalten
Wo es technisch möglich ist:
npm ci --ignore-scriptsEinige Pakete benötigen legitime Installationsskripte, beispielsweise für native Erweiterungen. Deshalb muss diese Einstellung getestet werden. In vielen reinen Build- oder Prüf-Pipelines ist sie trotzdem sinnvoll.
Neue Releases nicht sofort übernehmen
npm 12 unterstützt mit min-release-age ein Mindestalter für neu veröffentlichte Versionen. Ein Tag Verzögerung wird in der .npmrc so gesetzt:
min-release-age=1Das hätte die hier beschriebenen Veröffentlichungen nicht grundsätzlich verhindert, aber automatischen Updates ein Prüfungsfenster gegeben. Wichtig: Die Regel kann auch dringende Sicherheitsupdates verzögern. Ausnahmen sollten daher gezielt und nicht pauschal gesetzt werden.
Versionen exakt pinnen
Verwende exakte Versionen und committe Lockfiles. Automatische Merge-Prozesse für Dependency-Updates sollten nicht allein auf erfolgreiche Tests vertrauen. Ein Paket kann funktional korrekt bleiben und gleichzeitig während der Installation Schadcode ausführen.
CI-Runner kurzlebig halten
Ephemere Runner sollten nach jedem Job verworfen werden. Das verhindert nicht den Diebstahl von Secrets während des Jobs, erschwert aber dauerhafte Persistenz und reduziert Seitwärtsbewegungen.
Veröffentlichungsrechte begrenzen
Ein Token, das hunderte Pakete veröffentlichen darf, erzeugt einen entsprechend großen Schaden. Sinnvoll sind:
- getrennte Identitäten pro Paketgruppe oder Organisation
- möglichst kurzlebige OIDC-Anmeldungen statt dauerhafter Tokens
- minimale Berechtigungen
- verpflichtende Zwei-Faktor-Authentifizierung
- Protokollierung und Alarmierung bei neuen Versionen oder Token-Änderungen
Registry-Proxy oder Allowlist nutzen
Unternehmen können neue oder unbekannte Versionen zunächst über einen internen Registry-Proxy blockieren. Besonders sensible Build-Umgebungen sollten nur freigegebene Pakete und Versionen beziehen dürfen.
Indicators of Compromise
Dateien und Pfade
setup.mjs
Math_Symbol.js
math_init.js
router_runtime.js
.claude/setup.mjs
.claude/settings.json
.vscode/setup.mjs
.vscode/tasks.json
~/.local/bin/gh-token-monitor.sh
~/.config/gh-token-monitor/
gh-token-monitor.service
com.user.gh-token-monitorBeobachtete SHA-256-Hashes
54dc7ea54a1317cca0e890a2770630cf7fa6c97813e0cb9d2caa93012b350668 setup.mjs, erste Welle
fd3ca4007b225fdf8de7af4345a19179d5efa8c4bb9205f88cda806e5684b1eb setup.mjs, spätere Variante
9fc2570b7cef51c1b8df116d144d11ff4096357be7d2c4c6367cfc2509cf1bcc Math_Symbol.js / math_init.jsNetzwerk und weitere Marker
npm-cache[.]com:443/router
0xE1f2395ee43e45A1556EC6438a88c31B83493103
Shai-Hulud: Here We Go Again
Thebeautifulmarchoftime
IfYouBlockThisAPIKeyItWillCrashTheLiveProductionServersOfAllThirdPartyClientsIOCs sind hilfreich, aber nie vollständig. Ein fehlender Treffer ist kein Beweis dafür, dass ein System nicht betroffen war.
Fazit
Dieser Angriff zeigt, wie schnell aus einem kompromittierten Maintainer-Zugang ein Problem für hunderte Pakete werden kann. Besonders kritisch ist nicht nur die Zahl der betroffenen Releases, sondern der Ausführungszeitpunkt: Der Schadcode startet bereits bei der Installation.
Wer am 4. August 2026 eine der betroffenen Versionen installiert hat, sollte nicht nur die Abhängigkeit zurücksetzen. Der verwendete Entwicklerrechner oder CI-Runner muss als potenziell kompromittiert gelten. Systeme isolieren, sauber neu aufbauen, erreichbare Zugangsdaten von einem vertrauenswürdigen Gerät aus widerrufen und Veröffentlichungen sowie Repository-Aktivitäten prüfen.
Für die Zukunft sind blockierte Installationsskripte, exakte Versionen, verzögerte Updates, kurzlebige CI-Runner und eng begrenzte Veröffentlichungsrechte keine theoretischen Best Practices. Sie begrenzen in genau solchen Fällen den Schaden.
Quellen:
OX Security: A Massive Shai-Hulud Campaign Hits npm
Erste Meldung zur aktuellen Kampagne mit technischer Einordnung, Indicators of Compromise und einer ausdrücklich unvollständigen Liste betroffener Pakete.
https://www.ox.security/blog/a-new-infostealer-worm-hits-npm-affecting-keyv-and-cacheable/
Socket Research: Keyv- und Cacheable-Pakete kompromittiert
Ausführliche technische Analyse des preinstall-Loaders, der Schadsoftware, der Credential-Exfiltration und der Selbstverbreitung über kompromittierte npm-Zugänge.
https://socket.dev/blog/popular-npm-packages-in-the-keyv-and-cacheable-namespaces-compromised-in-active-supply-chain
Socket: Laufend aktualisierte Kampagnenseite
Aktuelle Übersicht der erkannten Pakete und Paketversionen. Diese Liste wurde verwendet, um weitere betroffene Versionen zu identifizieren, die in der ursprünglichen OX-Tabelle noch nicht aufgeführt waren.
https://socket.dev/supply-chain-attacks/keyv-and-cacheable-compromiseSocket: Vollständiger CSV-Export der erkannten Artefakte
Maschinenlesbare Liste der derzeit von Socket erfassten Paketversionen.
https://socket.dev/api/public/supply-chain-attacks/keyv-and-cacheable-compromise/packages.csv
Socket-Dateiansicht von keyv@6.0.0
Archivierte Paketansicht der zurückgezogenen Version, über die unter anderem die ergänzten Lifecycle-Dateien untersucht wurden.
https://socket.dev/npm/package/keyv/files/6.0.0/package.jsonGitHub-Suche nach dem Kampagnenmarker
Öffentliche Suche nach Repositories mit dem von der Schadsoftware verwendeten Marker Shai-Hulud: Here We Go Again. Die Trefferzahl verändert sich laufend.
https://github.com/search?q=%22Shai-Hulud%3A+Here+We+Go+Again%22&type=repositories
⚠️ Please note: We do our best to keep our projects and articles accurate, but we cannot guarantee that every setup will behave identically across all Plesk versions and Linux distributions. Test extensions on a separate development server before using them in production.
If you encounter a problem or have an improvement, feel free to open an issue or pull request on GitHub.
If this project is useful to you, we would appreciate your support on Instagram, LinkedIn or GitHub ❤️