Gefährliche GitHub-Aktionen in Open-Source-Projekten entdeckt

Gefährliche GitHub-Aktionen in Open-Source-Projekten entdeckt.

Das Threat Research Team (TRT) von Sysdig hat bei der Analyse von GitHub Actions in zahlreichen Open-Source-Repositories schwerwiegende Sicherheitslücken identifiziert.

Durch fehlerhaft konfigurierte Workflows – insbesondere den missbräuchlichen Einsatz von pull_request_target – konnten Angreifer sich Zugang zu Repositories verschaffen, hochprivilegierte Tokens und sensible Informationen exfiltrieren sowie vereinzelt die vollständige Kontrolle übernehmen. Betroffen waren unter anderem Projekte von MITRE, Splunk und der Spotipy-Community.

Wichtigste Erkenntnisse

• Kritische Schwachstellen in CI/CD-Workflows zahlreicher populärer Repositories – durch falsche Nutzung von pull_request_target.
• Vollständige Repository-Kompromittierung in mindestens einem Fall (CVE-2025-47928), inklusive Schreibzugriff und standardmäßig weitreichenden Rechten mit GITHUB_TOKEN.
• Mehrere betroffene Organisationen: Spotipy, MITRE ATT&CK CAR und Splunk Security Content.
• Einfache Exploits ermöglichten die Einschleusung bösartiger Pakete via pip install aus manipulierten Forks.
• Empfehlungen zur Absicherung: minimale Berechtigungen, Workflow-Trennung und Nutzung von Falco Actions zur Laufzeitüberwachung.

GitHub Actions: Mächtig, aber gefährlich bei Fehlkonfiguration

GitHub Actions ist eines der führenden CI/CD-Werkzeuge im Open-Source-Bereich. Es ermöglicht automatisierte Tests, Builds und Deployments – direkt aus GitHub-Repositories heraus. Doch was viele Entwickler unterschätzen: In Kombination mit falschen Sicherheitseinstellungen kann es Angreifern eine direkte Einflugschneise bieten.

Ein zentrales Risiko stellt dabei der Trigger pull_request_target dar. Er wird häufig verwendet, um Tests und Checks für eingehende Pull-Requests (PR) durchzuführen. Im Gegensatz zu pull_request, der im Kontext des PR-Commits läuft, agiert pull_request_target im Kontext des Haupt-Branches – mit voller Berechtigung und Zugriff auf Secrets. Wird in diesem Kontext jedoch Code aus einem öffentlichen Fork geladen und ausgeführt, entsteht eine massive Sicherheitslücke.

Viele Entwickler verlassen sich auf die GitHub-Funktion „Require approval for all workflow runs from public forks“. Doch Vorsicht: Diese Einstellung greift bei pull_request_target nicht. Da dieser Trigger im Kontext des Haupt-Branches läuft, wird der Workflow unabhängig von einer Freigabe gestartet – selbst wenn der Code aus einem öffentlichen Fork stammt.

So wurde attackiert – drei reale Fallbeispiele

• Spotipy (CVE-2025-47928): Die Python-Bibliothek Spotipy mit über 5.000 GitHub-Sternen war durch einen Workflow verwundbar, der fehlerhaft konfiguriert war. Angreifer konnten einen Pull Request mit einer modifizierten setup.py einreichen. Diese enthielt ein bösartiges Python-Skript, das beim automatischen pip install. ausgeführt wurde. In der Folge wurden Secrets wie API-Schlüssel sowie der GITHUB_TOKEN extrahiert und an einen externen Server übertragen. Die Rechte des Tokens erlaubten sogar Schreibzugriffe auf das Haupt-Repository. Das Skript nutzte zudem das Tool memdump.py, um Secrets aus dem Speicher zu extrahieren
• MITRE CAR (Cyber Analytics Repository): Auch MITREs öffentliches Repository zur analytischen Abdeckung des ATT&CK-Frameworks wies einen kritischen Fehler im Workflow auf. Über eine manipulierte requirements.txt konnten Angreifer beim pip install Code zur Ausführung bringen – mit denselben fatalen Folgen: Exfiltration von Secrets und potenzieller Vollzugriff auf das Repository.
• Splunk Security Content: Im Splunk-Repository konnte das Sysdig TRT ebenfalls eine Schwachstelle aufdecken. Zwar war der GITHUB_TOKEN hier auf das Lesen beschränkt, jedoch nutzte der Workflow zwei hartcodierte Secrets (APPINSPECTUSERNAME, APPINSPECTPASSWORD), die kompromittiert werden konnten. Auch wenn der Token limitiert war, waren dennoch sensible Secrets durch Fehlkonfiguration angreifbar. Eine Rückmeldung auf die Offenlegung erfolgte seitens Splunk bisher nicht, der Workflow wurde allerdings zwischenzeitlich angepasst.

Was Entwickler jetzt tun sollten

Sysdig empfiehlt ein mehrstufiges Sicherheitskonzept für GitHub-Aktionen:

• Vermeiden Sie pull_request_target, es sei denn, der Workflow ist vollständig gegen unautorisierte Ausführung abgesichert.
• Teilen Sie Ihre Workflows auf: Verwenden Sie pull_request für unprivilegierte Prüfungen und workflow_run für nachgelagerte, sensible Schritte.
• Minimieren Sie GITHUB_TOKEN-Berechtigungen. Dies verhindert ungewollte Schreib- oder Deployment-Rechte.
• Implementieren Sie Sicherheits-Gates, etwa über Labels, die nur von Maintainern gesetzt werden können. Diese Technik ist nicht narrensicher, aber ein zusätzlicher Schutzmechanismus.
• Nutzen Sie Tools wie Falco Actions zur Laufzeiterkennung: Sie helfen, verdächtige Aktivitäten wie Datei- und Netzwerkanomalien in CI/CD-Jobs zu identifizieren. Falco erkennt unter anderem Speicherzugriffe und Netzwerkverbindungen, die typischerweise mit Exfiltrationen verbunden sind.

Fazit zu den GitHub-Aktionen

Moderne Supply-Chain-Angriffe auf die Softwareentwicklung beginnen oft in der CI/CD-Pipeline. GitHub Actions bietet enorme Flexibilität – aber auch große Angriffsflächen, wenn nicht korrekt abgesichert. Die Recherche von Sysdig zeigt: Selbst hochkarätige Projekte übersehen diese Risiken. Die Community muss dringend umdenken – und sichere Standards bei der Workflow-Gestaltung etablieren.

Zum vollständigen technischen Report mit konkreten Konfigurationsbeispielen und Abhilfemaßnahmen.