Im April 2025 wurde Grafana Labs mit einem schwerwiegenden Sicherheitsvorfall konfrontiert, der die gesamte Open-Source-Community und DevOps-Expert:innen in Alarm versetzte. Ein nicht autorisierter Angreifer nutzte eine Schwachstelle in einer GitHub Actions Workflow-Konfiguration innerhalb eines öffentlichen Repositoriums von Grafana aus. Diese sicherheitskritische Lücke führte zur Exposure sensibler Geheimnisse, was ein erhebliches Risiko für die Integrität und Vertraulichkeit der Softwareentwicklung darstellt. Die Ereignisse rund um diese Sicherheitsverletzung geben wertvolle Einblicke in die Herausforderungen der modernen Continuous-Integration/Continuous-Delivery (CI/CD) Infrastruktur und zeigen dringend benötigte Gegenmaßnahmen auf. Die Ursache des Problems liegt primär in einer sogenannten „Pwn Request“-Verwundbarkeit, gepaart mit einer Script-Injection-Schwachstelle, die gemeinsam zum Erstzugriff und schließlich zur Eskalation genutzt wurden.
Dabei wurde eine GitHub Actions Workflow Datei namens pr-patch-check-event. yml im öffentlichen grafana/grafana Repository verwendet, die auf das Ereignis pull_request_target anspricht. Diese Trigger-Art erlaubt es, dass der Workflow mit umfassenden Repository-Berechtigungen inklusive Zugriff auf als Secrets hinterlegte Zugangsdaten ausgeführt wird, selbst wenn der Pull Request von einem externen Fork stammt. Dies stellt per Design ein großes Sicherheitsrisiko dar, wenn Eingaben nicht ausreichend überprüft und bereinigt werden. Der Begriff „Pwn Request“ beschreibt eine kritische Sicherheitslücke in GitHub Actions, bei der externe Pull Requests Workflows mit vollen Repository-Rechten inklusive Zugriff auf sensible Secrets starten können. Wenn der Workflow dabei ungesicherte, von Angreifer:innen kontrollierte Eingaben wie Branch-Namen oder Pull-Request-Titel verarbeitet, ohne diese richtig zu maskieren, entsteht die Möglichkeit, schadhaften Code auszuführen.
Im Fall von Grafana wurde eine speziell manipulierte Branch-Bezeichnung verwendet, welche die Schutzmechanismen durchbrach und es ermöglichte, Anmeldedaten des Bots, der diese Workflows ausführt, zu exfiltrieren. Besonders brisant ist, dass der Angreifer keinen Merge des Pull Requests oder weitere Rechteeskalationen benötigte – der Zugriff erfolgte unmittelbar bei der ersten Ausführung des Workflows. Zusätzlich zum Pwn Request wurde eine Script Injection Schwachstelle ausgenutzt. Diese Art von Verwundbarkeit tritt auf, wenn Workflow-Skripte benutzereingaben ohne angemessene Quoting- oder Sanitisierungsmaßnahmen in Inline-Shell- oder JavaScript-Befehle einbetten. Solche ungesicherten Eingaben können Steuerzeichen enthalten, die aus dem vorgesehenen Ausführungskontext ausbrechen und beliebigen schädlichen Code auf dem Runner ausführen. In der Grafana-Situation wurde angenommen, dass der Branch-Name in einem Node-Skript eingebettet und ohne entsprechende Prüfung ausgeführt wurde.
Das erlaubt einer Angreiferin oder einem Angreifer, Remote-Code-Ausführung zu erlangen und somit die vollständige Kontrolle über den CI-Prozess für den betreffenden Lauf zu übernehmen. Nachdem Zugang zu den Bot-Zugangsdaten erlangt wurde, konnte der Angreifer eine neue bösartige Workflow-Datei namens hrgqavynjp in das Repository einschleusen. Dieser Schadworkflow startete beim Pushen auf einen gleichnamigen Branch und führte eine systematische Sammlung aller verfügbaren GitHub Actions Secrets durch. Anschließend wurden diese Daten mittels AES-256-CBC verschlüsselt und der Schlüssel wiederum mit einem eingebetteten RSA-Public-Key verschlüsselt. Die verschlüsselten Geheimnisse und Schlüssel wurden dann als Artefakte im GitHub Actions System hochgeladen – ein raffinierter Exfiltrations-Ansatz, der versuchte Spuren zu verwischen und eine spätere Entdeckung zu erschweren. Die Aktivitäten des kompromittierten Bots sind im GitHub-Aktivitätsfeed klar nachvollziehbar.
Dort zeigte sich, wie ein neuer Branch erstellt, die Schadsoftware eingespielt und kurz darauf der Branch wieder gelöscht wurde. Dieses Verhalten ist typisch für Angriffe, die möglichst wenig Spuren hinterlassen wollen, um so lange wie möglich unentdeckt zu bleiben. Die Reaktion von Grafana Labs war zügig und professionell. Nach dem Bekanntwerden des Vorfalls wurden alle GitHub Actions in den öffentlichen Repositories deaktiviert. Die internen Untersuchungen zeigten, dass es keinen Zugriff auf Produktionssysteme oder sensible Nutzerdaten gegeben hatte. Dennoch blieb die Gefahr durch die Exfiltration der Botschlüssel bestehen, weshalb umgehend alle relevanten Zugangsdaten ausgetauscht und Workflows abgesichert wurden. Offenheit gegenüber der Community durch zeitnahe Offenlegung des Vorfalls und Zusammenarbeit mit externen Sicherheitsforschenden wie Adnan Khan war ebenfalls ein wichtiger Schritt zur Schadensbegrenzung.
Diese Sicherheitslücke in GitHub Actions mahnt, wie kritisch es ist, CI/CD-Pipelines und automatisierte Workflows mit größter Sorgfalt und Sicherheitsdenken zu gestalten. Es gibt bewährte Strategien, mit denen DevOps-Teams ihre Repositories und Workflows schützen können und sollten. Sensible Secrets wie Tokens oder Zertifikate sollten nicht in Workflows verfügbar sein, die auf pull_request_target Trigger reagieren, es sei denn, diese Trigger sind absolut notwendig. Noch besser ist es, auf sicherere Trigger wie pull_request oder workflow_dispatch auszuweichen, die keine erhöhten Rechte an untrusted Code weitergeben. Ein weiterer essenzieller Schutzansatz ist die ständige Überprüfung und Rotation von Secrets. Geheimnisse, die wirklich benötigt werden, sollten regelmäßig erneuert werden, um den potenziellen Schaden durch deren Exfiltration zu minimieren.
Die Nutzung von Environment Secrets mit verpflichtenden manuellen Review-Prozessen kann zudem den Zugriff auf kritische Produktionsgeheimnisse kontrollieren. Dabei wird erst durch eine autorisierte Freigabe die Nutzung eines Secrets im Workflow erlaubt. Darüber hinaus hilft das Minimieren von App-Berechtigungen, wie sie beispielsweise bei GitHub Apps vorhanden sind, dabei, die Schadensausbreitung im Falle einer Kompromittierung zu beschränken. Jeder Workflow, jeder App-Token und jede Berechtigung sollte auf den kleinstmöglichen Satz von Zugriffsrechten beschränkt werden, die für die ordnungsgemäße Funktion wirklich notwendig sind. Ein innovativer Schutzmechanismus ist die Einführung von Netzwerk- und Laufzeitüberwachung auf Runnern. Tools wie Harden-Runner überwachen Live-Vorgänge, erkennen ungewöhnliche Netzwerkverbindungen oder massenhafte Speicherzugriffe, die auf ein Ausspähen von Geheimnissen hindeuten könnten.
Solche Echtzeitalarme ermöglichen schnelles Eingreifen und können so größere Schäden verhindern. Als letzter wichtiger Mechanismus sollte für alle öffentlichen Fork-Pull Requests die Möglichkeit zur Ausführung der Workflows auf Genehmigungspflicht stehen. Dies ist eine zentrale Einstellung in GitHub, die verhindert, dass automatisierte Builds mit sensiblen Rechten ohne kontrollierte Freigabe ausgeführt werden. Gerade für große Open-Source-Organisationen ist diese Maßnahme unverzichtbar. Der Vorfall bei Grafana Labs zeigt eindringlich, dass die Kombination aus modernen DevOps-Methoden und Sicherheitsbewusstsein Hand in Hand gehen muss. GitHub Actions haben die Entwicklung und Automatisierung von Software wesentlich vereinfacht. Gleichzeitig erfordern sie aufgrund ihrer engen Verzahnung mit sensiblen Zugriffsrechten ein besonders wachsam gestaltetes Sicherheitskonzept.
Nur so lassen sich die Vorteile der Automatisierung nutzen, ohne die Gefahr schwerwiegender Sicherheitsvorfälle einzugehen. Die Continuous-Integration-Landschaft wird sich weiterentwickeln, und das Sicherheitslevel muss mitwachsen. Die Öffentlichkeit, Entwicklerinnen und Entwickler sowie Unternehmen lernen kontinuierlich aus solchen Vorfällen und verbessern ihre Praktiken. Die Offenlegung bei Grafana, die darauffolgenden Empfehlungen und die Entwicklung neuer Sicherheits-Tools wie Harden-Runner sind Schritte in diese Richtung. Abschließend verdeutlicht dieser Vorfall, wie wichtig gründliche Code-Reviews, die sorgfältige Behandlung von Eingaben und eine strikte Geheimnisverwaltung in automatisierten Build-Prozessen sind. Der Schutz vor „Pwn Request“-Angriffen und Script Injection ist heute ein Muss, um den zunehmenden Cyber-Bedrohungen zu begegnen.
Entwickler und Organisationen sollten diese Lektionen in ihre Sicherheitsstrategie integrieren, um die Integrität ihrer Software sowie das Vertrauen der Nutzer nachhaltig sicherzustellen.
