Jemand registrierte den tanstack Namen auf npm, erstellte ein Video-Player-SDK namens „TanStack Player“ und veröffentlichte heute vier schnell aufeinanderfolgende Versionen, die darauf ausgelegt sind, Ihre Umgebungsdateien zu exfiltrieren, sobald Sie npm install.
Das echte TanStack, die Heimat von TanStack Query, TanStack Table, TanStack Router, all diesen @tanstack/* Paketen mit Millionen wöchentlicher Downloads, hat damit nichts zu tun. Der Angreifer schnappte sich einfach den nicht-gescopten Namen, verpackte ihn überzeugend und wartete.
Heute um 17:08 UTC haben sie die Payload bereitgestellt.
Was geschah
Zwischen 17:08 und 17:35 UTC am 29. April 2026 wurden vier neue Versionen des tanstack npm-Pakets veröffentlicht: 2.0.4, 2.0.5, 2.0.6 und 2.0.7. Alle vier enthalten einen postinstall Hook, der automatisch ausgelöst wird, wenn das Paket installiert wird.
Vor heute, tanstack@2.0.3 (im März veröffentlicht) hatte keinen postinstall Hook. Es war ein sauberes Paket ohne Netzwerkaufrufe. Doch das änderte sich heute.
Der postinstall.cjs Skript liest Umgebungsdateien aus dem Arbeitsverzeichnis der Entwickelnden und sendet deren Inhalte an einen vom Angreifer kontrollierten Svix-Webhook-Endpunkt. Keine Aufforderungen. Keine sichtbare Ausgabe in den meisten Versionen. Es wird einfach ausgeführt und beendet.
Das Paket hatte im letzten Monat vor Beginn dieser Kampagne rund 19.830 Downloads.
Die Payload
Das Skript ist unkompliziert. Bei der Installation liest es lokale Dateien und POSTet sie als JSON an diesen Endpunkt:
https://api.svix.com/ingest/api/v1/source/src_3387PLMB2uhXOBe3Q8sHu/in/3j2jokvbaF4WWdngv8zBbk
Svix ist ein seriöses Webhooks-as-a-Service-Unternehmen. Der Angreifer nutzt dessen Produkt „Ingest“ als Exfiltrations-Relay, um gestohlene Daten über einen vertrauenswürdigen Drittanbieter zu leiten und so eine Blockierung auf Netzwerkebene zu umgehen.
Die Payload enthält Dateiinhalte sowie System-Metadaten:
{
"package": "tanstack",
"version": "2.0.x",
"event": "postinstall",
"readme": "<contents of .env>",
"agents": "<contents of .env.local>",
"timestamp": "...",
"node": "v22.x.x",
"platform": "linux",
"arch": "x64"
}Die Feldnamen (readme, agents) sind eine Ablenkung. 🪄 Was tatsächlich gesendet wird, ist Ihr .env und .env.local.
Vier Versionen, 27 Minuten, ein Angreifer testet live
Die Versionshistorie ist der interessanteste Teil dieses Vorfalls. Der Angreifer veröffentlichte innerhalb einer halben Stunde vier Releases und iterierte dabei sichtbar an seiner Payload zwischen jedem Push.
2.0.4 (17:08): Zielt auf .env und .env.local. Die Opt-out-Prüfung (TANSTACK_TELEMETRY_OPT_OUT) ist auskommentiert, was bedeutet, dass es keinen Escape gibt. Enthält eine doppelte postinstall.js Datei, die in keiner anderen Version vorkommt. Importiert das http Modul, verwendet es aber nie.
2.0.5 (17:11, drei Minuten später): Ändert die Zieldateien zu README.md und AGENTS.md. Aktiviert auch den Opt-out-Mechanismus wieder. Dies sieht nach einem kurzen Umweg aus — entweder wurde getestet, ob der Webhook Daten empfing, oder es war ein Versuch, den Hook harmloser erscheinen zu lassen, bevor man zurückschwenkte. README.md ist keine Anmeldedatei.
2.0.6 (17:26): Die gefährliche Version. Verwirft die Ziel-Dateipfade vollständig und ersetzt sie durch einen Verzeichnis-Sweep:
function collectEnvFiles() {
const allFiles = fs.readdirSync(rootDir);
const matches = allFiles.filter(
(f) => f === ".env" || f.startsWith(".env.")
);
for (const file of matches) {
envFiles[file] = fs.readFileSync(path.join(rootDir, file), "utf-8");
}
return envFiles;
}Dies erfasst alles: .env, .env.local, .env.production, .env.staging, .env.development. Alles davon wird in einem einzigen POST gesendet. Die Konsolenausgabe ist vollständig unterdrückt. Der Opt-out ist wieder auskommentiert.
2.0.7 (17:35): Kehrt zurück zu .env + .env.local Targeting, hält die Konsolenausgabe auskommentiert. Fügt eine merkwürdige selbstreferenzielle Abhängigkeit hinzu "tanstack": "^2.0.6" in seiner eigenen package.json. Ob das ein Fehler ist oder einem bestimmten Zweck dient, ist unklar.
Was Sie in dieser Versionshistorie sehen, ist Live-Debugging. Der Angreifer passte seine Zielausrichtung an, testete seinen Receiver und optimierte auf Tarnung, während das Paket öffentlich verfügbar und installierbar war.
Der Aspekt des Name Squatting
Der @tanstack Organisation veröffentlicht einige der meistgenutzten JavaScript-Bibliotheken auf npm: Allein TanStack Query verzeichnet wöchentlich rund 8 Millionen Downloads. Die tanstack unscoped Name liegt seit Dezember 2024 separat vor.
Eine Entwickelnde, die npm install tanstack anstatt npm install @tanstack/query bekommt nicht das, was sie erwartet. Sie bekommt dies.
Das README des Pakets ist ausgefeilt. Es enthält ein Sponsoring-Badge, npm-Download-Shields, eine Feature-Vergleichstabelle und Codebeispiele. Es präsentiert sich als echtes Produkt. Die Tarnung ist gut genug, dass ein flüchtiger Blick sie nicht als verdächtig einstufen würde.
Was gestohlen wird
In einem typischen JavaScript-Projekt .env Dateien enthalten:
- AWS Access Keys und Secrets
- GitHub Personal Access Tokens
- npm Publish Tokens
- Datenbank-Verbindungsstrings
- Stripe-, Twilio-, Resend-, SendGrid-API-Keys
- OpenAI-, Anthropic- und andere LLM-API-Keys
- OAuth Client Secrets
- Alle weiteren lokal konfigurierten Drittanbieter-Zugangsdaten
Wenn Sie eine .env.production Datei irgendwo in der Nähe Ihres Arbeitsverzeichnisses haben (Version 2.0.6 hätte sie gefunden), werden bei der Installation Produktionszugangsdaten an einen Angreifer übergeben.
Behebung und Erkennung
Schritt 1: Prüfen Sie, ob Sie betroffen waren
Überprüfen Sie Ihre Lock-Dateien und Installationshistorie auf eine dieser Paketversionen:
# Check package-lock.json
grep -r "tanstack" package-lock.json yarn.lock pnpm-lock.yaml 2>/dev/null
# Check node_modules
ls node_modules/tanstack/package.json 2>/dev/null && cat node_modules/tanstack/package.json | grep '"version"'Betroffene Versionen: 2.0.4, 2.0.5, 2.0.6, 2.0.7. Wenn eine dieser Versionen in einer Lock-Datei auftaucht, behandeln Sie Ihre Umgebungsdateien als kompromittiert.
Schritt 2: Wenn Sie betroffen waren
Gehen Sie davon aus, dass jede .env Datei, die zum Zeitpunkt der Installation im Arbeitsverzeichnis vorhanden war, exfiltriert wurde. Rotieren Sie sofort:
- AWS-Zugriffsschlüssel und Secrets (überprüfen Sie CloudTrail auf nicht autorisierte API-Aufrufe)
- GitHub-Tokens mit Repo- oder Org-Geltungsbereich
- npm-Tokens — unter npmjs.com/settings widerrufen und neu ausstellen
- Alle Datenbankzugangsdaten, die in
.env - Alle API-Schlüssel von Drittanbietern in den betroffenen Dateien
Für CI-Umgebungen: Der Postinstall-Hook wird während npm ci ebenfalls ausgelöst. Wenn Ihre CI-Pipeline dieses Paket installiert hat, rotieren Sie alle Secrets, die in die Umgebung dieser Pipeline injiziert wurden. Überprüfen Sie die Job-Logs Ihres CI-Anbieters auf den Installationsschritt zum Zeitpunkt der Kompromittierung.
Für Entwickelnden-Maschinen: Dies ist eine persistente Datenexfiltration, kein In-Memory-Angriff. Die Dateien wurden gelesen und gesendet. Es gibt keine abgelegten Binärdateien oder Persistenzmechanismen zu bereinigen, aber Ihre Zugangsdaten sind bereits offengelegt.
Suchen Sie nach ausgehendem HTTPS-Traffic zu api.svix.com in Ihren Netzwerk-Logs zum Zeitpunkt der Installation. Der POST-Request wäre vom CI-Runner oder der Entwickelnden-Maschine gekommen, die die Installation durchgeführt hat.
Schritt 3: Mit Aikido erkennen
Wenn Sie ein Aikido-Benutzer sind, überprüfen Sie Ihren zentralen Feed und filtern Sie nach Malware-Problemen. Die Schwachstelle wird als 100/100 kritisches Problem im Feed angezeigt. Tipp: Aikido scannt Ihre Repos nächtlich neu, wir empfehlen jedoch, auch einen vollständigen Neu-Scan auszulösen.
Wenn Sie noch kein Aikido-Benutzer sind, richten Sie ein Konto ein und verbinden Sie Ihre Repos. Unsere proprietäre Malware-Abdeckung ist im kostenlosen Plan enthalten (keine Kreditkarte erforderlich).
Schritt 4: Zukünftiger Schutz (SafeChain)
Für zukünftigen Schutz ziehen Sie die Verwendung von Aikido SafeChain (Open Source) in Betracht, einem sicheren Wrapper für npm, npx, yarn, pnpm und pnpx. SafeChain integriert sich in Ihre aktuellen Workflows, fängt Paketinstallationsbefehle ab und überprüft Pakete vor der Installation auf Malware anhand von Aikido Intel. Stoppen Sie Bedrohungen, bevor sie Ihr System erreichen.
IOCs
tanstack@2.0.4— SHA256:72ec4571e27c06f1d48737477c2b38a4f90d699950dab8946b48591133dc4f90tanstack@2.0.5— SHA256:04ee5325c8900c9d644ed81c9012525b6fc19f21c65cef85b6ba98b6a0a23566tanstack@2.0.6— SHA256:abc164807947b102164488a08161adb4ee08be6b78a371350a6b156eed0d97d9tanstack@2.0.7— SHA256:7bb84e6ba893248814cd3bac70b7bdc115740fba9e13419940c73460cbcd7b6f- Exfiltrations-Endpunkt:
hxxps://api.svix[.]com/ingest/api/v1/source/src_3387PLMB2uhXOBe3Q8sHu/in/3j2jokvbaF4WWdngv8zBbk - Svix-Quell-ID:
src_3387PLMB2uhXOBe3Q8sHu - npm Maintainer-Konto:
sh20raj
Fazit
Dieser Angriff erinnert uns daran, wie wenig es braucht, um ein Name-Squatting-Setup in einen aktiven Credential Harvester zu verwandeln. Der Angreifer musste weder einen Maintainer kompromittieren, ein CI-System phishen noch eine Schwachstelle ausnutzen. Er registrierte ein plausibel klingendes Paket, fügte ein einseitiges Postinstall-Skript hinzu und wartete, bis die Installationen erfolgten.
Das Iterationsmuster über vier Versionen ist bemerkenswert. Dies war keine einmalige Bereitstellung. Der Angreifer war präsent, beobachtete und passte seine Payload in Echtzeit an. Das ist jemand, der weiß, was er tut, und der speziell auf die Abdeckung von Anmeldeinformationen optimiert hat.
Jeder .env Datei in Ihrem Projekt ist ein Ziel. Jedes Paket mit einem Postinstall-Hook kann diese lesen. Die npm Registry gibt jedem Publisher diese Fähigkeit standardmäßig.
