GRAFANA HAT EINEN BRUTALEN BREACH: Am 16. Mai 2026 meldete der Open-Source-Monitoring-Hersteller, dass UNBEFUGTE die komplette Codebase aus dem GitHub-Repo gezogen haben — und dann das Unternehmen zu erpressen versuchten. Grafana hat den Lösegeld-Forderungen NICHT nachgegeben. Das FBI hatte dem Team explizit dazu geraten, denn jede Zahlung lockt nur den nächsten Erpresser an.
WIE ist der Angriff abgelaufen?
Die Wurzel der Lecke war eine kürzlich aktivierte GitHub Action mit dem berüchtigten „Pwn-Request“-Bug. Klingt nach Hackergeschwätz, ist aber eine echte Misconfiguration-Klasse: Ein Workflow läuft auf pull_request_target-Events — das heißt, der Code des Pull-Requests wird mit den GEHEIMNISSEN des Hauptrepos ausgeführt. Wenn der Workflow dann auch noch beliebigen Code aus dem PR-Fork ausführt (z.B. ein curl-Aufruf in einem Build-Script), ist die Tür komplett offen.
SO einfach lief der Klau
Der Angreifer hat:
- Ein Grafana-Repo geforkt.
- Bösartigen Code in einen Build-Script-File geschoben (curl-Befehl, der die Environment-Variablen ausliest).
- Diese Variablen verschlüsselt in eine File geschrieben.
- Mit den dort enthaltenen privilegierten Tokens dann Zugriff aufs GitHub-Environment bekommen und die Codebase abgesaugt.
WIE haben sie es BEMERKT?
Klassischer Canary-Token: Grafana verteilt tausende falsche Credentials in seine Systeme, die normal NIEMAND anfassen würde. Sobald einer davon getriggert wird, schlägt das Security-Team Alarm. Genau das ist passiert — die forensische Analyse fand zügig die Quelle, kompromittierte Tokens wurden invalidiert, zusätzliche Schutzmaßnahmen aktiviert.
KEINE Kundendaten betroffen — aber…
Grafana betont, dass keine personenbezogenen Daten und keine Kundendaten kompromittiert wurden. Die Angreifer haben „nur“ den Source-Code mitgenommen. Doch genau das ist heikel: Wer den Code hat, kann gezielt nach unentdeckten Bugs suchen. Wer Grafana on-prem fährt, sollte den eigenen Patch-Stand JETZT überprüfen und in den nächsten Wochen sehr aufmerksam auf Security-Releases gucken.
WAS HEISST DAS für DICH?
Wenn du irgendwo eigene GitHub-Workflows betreibst — und das tut JEDER, der ein Open-Source-Projekt pflegt — JETZT checken:
- Hast du Actions, die auf
pull_request_targetreagieren? - Werden in diesen Actions ARBITRARY Scripts oder Build-Tools aus dem PR-Fork ausgeführt?
- Sind die Secrets so eingerichtet, dass sie auch in Fork-PRs verfügbar sind?
Wenn drei mal Ja → SOFORT die Workflows auf pull_request umstellen (ohne _target) oder Secrets explizit deaktivieren. GitHub hat die Pattern selbst dokumentiert, aber viele Repos haben das nie umgesetzt.
EXTRA-TIPP: Canary-Tokens für JEDES Projekt
Was Grafana gerettet hat, kannst auch DU einbauen: Canary-Tokens. Das sind harmlose Dummy-Credentials, die irgendwo im Repo, in der Doku oder in Build-Outputs liegen. Tools wie canarytokens.org oder thinkst-canary liefern die kostenlos. Sobald jemand sie benutzt, kriegst du einen Alert — und weißt sofort, dass jemand deine Codebase abgegrast hat.
FAZIT: Open-Source-Strenge gilt fürs Build-System AUCH
Der Grafana-Breach zeigt: Du kannst die beste App-Sicherheit der Welt haben — wenn der CI/CD-Pipeline ein Loch hat, geht trotzdem alles flöten. Pwn-Request ist eines der häufigsten GitHub-Action-Probleme. Audit deine Workflows JETZT. Und wenn ein Erpresser klingelt: NICHT zahlen. Grafana hat es vorgemacht.
Häufige Fragen
Was wurde konkret gestohlen?
Bin ich als Grafana-Nutzer betroffen?
Was ist eine Pwn-Request-Lücke?
pull_request_target-Events laufen mit den Secrets des Hauptrepos. Wenn der Workflow dann Code aus dem PR-Fork ausführt, kann der Forker beliebigen Code mit deinen privilegierten Tokens ausführen. Lösung: pull_request ohne _target nutzen oder Secrets explizit blocken.Warum hat Grafana das Lösegeld verweigert?
Quellen: