Wiz entdeckt CI/CD-Schwachstelle in Snowflake-GitHub-Repository

Forschende des Unternehmens Wiz haben eine Schwachstelle des Typs workflow injection im öffentlichen Repository snowflakedb/snowflake-connector-net auf GitHub entdeckt, die es einem Angreifer ermöglichte, durch das Erstellen eines speziell präparierten Issues beliebige Befehle in der GitHub-Actions-Runner-Umgebung auszuführen. Im Rahmen eines autorisierten Tests extrahierten die Forschenden ein Jira-API-Token, das ihnen zufolge Lesezugriff auf interne Snowflake-Projekte gewährte, darunter Engineering-Aufgaben, Nachverfolgung der Einhaltung von Sicherheitsanforderungen und Bug-Bounty. Die Schwachstelle bestand in der CI/CD-Automatisierung des Repositories fünf Tage lang – vom 18. bis 23. Juni 2026 – und wurde am Tag des Eingangs des Reports behoben. Betroffene Releases des Connectors für .NET wurden nicht festgestellt.

Mechanismus der Schwachstelle

Das Problem befand sich in der Datei .github/workflows/jira_issue.yml, die beim Öffnen eines öffentlichen Issues im Repository ausgelöst wurde. Der Workflow enthielt zwei kritische Fehler:

• Direkte Interpolation von Benutzereingaben in einem Shell-Block: Titel und Text des Issues wurden direkt in den run:-Block eingesetzt, was einen klassischen Angriffsvektor für Command Injection schuf. Ein Angreifer konnte beliebige Shell-Befehle über den Inhalt des Issues einschleusen.
• Unwirksame Autorisierungsprüfung: Der Workflow prüfte den Wert von github.event.pull_request.user.login, obwohl das auslösende Ereignis ein Issue und kein Pull Request war. Laut GitHub-Dokumentation liefert der Zugriff auf eine im Kontext nicht vorhandene Eigenschaft einen leeren String zurück. Infolgedessen schlug der Vergleich mit whitesource-for-github-com[bot] als Filter immer fehl, und jeder Benutzer konnte die Ausführung des Workflows auslösen.

Im selben Schritt des Workflows standen die Secrets JIRA_BASE_URL, JIRA_USER_EMAIL und JIRA_API_TOKEN zur Verfügung, was bedeutete: Eine erfolgreiche Command Injection verschaffte automatisch Zugriff auf diese Anmeldedaten.

Exploitation und Auswirkungsumfang

Nach Angaben von Wiz wurde die Schwachstelle von ihrem automatisierten System Red Agent im Rahmen eines autorisierten Sicherheitstests entdeckt und ausgenutzt. Die erste Payload führte zu einem Shell-Syntaxfehler, woraufhin das System seinen Ansatz anpasste. Die Forschenden berichten, dass sie einen out-of-band Callback vom GitHub-Actions-Runner erhielten und das Jira-API-Token extrahierten.

Dem Bericht von Wiz zufolge gehörte das Token zum Account [email protected] und gewährte Lesezugriff auf Jira-Projekte in der Domain snowflakecomputing.atlassian.net, die Engineering-Aufgaben, Nachverfolgung der Einhaltung von Sicherheitsanforderungen und Bug-Bounty abdeckten. Es ist anzumerken, dass Details zur Ausnutzung und zum Umfang der erlangten Berechtigungen ausschließlich auf den Aussagen von Wiz basieren – öffentliche Audit-Logs von Snowflake wurden nicht offengelegt.

Chronologie und Behebung

• 18. Juni 2026 – der verwundbare Workflow gelangte über Pull Request #1218 in den Main-Branch (Squash-Merge, Commit 4a1b8ce).
• 23. Juni 2026 – Wiz reichte den Report über HackerOne ein (Report #3819931). Am selben Tag implementierte Snowflake den Fix in Pull Request #1402, indem die direkte Verwendung von GitHub-Ausdrücken durch die Übergabe der Werte über Umgebungsvariablen an jq ersetzt wurde.
• 24. Juni 2026 – laut Wiz wurde das Jira-Token rotiert.

Snowflake erklärte in einem von Wiz wiedergegebenen Statement, dass die Untersuchung „keine Hinweise auf unbefugten Zugriff festgestellt“ habe. Nach Angaben von Wiz ergab die Prüfung von Snowflake keine Nutzung des Tokens durch Dritte im fünf Tage umfassenden Zeitfenster der Exposition. Allerdings wurden die Audit-Logs von Snowflake nicht veröffentlicht, sodass eine unabhängige Verifizierung dieser Aussagen nicht möglich ist.

Frage der Attribution: die Rolle von GitHub Copilot

Wiz beschrieb die Schwachstelle als Resultat einer Änderung, die von GitHub Copilot Autofix eingebracht worden sei. Die Analyse der Commit-Historie im Repository zeichnet jedoch ein komplexeres Bild. Der Commit 6d0e2fa, der ausdrücklich als Co-Autorschaft von Copilot Autofix gekennzeichnet ist, änderte die Datei jira_close.yml, nicht jedoch das verwundbare jira_issue.yml. Das unsichere Refactoring von jira_issue.yml befindet sich in einem separaten Commit 094038e, der dem GitHub-Entwickler sfc-gh-hpathak zugeschrieben ist. Beide Änderungen gingen in den finalen Squash-Merge 4a1b8ce ein, in dem Copilot Autofix als einer der Co-Autoren aufgeführt ist. Damit ist die Beteiligung von Copilot am Pull Request belegt, nicht jedoch die Autorenschaft der konkret verwundbaren Codezeilen.

Systemisches Problem und Empfehlungen

Dieser Vorfall ist ein typisches Beispiel für eine Klasse von Schwachstellen, die von GitHub bereits im Juli 2025 dokumentiert wurde: die direkte Einbindung nicht vertrauenswürdiger Daten aus Ereignissen (Issue-Titel, -Text, Kommentare) in run:-Blöcke von GitHub Actions. Der empfohlene Ansatz ist die Verwendung von zwischengeschalteten Umgebungsvariablen, was auch in Snowflakes Fix umgesetzt wurde.

Organisationen, die GitHub Actions in öffentlichen Repositories einsetzen, sollten:

• Einen Audit aller Workflow-Dateien durchführen, um direkte Interpolation von Ausdrücken ${{ github.event.* }} innerhalb von run:-Blöcken zu identifizieren. Sämtliche Daten aus Issues, Pull Requests oder Kommentaren sollten über Umgebungsvariablen übergeben werden.
• Filterbedingungen in Workflows prüfen: sicherstellen, dass Autorisierungsprüfungen auf Eigenschaften verweisen, die im Kontext des tatsächlich auslösenden Ereignisses existieren. Eine Diskrepanz zwischen Ereignistyp und geprüfter Eigenschaft führt zur Umgehung des Filters.
• Den Geltungsbereich von Secrets minimieren: keine Anmeldedaten in Schritte übergeben, die Benutzereingaben verarbeiten. Schritte zur Validierung der Eingabedaten und Schritte, die Secrets verwenden, sollten getrennt werden.
• Automatisiertes Scanning von Workflow-Dateien einführen – etwa mit Tools wie actionlint – um unsichere Interpolationsmuster bereits in der Code-Review-Phase aufzuspüren.

Dieser Fall zeigt, dass selbst bei Abwesenheit einer Schwachstelle im eigentlichen Softwareprodukt eine Kompromittierung der CI/CD-Infrastruktur eines öffentlichen Repositories zur Offenlegung interner Anmeldedaten mit Zugriff auf Unternehmenssysteme führen kann. Das fünf Tage umfassende Expositionsfenster und die zeitnahe Behebung am Tag des Reports sind ein positives Beispiel für Reaktion, doch die Tatsache, dass unsicherer Code überhaupt in den Main-Branch gelangt ist, unterstreicht die Notwendigkeit, Sicherheitsprüfungen für Workflows vor dem Merge zu verstärken. Organisationen mit öffentlichen Repositories auf GitHub sollten ihre Actions-Konfigurationen unverzüglich auf vergleichbare Muster direkter Datenübernahme aus Ereignissen überprüfen.