Grafana Labs: Quellcode entwendet nach Supply-Chain-Angriff auf TanStack
Über eine kompromittierte VS-Code-Extension drang ein Info-Stealer in die CI/CD-Pipeline von Grafana Labs ein. Ein bei der Token-Rotation übersehener Schlüssel öffnete den Weg zu privaten GitHub-Repositories.
Grafana Labs hat einen Sicherheitsvorfall öffentlich gemacht: Angreifer haben Teile des Quellcodes aus den privaten GitHub-Repositories des Unternehmens kopiert. Ausgangspunkt war ein Supply-Chain-Angriff auf das TanStack-Ökosystem; ein bei der anschließenden Token-Rotation übersehener GitHub-Workflow-Token verschaffte den Angreifern Zugang.
Worum es geht
Der Angriff begann mit einer kompromittierten Version der Nx Console-Erweiterung für Visual Studio Code. Die TanStack-Supply-Chain-Attacke wird der TeamPCP-Gruppe zugeschrieben, die zuerst dutzende TanStack- und Mistral-AI-npm-Pakete kaperte und anschließend gestohlene CI/CD-Credentials nutzte, um sich seitwärts in andere Projekte zu bewegen. Als Grafana das manipulierte npm-Paket über die eigene CI/CD-Pipeline einspielte, exfiltrierte ein darin enthaltenes Info-Stealer-Modul Workflow-Tokens aus der GitHub-Umgebung. Grafana drehte daraufhin zahlreiche Tokens, übersah dabei aber einen Schlüssel – mit diesem griff der Angreifer später erfolgreich auf private Repositories zu. Die Erpresser-Gruppe CoinbaseCartel reklamierte den Vorfall, Grafana lehnte eine Zahlung ab. Kundendaten oder personenbezogene Informationen seien nach derzeitigem Stand nicht abgeflossen, der heruntergeladene Quellcode sei nicht manipuliert worden.
Wie prüfe ich meine eigene Pipeline?
Wer eigene CI/CD-Pipelines mit npm-Paketen pflegt, sollte die installierten TanStack- und Nx-Pakete inventarisieren. Auf einem Build-Runner mit Node.js:
npm ls --all 2>/dev/null | grep -E '@tanstack|@nx|nx-console'Welche GitHub-Actions-Workflows laufen mit erhöhten Rechten? In einem Repo-Klon:
grep -RhE 'permissions:|GITHUB_TOKEN|secrets\.' .github/workflows/ 2>/dev/null | sort -uToken-Last-Used-Daten im GitHub-Audit-Log abfragen (mit installiertem gh-CLI und passenden Rechten):
gh api -X GET orgs//audit-log --field phrase='action:workflow_run' --paginate | jq '.[] | {actor:.actor, ts:.created_at, action:.action}'Härtung für eigene Setups
Aus dem Vorfall ergeben sich klassische Empfehlungen: kurz lebende, scope-begrenzte Tokens; ein automatisierter Token-Rotation-Job mit nachvollziehbarem Audit; OIDC-Trust statt langlebige PATs für CI/CD; ein zweiter Review-Schritt für npm-Pakete in sicherheitskritischen Projekten (etwa über interne Mirror-Registries oder Tools wie socket.dev). Wer keinen festen Inventar-Prozess für npm-Abhängigkeiten hat, sollte zumindest npm audit signatures in den Build einbauen und Pinning auf Lockfile-Ebene erzwingen.
Für den DACH-Mittelstand zeigt der Fall einmal mehr, dass Supply-Chain-Angriffe nicht nur große Tech-Konzerne treffen. Selbst Anbieter mit reifer Security-Organisation wie Grafana Labs verlieren bei einer übersehenen Rotation viel. Wer eigene Web-Anwendungen oder Build-Pipelines betreibt, sollte das eigene Token- und Secret-Management ehrlich auditieren.
Mehr aus der Kategorie Monitoring: News aus der Kategorie Monitoring
Quellen: heise online – Cyberattack: Attackers copy Grafana source code, BleepingComputer – Grafana breach caused by missed token rotation after TanStack attack.