npm-Wurm testmetest: 42 GitHub-Repos starten Malware über KI-Tools

Ein sich selbst verbreitender Wurm aus dem npm-Umfeld hat sich in 42 GitHub-Repositories eingenistet, die echten Entwicklern und Firmen gehören. Das hat das Sicherheitsteam von JFrog am 26. Oktober 2026 in einer ausführlichen Analyse der Kampagne „testmetest“ offengelegt. Besonders heikel: Die Schadsoftware muss nicht installiert werden. Es genügt unter Umständen, ein verseuchtes Projekt mit einem KI-Coding-Assistenten wie Claude Code, Gemini CLI oder Cursor zu öffnen oder den Ordner in VS Code zu laden.

Betroffen sind laut JFrog 11 legitime Konten. Das Fachportal The Register bestätigt die Zahlen. Wir ordnen ein, wie die Kampagne funktioniert und was Sie jetzt prüfen sollten.

Was ist testmetest?

Hinter dem Namen steckt eine Familie schädlicher npm-Pakete, deren Namen meist auf „-testmetest“ enden, etwa event-emitter-testmetest oder retry-utils-testmetest. Hinzu kommen Pakete unter den Scopes @iobandamwer und @testsecuiitytestme. Nach Stand vom 26. Oktober umfasst das Inventar 25 Paketnamen mit 82 bekannten Versionen. Nicht alle davon sind schädlich: Einige dienen offenbar als harmlose Tarnung, nachweislich bösartige Versionen fand JFrog bei 15 Paketen.

Erstmals aufgefallen ist die Kampagne dem Sicherheitsdienst SafeDep, der am 21. und 22. Oktober darüber berichtete. Damals sah es nach einem Testlauf ohne echte Opfer aus. JFrog hat weitergegraben und zeigt, dass das nicht stimmt: Gekaperte Konten gibt es demnach seit Juli 2026, eine skriptgesteuerte Welle hat Ende September zahlreiche fremde Repositories auf einmal präpariert. Die Commit-Daten wurden dabei gefälscht und aus der echten Projekthistorie kopiert, sodass die Änderungen älter wirken, als sie sind.

Warum KI-Assistenten hier zum Einfallstor werden

Moderne Entwicklerwerkzeuge lesen beim Start projektspezifische Einstellungen aus dem Repository. Genau das nutzt der Wurm aus. Die Angreifer legen in den gekaperten Projekten Konfigurationsdateien ab, die beim Öffnen automatisch einen Befehl ausführen:

Bei Claude Code und Gemini CLI handelt es sich um sogenannte Hooks, die beim Start einer Sitzung (SessionStart) feuern. Bei Cursor wird eine manipulierte MCP-Konfiguration samt Projektregel eingeschleust, bei VS Code ein Task, der beim Öffnen des Ordners läuft. Ob vor der Ausführung eine Vertrauensabfrage erscheint, hängt vom Werkzeug und seinen Einstellungen ab; JFrog äußert sich dazu nicht. Klar ist: Wer ein fremdes Repository klont und es ungeprüft als vertrauenswürdig markiert, gibt dem Wurm die Tür frei.

Die eigentliche Nutzlast ist gut versteckt. Die verschlüsselten Dateien in den Repositories sind 12,9 bis 13,7 MB groß. Das ist kein Zufall: Laut JFrog landen Dateien dieser Größe nicht im Suchindex von GitHub, und auch die übliche Inhalts-Schnittstelle liefert sie nicht aus. Werkzeuge, die auf diesem Weg nach bekannten Mustern suchen, gehen deshalb leer aus. Neuere npm-Varianten verbergen den Code zusätzlich in kompilierten Node-Erweiterungen (.node-Dateien), die ihn erst zur Laufzeit entschlüsseln. Zudem prüft die Schadsoftware, ob sie in einer CI-Umgebung, einem Container, einer schwach ausgestatteten Analyse-Maschine oder unter einem Debugger läuft, und bleibt dort still.

Was der Wurm auf dem Rechner anrichtet

Ist der Wurm aktiv, sammelt er Zugangsdaten, vor allem Token für GitHub und npm. Mit gestohlenen Veröffentlichungsrechten verbreitet er sich weiter, indem er neue Paketversionen hochlädt oder weitere Repositories präpariert. Auf dem System richtet er sich dauerhaft ein, unter Linux und macOS etwa als Dienste mit den Namen net-health-checker und pkg-runtime.

Gefährlich ist eine eingebaute Vergeltungsfunktion. JFrog warnt, dass der Wurm einen „Token-Revocation-Wiper“ enthält. Nach dem Bericht von The Register löscht er das Home-Verzeichnis, sobald das gestohlene GitHub-Token widerrufen wird. Daher ist die Reihenfolge beim Aufräumen wichtig (siehe unten).

Die Kampagne hängt außerdem mit Angriffen auf Webhosting-Server zusammen. Über missbrauchte GitHub-Actions-Workflows scannt sie das Internet nach Servern mit cPanel und WHM, die für die Authentifizierungslücke CVE-2026-41940 anfällig sind. Die US-Behörde CISA führt diese Lücke seit dem 30. April 2026 in ihrer Liste aktiv ausgenutzter Schwachstellen. Erfolgreiche Übernahmen von cPanel-Servern durch diese Kampagne sind laut The Register bislang nicht bestätigt.

Wie viele Opfer gibt es?

Das ist die große offene Frage. In einem Sammel-Repository der Angreifer fand JFrog am 25. Oktober 27 verschlüsselte Datendateien mit Zeitstempeln vom 22. bis 24. Oktober. Was darin steckt und von wem die Daten stammen, ließ sich nicht entschlüsseln. Die Zahl der betroffenen Entwickler ist deshalb unbekannt. Hinweise auf konkrete Opfer in Deutschland gibt es bislang nicht; die Kampagne richtet sich nicht gezielt gegen ein Land.

Was Sie jetzt tun sollten

1. Abhängigkeiten prüfen: Suchen Sie in package-lock.json und Ihren Build-Logs nach Paketen mit „testmetest“ im Namen sowie nach den Scopes @iobandamwer und @testsecuiitytestme. Fundstellen entfernen und neu aus vertrauenswürdigen Quellen bauen.
2. Repositories durchsuchen: Prüfen Sie eigene und geforkte Projekte auf die oben genannten Dateien und auf unerwartete Startbefehle in package.json, composer.json oder Makefile. Weil die Codesuche große Dateien übersieht, sollten Sie das Repository direkt per Git auschecken und lokal durchsuchen.
3. Verdächtige Spuren in Git: JFrog nennt Commits mit dem Zusatz skip-checks:true, kurzlebige Branches nach dem Muster chore/ci-* oder deps/upd-* und Massenumbenennungen von Repositories als Warnzeichen.
4. Reihenfolge beim Aufräumen: Erst die Dienste net-health-checker und pkg-runtime samt zugehöriger Dateien entfernen, dann Token widerrufen. Danach alle erreichbaren Zugangsdaten erneuern: GitHub, npm, Cloud, SSH und auch API-Schlüssel von KI-Anbietern.
5. Fremde Projekte vorsichtig öffnen: Klonen Sie unbekannte Repositories zuerst und sehen Sie sich Ordner wie .claude, .gemini, .cursor und .vscode an, bevor Sie einen KI-Assistenten starten oder den Ordner als vertrauenswürdig einstufen.
6. Hosting-Server patchen: Wer cPanel/WHM betreibt, sollte das Update gegen CVE-2026-41940 einspielen und Logs auf unbekannte Sitzungen prüfen.

Wer in einem Unternehmen mit personenbezogenen Daten arbeitet, sollte bei einem Befall außerdem die Datenschutzverantwortlichen einbinden: Abgeflossene Zugangsdaten zu Systemen mit Kundendaten können eine Meldepflicht nach Art. 33 DSGVO auslösen.

Einordnung: Lieferkettenangriffe treffen jetzt KI-Workflows

Angriffe über npm sind nicht neu, doch testmetest verlagert den Auslöser vom Installieren aufs Öffnen. Das passt zu einem Trend, den wir zuletzt bei den kritischen PHP-Lücken rund um PHP2Shell und der ausgenutzten WordPress-Lücke CVE-2026-87902 gesehen haben: Angreifer zielen auf Werkzeuge, denen Entwickler im Alltag blind vertrauen. Je mehr Arbeit KI-Assistenten wie Claude Code selbstständig erledigen, desto wertvoller werden deren Projekteinstellungen für Angreifer. JFrog sieht Parallelen zur bekannten Shai-Hulud-Wurmfamilie, lässt die genaue Herkunft aber offen.

Hinweis: Wir haben die Schadsoftware nicht selbst analysiert. Alle Angaben stammen aus der Untersuchung von JFrog Security Research und dem Bericht von The Register. Details zur Ausnutzung von Schwachstellen nennen wir bewusst nicht.

Häufige Fragen

Bin ich betroffen, wenn ich Claude Code oder Cursor nutze?

Nicht automatisch. Gefährlich wird es nur, wenn Sie ein präpariertes Repository öffnen oder eines der schädlichen npm-Pakete installiert haben. Die Werkzeuge selbst haben keine Lücke, missbraucht wird ihre Projektkonfiguration.

Schützt npm install --ignore-scripts?

Nur teilweise. Es verhindert klassische Installationsskripte, die Hooks für KI-Assistenten und VS Code im Repository greifen aber unabhängig davon.

Warum sollte ich das Token nicht sofort widerrufen?

Weil der Wurm laut den Berichten beim Widerruf des gestohlenen GitHub-Tokens das Home-Verzeichnis löschen kann. Entfernen Sie deshalb zuerst die eingerichteten Dienste und widerrufen Sie danach die Zugangsdaten.

Wie viele Rechner sind infiziert?

Das ist unbekannt. JFrog fand verschlüsselte Datensätze der Angreifer, konnte sie aber nicht lesen und nennt keine Opferzahl.