TanStack & VIELE weitere Pakete betroffen - Deep Dive & Analyse

하이라이트

• Ein Supply-Chain-Angriff auf TanStack am 11. Mai 2026 betraf Pakete wie TanStack Query und Router innerhalb eines 20-Minuten-Zeitfensters.

• Die Malware agiert als Wurm, der gezielt NPM-Tokens, GitHub-Tokens und AWS-Zugangsdaten aus Dateisystemen extrahiert.

• Ausgehender Netzwerkverkehr zu einer spezifischen URL dient als Indikator für den erfolgreichen Abfluss sensibler Systemdaten.

• Der Angriff nutzte eine Sicherheitslücke in GitHub Actions über den 'pull_request_target'-Trigger für Cache-Poisoning aus.

• Moderne Paketmanager wie Bun ermöglichen über die bunfig.toml die Festlegung eines Mindestalters für Paket-Releases zur Risikominimierung.

• Die Angreifer extrahierten kurzlebige OIDC-Tokens aus dem Laufzeitspeicher, um bösartige Paketversionen über Trusted Publishing zu signieren.

타임라인

1. 00:00 - 01:38

   Ausmaß und aktuelle Bedrohungslage

   Die Situation ist hochdynamisch und weitete sich innerhalb weniger Stunden vom JavaScript-Bereich auf Python aus. Obwohl die initiale Phase bei TanStack nach 20 Minuten eingedämmt wurde, bleibt das Risiko bei Neuinstallationen hoch. Die Malware zielt auf den Diebstahl von Anmeldedaten ab, um die Infektionskette fortzusetzen.

   • Ein massiver Supply-Chain-Angriff betrifft aktuell das NPM- und Python-Ökosystem.
   • Sämtliche TanStack-Pakete wurden am 11. Mai kurzzeitig mit bösartigen Versionen kompromittiert.
   • Die Infektion verbreitet sich wurmartig auf weitere Bibliotheken wie Mistral-Pakete.
2. 01:38 - 02:54

   Identifikation einer Kompromittierung

   Betroffene Nutzer müssen UTC-Zeitangaben in ihre lokale Zeitzone umrechnen, um das Installationsfenster abzugleichen. Da die Liste der betroffenen Pakete stetig wächst, ist eine allgemeine Vorsicht bei allen Paket-Updates geboten. Die Analyse von Dateihashes bleibt die sicherste Methode zur Verifizierung lokaler Dateiintegrität.

   • Installationen von TanStack-Paketen während des kritischen Zeitfensters am 11. Mai gelten als infiziert.
   • Spezifische SHA-Hashes in JavaScript-Dateien dienen als technischer Beleg für eine Infektion.
   • Überwachungstools für Netzwerkverkehr können Datendiebstahl durch Anfragen an verdächtige URLs nachweisen.
3. 02:54 - 04:38

   Funktionsweise der Schadsoftware

   Der Fokus liegt auf der Gewinnung von Zugangsrechten, die im Klartext auf Entwicklerrechnern oder in Umgebungsvariablen gespeichert sind. Sobald ein CI/CD-Workflow infiziert ist, nutzt der Wurm die dortigen Berechtigungen zur weiteren Skalierung. Dies führt dazu, dass Pakete ohne direktes Zutun der menschlichen Maintainer kompromittiert werden.

   • Die Malware scannt lokale Dateisysteme systematisch nach NPM-, GitHub- und AWS-Geheimnissen.
   • Gestohlene Tokens werden in CI/CD-Workflows missbraucht, um bösartige Versionen abhängiger Projekte zu veröffentlichen.
   • Die Verbreitung erfolgt automatisiert durch die Übernahme von Maintainer-Rechten in Build-Prozessen.
4. 04:38 - 07:56

   Strategien zur Systemhärtung

   Präventive Maßnahmen umfassen die Umstellung auf AWS Single-Sign-On statt statischer IAM-Zugangsdaten. Durch Konfigurationen in pnpm oder Bun lässt sich erzwingen, dass nur Pakete mit einer gewissen Veröffentlichungsdauer installiert werden. Da KI die Analyse von Angriffsvektoren beschleunigt, steigt die Frequenz solcher Vorfälle signifikant an.

   • Die Nutzung von virtuellen Maschinen oder Dev-Containern isoliert den Hauptrechner vor Infektionen.
   • Cloud-basierte Geheimnisverwaltung wie Infisical oder Doppler ersetzt die Speicherung in lokalen .env-Dateien.
   • Sicherheitsfunktionen in Paketmanagern blockieren standardmäßig potenziell gefährliche Post-Install-Skripte.
5. 07:56 - 14:34

   Technische Analyse des Angriffsvektors

   Im Gegensatz zum Standard-'pull_request' bietet 'pull_request_target' Zugriff auf privilegierten Kontext. Der Angreifer schleuste über einen präparierten Pull Request manipulierte Daten in den GitHub Actions Cache ein. Sobald ein Maintainer regulären Code pushte, griff der Build-Prozess auf diesen vergifteten Cache zurück.

   • Der 'pull_request_target'-Trigger ermöglichte die Code-Ausführung im Kontext des Basis-Repositories.
   • Cache-Poisoning übertrug bösartige Abhängigkeiten von einem Fork in den regulären Build-Prozess.
   • Gemeinsam genutzte Caches zwischen verschiedenen Workflows dienten als Transportmittel für den Schadcode.
6. 14:34 - 19:54

   Missbrauch von Trusted Publishing

   Obwohl Trusted Publishing Passwörter überflüssig macht, bleibt das System verwundbar, wenn der ausführende Code selbst infiziert ist. Der TanStack-Angriff scheiterte teilweise an fehlerhaftem Code im CI/CD, was externen Beobachtern auffiel. Dennoch zeigt der Vorfall, dass selbst moderne Sicherheitsmechanismen durch gezielte Laufzeit-Manipulationen umgangen werden können.

   • Bösartiger Code extrahierte kurzlebige OIDC-Tokens direkt aus dem Arbeitsspeicher des CI/CD-Runners.
   • Diskrepanzen zwischen fehlgeschlagenen Workflows und erfolgreichen Veröffentlichungen führten zur Entdeckung.
   • Die aktuelle Software-Explosion bietet Angreifern eine wachsende und oft unzureichend gesicherte Angriffsfläche.