testmetest: 42 GitHub-Repositories für npm-Wurm präpariert

42 fremde GitHub-Repositories bei elf legitimen Eigentümern: Diesen Umfang beschreibt JFrog Security Research für die npm-Wurm-Kampagne testmetest. Die Projekte wurden mit Ausführungswegen für einen versteckten Publisher versehen. Neben Paketinstallationen geraten damit auch Projektkonfigurationen von Entwicklungswerkzeugen in den Blick.

Ein späteres Update verschärft die praktische Frage: SafeDep beschreibt eine Variante, bei der schon der Import eines Pakets die Schadsoftware startet. Ein Team, das Installationsskripte unterbindet, hat damit noch nicht jeden Ausführungsweg erfasst.

Für die Einordnung kommt es auf den jeweiligen Stand an. Die Forschungsberichte wurden am 22. und 26. Oktober veröffentlicht; inzwischen liegen Ergänzungen und aktualisierte Paketdaten vor. Redaktionsstand dieses Artikels ist der 29. Oktober 2026.

Das Wichtigste

• JFrog berichtet von 42 präparierten Repositories, nicht von 42 nachgewiesenen Ausführungen oder betroffenen Unternehmen.
• Die Kampagne nutzt unterschiedliche Einstiegspunkte: Installation, Paketimport und konfigurierte Projekt-Hooks.
• Für @testsecuiitytestme/cache-helper nennt das aktuelle GitHub-Advisory 1.0.1 bis 1.0.7 als betroffen. Eine bereinigte Version ist dort nicht ausgewiesen.
• Der OpenSSF-Datensatz meldet dieses Paket inzwischen als entfernt. Bereits bezogene Kopien und zuvor offengelegte Zugangsdaten sind damit nicht automatisch bereinigt.
• Bei bestätigtem Befall gehören Eindämmung, Untersuchung der Persistenz und der kontrollierte Austausch von Zugangsdaten in einen abgestimmten Incident-Prozess.

Was hinter den 42 GitHub-Repositories steckt

Die JFrog-Analyse vom 26. Oktober verbindet npm-Pakete mit manipulierten GitHub-Projekten. In den untersuchten Repositories fanden die Forscher große, verschleierte Dateien und Projektkonfigurationen, die den versteckten Publisher starten konnten. Als Ausführungswege nennen sie Konfigurationen für Claude Code, Gemini CLI, Cursor und VS Code.

Die Zahl beschreibt einen untersuchten Infrastruktur-Fund. Sie sagt nicht, wie viele Entwickler die Dateien tatsächlich ausgeführt haben, wie viele nachgelagerte Nutzer erreicht wurden oder wie viele Unternehmen betroffen sind. Auch eine eindeutige Identität der Betreiber lässt sich aus den beschriebenen Werkzeugüberschneidungen nicht ableiten.

Für die eigene Prüfung ist außerdem relevant, dass große Dateien bei der Codesuche fehlen können. JFrog beschreibt Wrapper von rund 13 MB. Eine Suche auf der GitHub-Website allein ist deshalb keine vollständige Dateiinventur. Das ist kein Beleg dafür, dass sämtliche GitHub-Schnittstellen solche Dateien grundsätzlich nicht lesen könnten.

Warum das Abschalten von Installationsskripten nicht alles abdeckt

Die SafeDep-Untersuchung dokumentiert mehrere Entwicklungsstände der Kampagne. Dazu gehören Installationswege über native Build-Mechanismen und spätere native Add-ons. Im Update vom 27. Oktober beschreibt SafeDep zusätzlich den Start beim Laden eines Pakets.

Die npm-Option --ignore-scripts hat einen engeren Auftrag: Sie unterbindet die betreffenden Skripte aus Paketdateien. Sie schaltet nicht die spätere Ausführung jeder geladenen JavaScript- oder nativen Bibliothek ab. Auch ausdrücklich gestartete npm-Skripte haben laut npm-Dokumentation eigene Regeln.

Die Konsequenz ist konkret: Ein Paket zunächst ohne Installationsskripte zu beziehen und es anschließend unkontrolliert zu importieren ist keine vollständige Isolierung. Abhängigkeiten sind ausführbarer Code. Ihre spätere Verwendung muss in die Bewertung der vorgesehenen Umgebung einfließen.

Dabei sollte die Beschreibung der Varianten erhalten bleiben. Ein bestimmter Trigger gehört zu bestimmten untersuchten Builds; daraus folgt nicht, dass jedes verdächtige Paket alle Mechanismen zugleich enthält.

Projekt-Hooks gehören zum ausführbaren Teil eines Repositories

Bei testmetest liegt ein weiterer Einstiegspunkt in Dateien, die Entwickler häufig als Werkzeugkonfiguration wahrnehmen: etwa .claude/settings.json, .cursor/mcp.json oder .vscode/tasks.json. Ein unbekannter Befehl dort verdient denselben Review wie ein unbekanntes Build-Skript.

Die Claude-Code-Dokumentation beschreibt Hooks als ereignisgebundene Automatisierung. Abhängig vom Hook-Typ können sie Befehle ausführen. Das erklärt den grundsätzlichen Unterschied zu einem bloßen Hinweistext im Repository: Eine Konfiguration kann einen tatsächlichen Prozessstart bewirken.

Ob ein präpariertes Projekt diesen Weg auf einem bestimmten Rechner nutzen kann, hängt von Werkzeugversion, Konfiguration und erteiltem Vertrauen ab. VS Code Workspace Trust begrenzt beispielsweise Aufgaben und weitere Funktionen im Restricted Mode. Der Bericht belegt keine universelle Umgehung aller Trust-Dialoge.

Unsere Einordnung: Sicherheitsreviews sollten die Werkzeuge einbeziehen, mit denen ein Projekt geöffnet und bearbeitet wird. Dazu gehören freigegebene Projekt-Hooks, Tasks und MCP-Serverkonfigurationen. Ein bösartiger Prozessstart setzt nicht zwingend voraus, dass ein Sprachmodell zuvor durch einen Prompt überzeugt wurde.

Diese Meldung behandelt damit einen anderen Mechanismus als der AISI-Test mit einem unerlaubt handelnden KI-Agenten: Hier geht es um präparierte Software und Ausführungswege im Werkzeugumfeld.

Was am 29. Oktober zu den Paketversionen bekannt ist

Ältere Meldungen lassen sich nicht unverändert als aktueller Registry-Stand übernehmen. Der OpenSSF-Datensatz MAL-2026-18358 wurde am 29. Oktober aktualisiert. Er verzeichnet für @testsecuiitytestme/cache-helper die Versionen 1.0.1, 1.0.2, 1.0.3, 1.0.4, 1.0.5, 1.0.6 und 1.0.7 als betroffen und die Entfernung des gesamten Pakets am 27. Oktober um 22:17 UTC.

Das GitHub-Advisory GHSA-4g45-28rv-vq9q führt dieselben sieben Versionen auf und nennt keine bereinigte Version. Sein Beschreibungstext enthält noch den früheren Zwischenstand zu Version 1.0.3. Für die heutige Einordnung sind die aktualisierte Versionsliste und der zeitlich zugeordnete OpenSSF-Eintrag entscheidend.

Auch SafeDeps ursprüngliche Aussage, keine Drittbetroffenen gefunden zu haben, ist ausdrücklich auf den 22. Oktober bezogen. Sie widerlegt den später veröffentlichten GitHub-Fund von JFrog nicht.

Die Entfernung unterbindet weitere reguläre Bezüge über diese Registry-Veröffentlichung. Sie entfernt keine vorhandene Kopie aus einem Entwicklerrechner, Cache, Spiegel oder Build-Artefakt. Ebenso macht sie einen bereits abgeflossenen Token nicht ungültig. Diese Unterschiede bestimmen, was eine betroffene Organisation noch untersuchen muss.

Was Teams jetzt konkret prüfen können

Die erste Frage lautet, ob ein betroffener Bestandteil tatsächlich im eigenen Bestand vorkam. Dazu passen vorhandene Lockfiles, Softwareinventare und gespeicherte Paketmetadaten. Paketname und Version gehören zusammen; eine harmlose Platzhalterversion ist nicht automatisch der gleiche Befund wie eine bösartige Veröffentlichung.

Für die weitere Eingrenzung sollten Teams drei Bereiche getrennt dokumentieren:

Die veröffentlichten Indikatoren sind Ansatzpunkte für diese Untersuchung. Ein passender Dateiname allein beweist noch keinen Befall. Umgekehrt beendet ein fehlender Suchtreffer die Prüfung nicht, wenn relevante Dateien oder Zeiträume gar nicht erfasst wurden.

Öffnet verdächtige Projekte nicht zur Kontrolle in einer gewöhnlichen Entwicklungsumgebung, die ihre Automatisierungen starten könnte. Nutzt für die Analyse einen geeigneten, isolierten Ablauf. Eine Untersuchung braucht keine probeweise Installation der genannten Malware.

Bei bestätigtem Befall zählt ein abgestimmter Ablauf

Die Forschungsberichte beschreiben in untersuchten Payloads einen Wiper, also eine Löschfunktion, die auf den Widerruf eines gestohlenen GitHub-Tokens reagieren kann. Deshalb wäre ein pauschales Rezept „zuerst Tokens widerrufen, danach den Rechner untersuchen“ für diesen Fall unvollständig.

Zieht bei einem belastbaren Verdacht euer Incident-Response-Team hinzu: betroffene Systeme und automatische Abläufe eindämmen, relevante Spuren sichern, aktive Schadprozesse und Persistenz behandeln beziehungsweise einen kontrollierten Neuaufbau planen. Den zügigen Entzug und Austausch gefährdeter Zugangsdaten stimmt ihr damit ab und führt ihn von einer vertrauenswürdigen Administrationsumgebung aus durch.

Das ist keine Empfehlung, gestohlene Zugangsdaten weiter nutzbar zu lassen. Eindämmung und Credential-Recovery müssen zusammenpassen. Welche Konten und Systeme in den Austausch einbezogen werden, ergibt sich aus den tatsächlich erreichbaren Rechten und Daten, nicht allein aus dem Namen des Pakets.

Haltet dabei fest, welche Version gefunden wurde, ob eine Ausführung belegt ist, welche Dienste betroffen sein könnten und welche Arbeit noch offen ist. Eine entfernte Datei und ein wiederhergestelltes Vertrauensverhältnis sind unterschiedliche Ergebnisse.

Was sich für den regulären Release-Prozess ableiten lässt

Für npm-Publisher ist die Trennung zwischen Entwicklungsarbeit und Veröffentlichungsrecht besonders wichtig. Trusted Publishing mit OIDC kann bei unterstützten Workflows langlebige Veröffentlichungstokens durch kurzlebige, an den Workflow gebundene Berechtigungen ersetzen. Damit entfällt ein bestimmter dauerhaft gespeicherter Zugang zum Publishing.

Dieser Vorteil setzt einen geschützten Veröffentlichungsablauf voraus. Wenn nicht vertrauenswürdiger Code in einem privilegierten Release-Job ausgeführt wird, bleibt dessen Berechtigung relevant. Die GitHub-Empfehlungen für Actions behandeln deshalb unter anderem minimale Rechte, den Umgang mit fremdem Code und die Absicherung verwendeter Actions.

Für Unternehmen ohne eigene npm-Veröffentlichung bleibt die Bestandsfrage: Welche Abhängigkeiten, Entwicklungswerkzeuge und Build-Dienste gehören zu welchem Produkt oder Service? Und wer übernimmt die Nachprüfung, wenn ein Fund bekannt wird?

Kopexa kann diese Bearbeitung mit betroffenen Assets, Risiken, Maßnahmen, Verantwortlichen und Nachweisen verbinden. Die technische Erkennung und Bereinigung erfolgt mit den dafür eingesetzten Werkzeugen und Fachleuten. So bleiben Untersuchung und Nachbereitung nachvollziehbar, auch wenn Entwicklung, Betrieb und Informationssicherheit gemeinsam daran arbeiten.

Die entscheidende Verbindung

testmetest verbindet Paketbezug, lokale Entwicklungswerkzeuge und Veröffentlichungswege. Die Meldung ist deshalb mehr als eine Liste entfernter npm-Versionen: Teams müssen klären können, welcher Code in welchem Kontext ausgeführt wurde und welche weiteren Zugriffe daraus möglich waren.

Der aktuelle Versionsstand hilft bei der Eingrenzung. Ob es zu einer Ausführung oder einem Zugriff im eigenen Unternehmen kam, muss die eigene Untersuchung beantworten. Genau diese Trennung macht aus einer Nachricht einen belastbaren Arbeitsauftrag.