Eine neue Meldung aus der Sicherheitsforschung zeigt, wie schnell CI/CD-Automatisierung zum Einfallstor werden kann: Wiz berichtet über eine GitHub Actions-Workflow-Schwachstelle in einem öffentlichen Snowflake-Repository. Betroffen war ein Workflow, der bei dem Öffnen einer öffentlichen GitHub-Issue startete und dabei Jira-Zugangsdaten in einem Shell-Schritt verfügbar machte.
Wichtig: Nach den vorliegenden Angaben konnte die Schwachstelle auf die CI/CD-Automationen des Repositories begrenzt werden. Für den Snowflake Connector for .NET wurde laut Wiz keine betroffene Release identifiziert. Dennoch ist der Fall ein prägnantes Beispiel dafür, wie gefährlich es sein kann, nicht vertrauenswürdige Nutzereingaben direkt in Shell-Logik einzubetten.
Was genau war die Schwachstelle?
Wiz beschreibt eine Workflow-Injection, die sich über eine gezielt gestaltete GitHub-Issue ausnutzen ließ. Der relevante Workflow befand sich in .github/workflows/jira_issue.yml und startete, sobald eine öffentliche Issue geöffnet wurde. In diesem Schritt wurden Werte wie JIRA_BASE_URL, JIRA_USER_EMAIL und JIRA_API_TOKEN im selben Job bereitgestellt.
Der zentrale Fehler lag darin, dass die Workflows Logik-Werte aus der Issue direkt in einem Shell-Befehl in ein run-Block einfügte. Damit hatten Angreifer die Möglichkeit, die Struktur der Shell-Kommandos zu beeinflussen—mit dem Ergebnis einer möglichen Command Injection.
Warum reichte ein Issue statt eines Pull Requests?
Ein weiterer Aspekt betrifft die Bedingungsprüfung innerhalb des Workflows. Laut Wiz wurde in einem Vergleich auf github.event.pull_request.user.login geprüft, obwohl es sich beim Auslöser nicht um ein Pull Request-Event, sondern um ein Issue-Event handelte.
GitHub erklärte dazu sinngemäß, dass beim Dereferenzieren einer nicht existierenden Property ein leerer String entsteht. In der konkreten Implementierung führte dieser Umstand jedoch nicht dazu, dass normale Issues sicher blockiert wurden. Dadurch konnte eine gewöhnliche Issue weiterhin den Job auslösen—und damit auch den gefährlichen Shell-Schritt.
Wie Wiz die Schwachstelle demonstrierte
Wiz schildert, dass sein Red-Agent-System die Schwachstelle im Rahmen eines autorisierten Sicherheitschecks ausnutzte. Beim ersten Payload-Versuch kam es zunächst zu einem Shell-Syntaxfehler. Anschließend passte das System den Ansatz an, um die Injektion erfolgreich zu treiben.
Im Zuge der zweiten Phase berichteten die Forschenden von einem Out-of-Band Callback vom GitHub Actions Runner. Offensichtlich konnte dadurch eine Antwort über den Runner belegt werden. Auf diese Weise gelang es Wiz, das im Workflow verwendete Jira API Token zu ermitteln.
Welche Daten waren betroffen: Jira-Token und Berechtigungen
Das von Wiz beschriebene Token soll einem Konto zugeordnet gewesen sein, das als qa@snowflake.net benannt wird. Laut Wiz ermöglichte es Read-Zugriff auf Jira-Projekte, die Themen rund um Engineering, Security Compliance und auch Bug-Bounty-Tracking abdecken.
Als Jira-Umgebung nennt Wiz snowflakecomputing.atlassian.net. Gleichzeitig betonen die Forschenden, dass die zugrunde liegenden Details—etwa konkrete Workflow-Runs, konkrete Jira-Permissions auf Objekt-/Issue-Ebene sowie Audit Records—nicht öffentlich einsehbar sind.
Reaktion von Snowflake und technische Korrektur
Wiz meldete den Fehler am 23. Juni 2026 über den HackerOne-Kanal an Snowflake, registriert unter der Report-Nummer #3819931. Laut Bericht reagierte Snowflake mit einem Fix, der am selben Tag in einem Pull Request mit der Nummer #1402 zusammengeführt wurde.
Der Kern der Gegenmaßnahme: Snowflake ersetzte die direkte Expansion von GitHub-Ausdrücken durch die Verwendung von Umgebungsvariablen. Diese Variablen werden anschließend als Argumente an jq übergeben—also auf eine Weise, die das direkte Einbetten untrusted Daten in die Shell-Logik reduziert.
Zeitleiste: Wann war die Schwachstelle im Default Branch?
Wiz führt außerdem eine zeitliche Einordnung an: Der problematische Workflow befand sich bereits seit dem 18. Juni im Default Branch. Damals wurde ein Pull Request mit der Nummer #1218 gemerged. Der Fix selbst ist laut Darstellung im aktuell korrekten Stand in der master-Implementierung enthalten.
Bewertung der Ausnutzung: Was sagt Snowflake?
Snowflake teilte eine Einschätzung mit, die Wiz zitiert: In der Untersuchung habe man keinen Nachweis für unautorisierten Zugriff gefunden. Wiz hält dem gegenüber, dass das Token während der Validierung aus dem Systemkontext gezogen werden konnte.
Darüber hinaus nennt Wiz einen weiteren wichtigen Punkt: Das Token sei am 24. Juni rotiert worden. Snowflake habe außerdem in seiner Überprüfung keine Hinweise auf eine weitere, nicht zusammenhängende Nutzung des Tokens im Zeitraum der fünf Tage gefunden.
Die zugrunde liegenden Audit-Logs, die diese Aussagen stützen könnten, sind laut Bericht nicht öffentlich verfügbar.
Was hat GitHub zu dem Fehlerbild erklärt?
GitHub hatte bereits zuvor eine verwandte Klasse von Risiken dokumentiert. Laut Bericht besteht die Gefahr insbesondere dann, wenn untrusted Issue-Daten direkt in einem run:-Block expandiert werden. Als Empfehlung nennt GitHub die Nutzung von Zwischen-Umgebungsvariablen, damit die Verarbeitung kontrollierter und sicherer erfolgt.
Im vorliegenden Fall passt das Muster: Issue-Titel und -Body wurden laut Wiz in den Shell-Run-Block so eingefügt, dass ein Angreifer die Kommandostruktur beeinflussen konnte.
Stand der offiziellen Einordnung: CVE und KEV
Zum Stand 17. August 2026 habe Wiz keine CVE, keine CVSS-Bewertung und auch keinen Eintrag in der CISA Known Exploited Vulnerabilities (KEV)-Liste für die Schwachstelle finden können. Ebenso wurde laut Bericht keine Connector-Release-Update-Zuordnung identifiziert, die explizit mit dem Problem verknüpft ist.
Gleichzeitig sei die gefährliche Interpolation laut Wiz im Master-Stand nicht mehr vorhanden. Für eine belastbare Aussage über eine großflächige Ausnutzung in der Praxis—bis hin zu konkreten Kundenkompromittierungen—liefere das bisher verfügbare Material keine ausreichende Grundlage.
Einordnung nach Commit-Verlauf: Copilot-Autofix und Risiko
Wiz beschreibt die Entstehung der Schwachstelle im Kontext von GitHub Copilot Autofix. Allerdings stellt der Bericht klar: Der konkrete GitHub-Verlauf belege nicht eindeutig, dass Copilot selbst die anfälligen Zeilen in jira_issue.yml erstellt habe.
Der Bericht nennt eine Unterscheidung zwischen Änderungen: Ein expliziter Commit sei für jira_close.yml mit einem Copilot-Autofix-Bezug angegeben worden. Die gefährliche Umstellung in jira_issue.yml sei dagegen in einem separaten August-Commit enthalten, der von GitHub einem anderen Akteur zugeschrieben wurde.
Beide Änderungen wurden später in einem Squash-Merge-Commit zusammengeführt. In diesem Merge-Commit taucht Copilot Autofix als Mitautor auf. Für das Risiko bedeutet das vor allem: Auch wenn KI-gestützte Automationen beteiligt waren, liegt der technische Kernfehler eindeutig in der gefährlichen Handhabung untrusted Daten im Workflow.
Was sollten Teams aus dem Fall lernen?
Die Meldung lässt sich auf einen einfachen Grundsatz herunterbrechen: Untrusted Input gehört nicht direkt in Shell-Kommandos. Wenn Workflows Ereignisse von öffentlichen Plattformen verarbeiten—wie etwa GitHub Issues—müssen Daten vor der Verwendung in Skripten kontrolliert oder in sichere Verarbeitungspfade überführt werden.
Praktisch heißt das: Nutzen Sie Zwischenvariablen, verarbeiten Sie Inhalte über geeignete Parser (z. B. jq) und reduzieren Sie Stellen, an denen Issue-/Benutzertexte ohne Absicherung in run:-Shell-Blöcke expandiert werden.
Für Organisationen, die Jira oder andere Ticket-Systeme in CI/CD-Prozesse integrieren, ist zudem die Zugriffskontrolle zentral: Selbst wenn ein Token im Workflow existiert, sollte das Risiko durch Minimisierung der Berechtigungen und durch saubere Workflow-Validierung begrenzt werden.
Fazit
Wiz beschreibt eine GitHub Actions-Workflow-Schwachstelle im Snowflake-Connector-Repository, die über eine präparierte Issue zu einer Command Injection führen konnte. Der Workflow gab dabei Jira-Zugangsdaten im Shell-Schritt weiter und baute Issue-Werte direkt in die Kommandoausführung ein. Zusätzlich trug eine fehlerhafte Event-Bedingung dazu bei, dass der Job nicht wie beabsichtigt stoppte.
Snowflake hat den Fehler zeitnah behoben, indem die kritische direkte Expansion durch die Übergabe über Umgebungsvariablen ersetzt wurde. Eine unautorisierte Nutzung konnte Snowflake laut eigener Prüfung nicht belegen; Wiz berichtet jedoch von Token-Ermittlung im Testkontext. Insgesamt ist der Fall eine deutliche Erinnerung daran, CI/CD-Automation konsequent gegen untrusted Daten abzusichern.
Quelle: https://thehackernews.com/2026/08/snowflake-github-actions-flaw-lets_0330881554.html
