- Mehrere Versionen von @7nohe/openapi-react-query-codegen auf npm wurden kompromittiert., indem eine ausgeklügelte Malware-Payload eingebettet wird, die TanStack Query-basierte Workflows missbraucht.
- Der Angriff nutzte eine Sandbox-Schwachstelle in binding.gyp sowie Preinstall-Skripte. um einen mehrschichtigen JavaScript-Stealer während npm install auszuführen, selbst ohne explizite Lifecycle-Hooks.
- Die Nutzlast sammelte eine Vielzahl von Entwickler- und Cloud-Zugangsdaten. (GitHub, npm, AWS, Azure, GCP, Vault, Kubernetes und mehr) und haben sie in öffentliche GitHub-Repositories exfiltriert.
- Der Wurm missbrauchte gestohlene Token, um weitere npm-, PyPI- und RubyGems-Pakete sowie GitHub-Repos zu infizieren.und unterstreicht damit das umfassendere Lieferkettenrisiko im Zusammenhang mit der weit verbreiteten Nutzung des npm-Pakets TanStack Query.
Ende August 2026 entdeckten Sicherheitsforscher eine Gezielter Lieferkettenangriff mit Verbindung zum TanStack Query npm-Ökosystem durch einen gängigen OpenAPI-Codegenerator. Der Vorfall betrifft das Paket @7nohe/openapi-react-query-codegen, ein Tool, das automatisch typsichere Hooks für TanStack Query direkt aus OpenAPI-Schemas generiert und das wöchentlich mehr als 150,000 Downloads auf npm verzeichnet.
Anstatt die Kernbibliotheken von TanStack Query direkt anzugreifen, kompromittierten die Angreifer die zugehörigen Tools, auf die viele Teams zur Erstellung von TanStack Query-Hooks angewiesen sind . Sie schleusten eine komplexe Schadsoftware in mehrere Versionen des Generators ein. Da diese Hooks direkt in produktive React- und TypeScript-Codebasen integriert werden, reichen die Auswirkungen weit über ein einzelnes Paket hinaus und betreffen jede CI-Pipeline und jeden Entwicklerrechner, auf dem die manipulierten Versionen installiert wurden.
Wie der Angriff einen TanStack Query-Codegenerator auf npm missbrauchte
Die betroffene Bibliothek, @7nohe/openapi-react-query-codegen, wird häufig verwendet, um TanStack Query-Hook-Layer zu erstellen. Aus OpenAPI-Verträgen, wodurch Teams das manuelle Schreiben sich wiederholender Abruflogik ersparen. Innerhalb von etwa 20 Minuten veröffentlichte ein Angreifer zehn manipulierte Versionen dieses Pakets im npm-Repository, die alle über gültige Herkunftsnachweise verfügten, die über GitHub Actions erstellt wurden.
Diese normalerweise starken Integritätsnachweise wurden wertlos, da der GitHub-Actions-Workflow des Projekts selbst kompromittiert worden war . Durch Ausnutzung einer Schwachstelle in diesem Workflow konnte der Angreifer manipulierte Builds verbreiten und gleichzeitig kryptografische Beweise dafür generieren, dass diese aus der „offiziellen“ Pipeline stammten. Das zugehörige GitHub-Repository wurde offenbar im selben Zug übernommen, wodurch der Angreifer die volle Kontrolle über den Veröffentlichungsprozess erlangte.
Die Kampagne ähnelt früheren Lieferkettenvorfällen im Zusammenhang mit npm, fügt aber eine Besonderheit hinzu: Sie zielt gezielt auf die Schnittmenge von OpenAPI-Tools und TanStack-AbfragenutzungDa der Generator React-Code ausgibt, der von Folgendem abhängt @tanstack/react-queryJede Organisation, die dies in ihre automatisierte API-Clientgenerierung integriert hat, läuft Gefahr, die Malware in Build-Agenten, CI-Runner oder Entwickler-Laptops eingeschleust zu haben.
Die Ermittler stellten außerdem fest, dass die Kennzeichnung der Malware – die sich selbst „ Trinitite: Gesponsert von Preview 2 Effects “ nennt – an den theatralischen Stil früherer, mit TeamPCP in Verbindung stehender Operationen erinnert. Es bleibt jedoch unklar, ob es sich um das Werk von Nachahmern, einer Splittergruppe oder eines unabhängigen Akteurs handelt, der sich die Ästhetik angeeignet hat.
Binding.gyp-Sandbox-Escape: Malware wird während der npm-Installation gestartet
Eine der ungewöhnlicheren technischen Entscheidungen bei diesem TanStack-Query-Adjacent-Angriff ist die Missbrauch von binding.gyp als Ausführungsvektor während npm installUnter normalen Umständen binding.gyp Beschreibt, wie native Node.js-Add-ons kompiliert werden. Wenn npm auf eine solche Datei stößt, ruft es Folgendes auf: node-gyp, was wiederum die conditions Feld mit Python.
Die bösartigen Versionen von @7nohe/openapi-react-query-codegen Dieses Verhalten wird durch Einbetten eines Python-Sandbox-Escape in der conditions Schutzmassnahmen beiAnstatt harmlose Build-Konfigurationen zu enthalten, durchläuft die Datei die interne Klassenhierarchie von Python, um die catch_warnings Klasse, Wendepunkte zu __builtins__, Importe osund ruft schließlich an os.system Eine JavaScript-Payload mit Node ausführen.
Sobald die Verschleierung aufgehoben ist, reduziert sich die Bedingung auf einen einzigen Befehl: node 3FWCvzduYZg.js wird während der Installation automatisch ausgeführt.. Der Rest des binding.gyp Der Inhalt ist im Grunde ein Ablenkungsmanöver: Der angegebene Zielname ist bedeutungslos, der Typ ist hexadezimal kodiert. noneund es findet keine wirkliche native Kompilierung statt.
Nicht jede manipulierte Veröffentlichung beruhte ausschließlich auf diesem Trick. Zwei Vorab-Tags wurden konventionell verwendet preinstall Skripte stattdesseneine lokale Datei aufrufen nu.js und ein weiterer Download der Bun-Laufzeitumgebung über wget gerohrt zu bash bevor ich ein Skript mit dem dreisten Namen beginne is_it_this_simple.jsSpätere Versionen verdoppelten diese Anzahl und kombinierten die binding.gyp Ausnutzen mit einem expliziten "preinstall": "node 3FWCvzduYZg.js" Eintritt in package.json um die Wahrscheinlichkeit zu maximieren, dass die Nutzlast ausgeführt wird.
Eine mehrschichtige JavaScript-Nutzlast, die entwickelt wurde, um Sandboxes zu umgehen
Im Zentrum des kompromittierten TanStack-Abfragegenerators befindet sich 3FWCvzduYZg.js, eine einzeilige Datei mit einer Größe von etwa 5.4 MB.Das Skript befindet sich im Stammverzeichnis des npm-Pakets. Es ist stark verschleiert und verwendet mehrere Verschlüsselungsstufen, um die Untersuchung zu verlangsamen und statische Analysetools zu behindern.
Die äußerste Schicht ist eine riesiges Integer-Array, entschlüsselt mittels XOR mit einem festen Schlüssel, wodurch Code sichtbar wird, der die Bun-Laufzeitumgebung im Hintergrund in ein temporäres Verzeichnis herunterlädt (unter Namen wie trinnyyyy-XXXXX im System-Temp-Ordner). Bun wird dann verwendet, um das nächste verschlüsselte Segment auszuführen, das als AES-128-GCM-geschützte Daten im Skript eingebettet ist.
Nach vollständiger Entschlüsselung und Deobfuskierung entdeckten die Analysten eine etwa 800 KB große JavaScript-Nutzlast, die als Credential-Stealer, sich selbst verbreitender Wurm und zerstörerisches Tool fungiert . Dieses Skript verwendet eine eigens entwickelte Shuffled-Table-Verschlüsselung, die auf bekannten Transformationen von obfuscator.io aufbaut. Dies deutet erneut darauf hin, dass die Autoren gezielt automatisiertes Reverse Engineering verhindern wollten.
Bevor die Schadsoftware tatsächlichen Schaden anrichten kann, führt sie folgende Aktionen aus: Eine Reihe von Umgebungsprüfungen, die entwickelt wurden, um Sicherheitsforscher und automatisierte Scanner zu umgehen.Es beendet sich stillschweigend, wenn es russische Systemlokalisierungen, gängige EDR-Tools von CrowdStrike, SentinelOne oder Carbon Black, bekannte Sandbox-Verzeichnisse von Produkten zur Lieferkettenüberwachung oder gefälschte geheime Präfixe (wie z. B. …) erkennt. AKIAFAKE oder gefälschte npm-Tokens) oder GitHub-Organisationsnamen, die mit Sicherheitsforschungsdemos in Verbindung stehen. Es sucht außerdem nach dem Vorhandensein des StepSecurity-Härtungstools und bricht den Vorgang ab, wenn es eine gehärtete CI-Konfiguration erkennt.
Was die Malware von TanStack Query-Benutzern und darüber hinaus zu stehlen versucht
Sobald die Ausführungsbedingungen erfüllt sind, beginnt die Payload systematisch eine Vielzahl von Anmeldeinformationen zu sammeln, die in modernen JavaScript- und TanStack Query-basierten Workflows üblicherweise verwendet werden . Der Fokus liegt dabei nicht auf dem Frontend-Framework selbst, sondern auf der Cloud- und Entwicklerinfrastruktur, mit der TanStack Query-Clients typischerweise kommunizieren.
Der Zugriff auf GitHub ist ein Hauptziel. Die Schadsoftware Sucht sowohl nach klassischen persönlichen Zugriffstoken als auch nach neueren, fein abgestuften Token. in Umgebungsvariablen und Dateisystempfaden. Auf GitHub Actions-Runnern wird versucht, ein OIDC-Token mithilfe des Standards zu erhalten. ACTIONS_ID_TOKEN_REQUEST_TOKEN und der zugehörigen URL, wobei der gleiche Mechanismus genutzt wird, der auch in legitimen Arbeitsabläufen für kurzlebige Cloud-Anmeldeinformationen verwendet wird.
Paketregister sind eine weitere wichtige Datenquelle. Das Skript liest npm-Konfigurationsdateien wie z. B. ~/.npmrc, Scannen nach Bearer-Tokens und deren Validierung anhand der npm-Registry whoami EndpunktEs wendet eine ähnliche Logik für Pythons PyPI an (Suche nach Token, die mit beginnen). pypi-AgEIcHlwaS5vcmcCJ) und RubyGems (auf der Suche nach rubygems_ Token), wodurch die Angreifer potenziell Zugriff auf eine breite, ökosystemübergreifende Präsenz erhalten.
Das Sammeln von Cloud-Zugangsdaten ist noch weitreichender. Die Malware-Abfragen AWS-bezogene Umgebungsvariablen und Konfigurationsdateien, der EC2-Instanzmetadatendienst und ECS-Metadatenendpunkteunter Verwendung von sts:GetCallerIdentity Es werden Anrufe getätigt, um zu überprüfen, ob alle gefundenen Anmeldeinformationen gültig sind, bevor sie exfiltriert werden. Dieses Muster wird wiederholt für Azure (Client-IDs, Geheimnisse, verwaltete Identitäten und sogar Azure Key Vault) und für Google Cloud, Überprüfung von Dienstkonto-JSON, Metadatenservern und Secret Manager sobald es über ein verwendbares Token verfügt.
Neben Cloud- und Paketdatenbanken durchsucht das Skript auch lokale Festplatten nach über 150 verschiedene Klecksmustereinschließlich privater SSH-Schlüssel, Docker-Konfigurationen, .env Dateien, Git-Zugangsdatenspeicher, Krypto-Wallet-Verzeichnisse, Messaging-Clients wie Signal oder Telegram Desktop, VPN-Konfigurationen und sogar Konfigurationsdateien von KI-Tools wie Claude. Diese Bandbreite spiegelt das Verständnis dafür wider, wie TanStack Query-basierte Anwendungen typischerweise entwickelt und bereitgestellt werden: oft in Umgebungen, in denen ein einzelner Rechner oder CI-Job über weitreichende Zugangsdaten für Repositories, Registries und Cloud-Anbieter verfügt.
Datenexfiltration über GitHub-Repos und wurmartige Verbreitung
Sobald die Daten gesammelt sind, wählt die Malware einen ungewöhnlichen Ansatz zur Datenexfiltration. Anstatt Daten an einen herkömmlichen Command-and-Control-Server zu senden, nutzt sie GitHub-Repositories als öffentliche, verschlüsselte Ablageorte . Dies fügt sich nicht nur unauffällig in den normalen Entwicklerverkehr ein, insbesondere in Organisationen mit hohem TanStack-Query-Aufkommen, die ohnehin ständig mit GitHub interagieren, sondern erschwert auch die Bekämpfung.
Das Skript durchsucht zunächst die öffentliche Commit-Historie von GitHub nach Nachrichten, die einem bestimmten Muster entsprechen und ein verschlüsseltes Token im Nachrichtentext enthalten. Anschließend entschlüsselt es dieses Token, um die GitHub-Zugangsdaten zu ermitteln, mit denen es für jedes Opfer ein neues Repository erstellt . Dadurch landen gestohlene Daten von einem Rechner auf einem völlig anderen, bereits kompromittierten Konto, was die Zuordnung zusätzlich erschwert.
Jedes Exfiltrationsrepository wird benannt durch Kombination zufälliger Charakternamen aus dem Touhou-Projekt mit einem numerischen Suffix (zum Beispiel, cirno-marisa-74291) und die Beschreibung entspricht dem Slogan der Malware selbst: „Trinitite: Gesponsert von Preview 2 Effects“. Innerhalb dieser Repositories speichert das Skript JSON-Dateien mit Namen wie doubletrinnys-{counter}-{timestamp}.json in einem results/ -Ordner.
Das JSON-Layout ist einfach, aber sorgfältig verschlüsselt: Es enthält eine envelope enthielt den Großteil der gestohlenen Zugangsdaten und ein key Feld mit dem Sitzungsschlüssel, der über den öffentlichen RSA-Schlüssel des Angreifers verschlüsselt ist. Dies stellt sicher, dass die Dateien zwar technisch gesehen öffentlich sind, Nur wer den entsprechenden privaten Schlüssel besitzt, kann den Inhalt lesen.Dadurch können weder Gelegenheitsbeobachter noch die meisten automatisierten Crawler erkennen, was gestohlen wurde.
Parallel dazu agiert die Malware als Wurm. Mit gültigen npm-, PyPI- oder RubyGems-Tokens kann sie listet jedes Paket auf, das dem kompromittierten Maintainer gehört, und veröffentlicht neue, infizierte Versionen.Das Infektionsmuster folgt dem gleichen Schema wie bei der ursprünglichen Kompromittierung des TanStack Query-Codegenerators: Einschleusen eines schädlichen Codes. binding.gyp, vorbeischauen 3FWCvzduYZg.jsund das Paket mithilfe des gestohlenen Veröffentlichungstokens zu veröffentlichen. Es missbraucht außerdem gestohlene GitHub-Tokens, um zugängliche Repositories zu durchsuchen und Hintertür-Konfigurationsdateien unter folgenden Pfaden hinzuzufügen: .vscode, .claude, .github/workflowsund ähnliche Verzeichnisse, alle unter harmlosen Commit-Nachrichten wie "chore: update dependencies".
Dieses wurmartige Verhalten vergrößert den Wirkungsbereich dramatisch. Eine einzelne Organisation, die TanStack Query und @7nohe/openapi-react-query-codegen in ihrer CI-Kette verwendet , könnte unbeabsichtigt Malware in Dutzende interner Pakete und Repositories einschleusen, wenn ein kompromittierter Entwickler oder Build-Agent neue Versionen veröffentlicht, während er infiziert ist.
Indikatoren für Kompromisse bei TanStack Query npm-Benutzern
Für Teams, die auf TanStack Query und zugehörige npm-Tools angewiesen sind, gibt es einige konkrete Möglichkeiten. Es wurden Indikatoren für eine Gefährdung (IOCs) veröffentlicht, um die Exposition zu identifizieren.Die folgenden Versionen von @7nohe/openapi-react-query-codegen Es wurde bestätigt, dass sie die Trinitit-Nutzlast enthielten und als nicht vertrauenswürdig behandelt werden sollten:
- 0.5.4 und 0.5.5
- 1.6.3 und 1.6.4
- 2.2.1 und 2.2.2
- 3.0.3 und 3.0.4
- Vorabversionen 0.0.0-365d4eb738d3146583431948d3ba6e27a32556be und 0.0.0-ec7876d6c917dad516ba69bbfafc948b834bf0ab
Jedes Auftreten einer großen, einzeiligen JavaScript-Datei mit dem Namen 3FWCvzduYZg.js im Stammverzeichnis eines npm-Pakets ist ein starkes Warnsignal. Es wurden mehrere SHA-256-Hashes dieser Datei dokumentiert.Administratoren können diese mit Archiven installierter Pakete oder zwischengespeicherten Tarballs in internen Registrierungen vergleichen, um bekannte fehlerhafte Kopien aufzuspüren.
Auf infizierten Systemen werden temporäre Verzeichnisse mit einem Namen versehen. trinnyyyy- Ein Präfix, gefolgt von sechs zufälligen alphanumerischen Zeichen im temporären Ordner des Betriebssystems, kann ebenfalls auf eine vorherige Ausführung hinweisen. Diese Verzeichnisse werden verwendet, wenn Herunterladen und Bereitstellen der vom inneren Payload benötigten Bun-Laufzeitumgebung.
Über das jeweilige Generatorpaket hinaus sollten Organisationen die npm-Auditdaten, interne Paketspiegel und CI-Protokolle überprüfen. unerwartet binding.gyp Dateien oder plötzliches Auftauchen von preinstall Haken in Paketen, die bisher nicht auf native Add-ons oder Lebenszyklusskripte angewiesen waren. Im Kontext von TanStack Query bedeutet dies typischerweise, jegliche Codegenerierungs- oder OpenAPI-Integrationswerkzeuge, die in React, Vue oder andere Frontends eingebunden werden, genau zu prüfen.
Schließlich lohnt es sich, die GitHub-Aktivitäten genauer zu betrachten. Repositories mit Beschreibungen, die „Trinitite: Gesponsert von Preview 2 Effects“ oder ähnlichem entsprechen, sollten besonders beachtet werden. results/doubletrinnys-*.json Dateien und Commit-Nachrichten wie "meow meow meow", sollten als potenzielle Exfiltrationsendpunkte untersucht werden, die auf eine kompromittierte Nutzung von TanStack Query npm zurückzuführen sind.
Was TanStack-Abfrage-intensive Teams jetzt tun können
Für die meisten Organisationen besteht der erste Schritt darin, Inventarisieren Sie, wo und wie TanStack Query und die zugehörigen npm-Tools verwendet werden.Weil das kompromittierte Paket speziell für folgende Zwecke Hooks generiert: @tanstack/react-queryEs tritt häufig in Projekten mit starker Typisierung und automatisierten OpenAPI-Client-Generierungspipelines auf, die oft direkt in die CI eingebunden sind.
Die Teams sollten überprüfen, ob eine der aufgeführten schädlichen Versionen von @7nohe/openapi-react-query-codegen waren immer präsent in package-lock.json, pnpm-lock.yamlden yarn.lock Dateien oder über transitive Abhängigkeiten in Abhängigkeitsbäume eingebunden werden. Selbst wenn das Paket nicht mehr installiert ist, kann die frühere Verwendung auf Build-Agents eine genauere Untersuchung rechtfertigen.
Wo ein Kompromiss vermutet wird, sollte eine parallele Anstrengung den Schwerpunkt auf Folgendes legen: rotierende Token und Anmeldeinformationen, die von der Malware erbeutet wurdenDies umfasst persönliche GitHub-Zugriffstoken, npm-Veröffentlichungstoken, Cloud-Zugriffsschlüssel und alle dauerhaften Geheimnisse, die in Umgebungsvariablen oder Klartext-Konfigurationsdateien auf CI-Runnern gespeichert sind. Cloud-Anbieter protokollieren diese Vorgänge in der Regel. sts:GetCallerIdentity und ähnliche Anrufe, die dazu beitragen können, das Zeitfenster der Exposition einzugrenzen.
Tools zur Lieferkettensicherheit, die auf Malware-Scans von npm-Paketen spezialisiert sind , können Infektionen aufdecken, die herkömmlichen Schwachstellenscannern entgangen sind. Einige Plattformen stufen diese Kampagne bereits als kritisches Malware-Problem mit der Schweregradstufe 100/100 ein und bieten nächtliche oder bedarfsgesteuerte Überprüfungen von Repositories an, die auf TanStack Query und zugehörige Abhängigkeiten angewiesen sind.
Mit Blick auf die Zukunft werden Organisationen, die stark auf TanStack Query setzen, @tanstack/react-queryden @tanstack/vue-query In der Produktion sollten die Schutzmaßnahmen rund um die Paketinstallation verstärkt werden. Dies kann Folgendes umfassen: Proxy-Registries, die bekannte fehlerhafte Versionen blockieren, Tools, die Befehle wie … abfangen npm install or pnpm add und die Pakete anhand von Bedrohungsdaten abgleichenund eine strengere Verwendung von Herkunftsnachweis- und Signaturverifizierung – mit dem Vorbehalt, dass kompromittierte CI-Pipelines immer noch „gültige“ Attestierungen erzeugen können, wie hier zu sehen ist.
Da Frontend-Technologien zunehmend auf Bibliotheken wie TanStack Query für Datenabruf und -zwischenspeicherung setzen, werden Angreifer wahrscheinlich weiterhin das umliegende Ökosystem aus Generatoren, CLIs und Plugins auf npm ausspionieren . Dieser Vorfall verdeutlicht, wie ein scheinbar kleines Hilfspaket – das lediglich TanStack Query-Hooks aus einer OpenAPI-Datei generiert – zu einem schwerwiegenden Einfallstor in Build-Systeme, Monorepos und Cloud-Infrastrukturen werden kann, wenn es nicht ausreichend geschützt ist.
Die Entdeckung der Trinitit-Kampagne gegen @7nohe/openapi-react-query-codegen hebt hervor wie Beliebte npm-Pakete, die mit der Nutzung von TanStack Query verknüpft sind, können sich unbemerkt in Angriffsvektoren für Lieferketten verwandeln. wenn ihre Release-Workflows beeinträchtigt werden. Durch Missbrauch binding.gypMithilfe verschleierter JavaScript-Loader und GitHub-basierter Datenexfiltration gelang es den Angreifern, einen weitreichenden Credential-Stealer in einem Tool zu verstecken, das viele Teams als Routine-Tool betrachteten. Für Organisationen, die TanStack Query für React und andere Frontends nutzen, sind die Optimierung der npm-Sicherheit, die Überwachung verdächtiger Lifecycle-Skripte und die Absicherung von CI-Pipelines im Zusammenhang mit OpenAPI und Query-Codegenerierungstools keine optionalen Extras mehr, sondern fester Bestandteil des Risikomanagements.
