JFrog Security Research hat 42 GitHub-Repositories entdeckt, die Angreifer mit Ausführungs-Hooks und verstecktem Schadcode präpariert haben. Die Forscher ordnen sie der npm-Wurm-Kampagne "testmetest" zu. Wie viele Rechner den Code ausgeführt haben und welche Daten abgeflossen sind, ist bislang offen.
Die 42 Repositories gehören 11 legitimen Eigentümern. Den Schadcode, der laut JFrog Varianten von Shai-Hulud ähnelt, haben die Angreifer über gekaperte Konten oder Mitwirkendenrechte eingeschleust. Die npm-Seite der Kampagne hatte der Sicherheitsdienstleister SafeDep schon am 22. Oktober beschrieben, damals aber weder kompromittierte Fremdpakete noch Opfer gefunden.
KI-Assistent und IDE als Zünder
In den Repositories legten die Angreifer Projektkonfigurationen für Entwicklungswerkzeuge ab. Wer das Projekt etwa mit Claude Code, Gemini oder Cursor startete oder es mit passenden Einstellungen als VS-Code-Workspace öffnete, konnte damit die versteckte Datei .github/init.js ausführen. Ein bewusster Start eines Skripts war dafür nicht nötig.
JFrog nennt 15 npm-Pakete, von denen mindestens je eine Version als schädlich eingestuft ist:
- data-pipeline-testmetest, event-bus-lite-testmetest, event-emitter-testmetest
- log-rotate-testmetest, log-sink-testmetest, net-codec-testmetest
- npm-publish-testmetest, pixel-map-testmetest, retry-utils-testmetest
- test-brotli-testmetest, test-brotli2-testmetest, path-stream-utils-testmetest
- @iobandamwer/cache-helper, @iobandamwer/native-helper, @testsecuiitytestme/cache-helper
Ziel sind GitHub- und npm-Zugangsdaten
Einige der Pakete enthalten einen Wurm, der vor allem GitHub- und npm-Zugangsdaten einsammelt und sich selbst weiterverbreiten kann. In .github/init.js fand JFrog zusätzlich verschleierten Publisher-Code. Er sucht unter anderem nach GitHub-Token und veröffentlicht mit vorhandenen npm-Rechten manipulierte Paketversionen, zum Beispiel über GitHub Actions.
In einigen gekaperten Repositories lagen außerdem Shellpanel-Workflows, die cPanel-Systeme über die kritische Lücke CVE-2026-41940 angreifen. Eine durchgehende Kette von der npm-Infektion bis zur Ausnutzung dieser Lücke sehen die Forscher allerdings nicht belegt.
Unsichtbar für die Codesuche
Die Payload .github/init.js war je nach Variante 12,9 bis 13,7 MByte groß. So große Dateien indexiert die GitHub-Codesuche nicht, und auch die Contents API lieferte den Inhalt nicht aus. Erst als JFrog die Verzeichnisbäume über die Git Trees API auflistete und die Datei direkt als Git-Blob abrief, kam der Code zum Vorschein.
Eine neuere Variante tarnt sich noch besser. In @iobandamwer/cache-helper, @iobandamwer/native-helper und path-stream-utils-testmetest liegt der Schadcode nicht als lesbares JavaScript vor, sondern verschlüsselt in der Datei .napi_cache. Ein mitgeliefertes, kompiliertes Add-on entschlüsselt ihn zur Laufzeit. Vorher prüft es, ob es in einer Analyseumgebung läuft, und bricht in dem Fall ab. Laut einem SafeDep-Update vom 27. Oktober startet das Add-on in @testsecuiitytestme/cache-helper den Wurm sogar schon beim Import. Die Option --ignore-scripts schützt dann nicht mehr.
Für ihre Infrastruktur betreiben die Angreifer eigene Repositories, 17 davon unter dem GitHub-Konto CementBeetleSteeple. Eines davon, stable-scripts-9965, dient als Sammelstelle. Dort lagen am 25. Oktober 27 Dateien nach dem Muster data/snap-*.json mit vermutlich verschlüsselten Daten. Was darin steckt und wie viele Betroffene es gibt, bleibt unklar, denn JFrog hat nur die Metadaten ausgewertet.
Was Du jetzt tun solltest
JFrog rät, betroffene Systeme zu untersuchen und im Zweifel aus vertrauenswürdigen Quellen neu aufzusetzen. Prüf Repository-Konfigurationen und Workflows und widerrufe Zugangsdaten, die abgeflossen sein könnten. Achte dabei auf die Reihenfolge: Laut SafeDep installiert der Wurm einen Wiper, der das Home-Verzeichnis löscht, sobald das gestohlene GitHub-Token widerrufen wird. Wichtige Daten sicherst Du also besser vorher.