Das war sicherheitsrelevant, weil GitHub den Ausdruck bereits vor der Ausführung durch die Shell erweitert. Ein manipuliertes Issue mit einem einfachen Anführungszeichen konnte dadurch die vorgesehene Zeichenkette beenden und eigene Shell-Befehle anhängen. Eine nachgelagerte Bereinigung mit sed kam zu spät: Zu diesem Zeitpunkt war die gefährliche Interpretation durch die Shell bereits möglich.

Auch der Trigger issues: opened machte den Inhalt nicht vertrauenswürdig. In einem öffentlichen Repository kann grundsätzlich jeder Nutzer, der ein Issue eröffnen darf, dessen Titel kontrollieren. Eine Bedingung, die lediglich die Art des GitHub-Ereignisses prüft, verhindert keine Shell-Injektion über vom Angreifer gelieferte Daten.

Der Commit führte „Copilot Autofix powered by AI“ als Co-Autor auf. Die vorliegenden Belege klären jedoch nicht abschließend, ob Copilot die unsichere Änderung selbst erzeugte oder eine von Menschen verfasste Änderung lediglich mitprüfte. Belastbar ist daher: Copilot war mit der Änderung verbunden und erkannte die Injektion nicht – eine eindeutige Urheberschaft des Modells ist damit nicht bewiesen.

Wie der Red Agent die Lücke fand

Wiz’ Red Agent untersuchte die öffentliche GitHub-Organisation von Snowflake automatisiert auf riskante CI/CD-Muster. Dabei erkannte das System, dass der Jira-Workflow nicht vertrauenswürdige Issue-Daten in einem run:-Block verarbeitete. Daraus leitete der Agent ab, dass ein speziell formulierter öffentlicher Issue-Titel beliebige Befehle auf dem von GitHub bereitgestellten Actions-Runner ausführen könnte.

Am 23. Juni – fünf Tage nach dem Zusammenführen der anfälligen Änderung – eröffnete der Agent im Rahmen von Snowflakes HackerOne-Programm ein präpariertes Issue. Der Titel brach aus der vorgesehenen Shell-Zeichenkette aus. Der eingeschleuste Befehl übermittelte die Jira-Zugangsdaten über einen Out-of-Band-Callback, der für diesen autorisierten Proof of Concept kontrolliert wurde.

Es handelte sich damit nicht um einen unkontrollierten Einbruch, sondern um einen genehmigten Sicherheitstest. Die technische Schwachstelle war dennoch real: Ein öffentliches Issue konnte einen Workflow-Schritt erreichen, der mit internen Zugangsdaten arbeitete, und daraus eine Möglichkeit zur Befehlsausführung machen.

Welche Zugriffe offengelegt wurden

Der kompromittierte Workflow hatte Zugriff auf die Konfiguration des internen Snowflake-Jiras – darunter die Jira-URL, die E-Mail-Adresse des Nutzers und ein API-Token. Der wiederhergestellte Token war dem Konto qa@snowflake.net zugeordnet. Wiz nutzte ihn, um sich am internen Jira-Portal zu authentifizieren und die mögliche Reichweite des Zugriffs zu prüfen.

Die Berichterstattung nennt Lesezugriffe auf Jira-Projekte aus den Bereichen Engineering, Sicherheits-Compliance und Bug-Bounty-Aktivitäten. Die vorliegenden Belege liefern allerdings weder eine vollständige Aufstellung der Token-Berechtigungen noch ein abschließendes Verzeichnis aller erreichbaren Datensätze. Die präziseste Schlussfolgerung lautet daher: Der Token ermöglichte den Zugriff auf sensible interne Jira-Inhalte, nicht nachweislich auf sämtliche Snowflake-Systeme oder uneingeschränkte Unternehmensdaten.

Betroffen war die CI/CD-Automatisierung des Repositorys. Eine veröffentlichte Version des Snowflake Connector für .NET wurde nicht als betroffen gemeldet, weil die Schwachstelle im GitHub-Actions-Workflow und nicht im Laufzeitcode des Connectors lag.

Snowflakes Reaktion

Wiz meldete die Schwachstelle am 23. Juni. Snowflake korrigierte den Workflow noch am selben Tag und rotierte die offengelegten Jira-Zugangsdaten am folgenden Tag.

Anschließend wertete Snowflake die Audit-Logs aus und kam zu dem Ergebnis, dass Wiz während des relevanten Zeitfensters der einzige Akteur war. Wiz erklärte zudem, die im Rahmen des Proof of Concept abgerufenen Daten sicher gelöscht zu haben.

Ein unbefugter Zugriff durch Dritte wurde nicht gemeldet. Ebenso wurde keine CVE-Nummer vergeben und keine betroffene Connector-Version identifiziert. Diese Einschränkungen beschreiben den bestätigten Schaden, machen das ursprüngliche Workflow-Design aber nicht unbedenklich: Ein frei wählbarer Issue-Titel hätte niemals Bestandteil eines Shell-Befehls in einem Workflow werden dürfen, der interne Zugangsdaten verarbeitet.

Die Lehre für GitHub Actions und KI-Codeprüfung

Der Vorfall geht über Snowflake und Copilot hinaus. GitHub-Ausdrücke wie Issue- und Pull-Request-Titel, Branch-Namen oder Kommentare sollten immer als potenziell bösartige Eingaben behandelt werden, sobald sie in einen Shell-Befehl gelangen.

Sicherere Workflows sollten:

• nicht vertrauenswürdige Werte über Umgebungsvariablen statt direkt in run:-Skripte übergeben;
• strukturierte Werkzeuge wie jq zum Erzeugen von JSON verwenden, anstatt Shell-Zeichenketten zusammenzusetzen;
• Daten an der Grenze zur Shell korrekt quoten und validieren;
• Zugangsdaten möglichst aus Workflow-Schritten heraushalten, die angreiferkontrollierte Inhalte verarbeiten;
• KI-generierte oder KI-geprüfte Sicherheitsänderungen genauso gründlich kontrollieren wie Code von Menschen.

Der Fall zeigt eine neue Dynamik in der Anwendungssicherheit: Ein KI-gestütztes Codetool kann eine gefährliche Änderung übersehen, während ein autonomer offensiver Agent dieselbe Lücke innerhalb weniger Tage findet und bestätigt. Automatisierung kann sowohl Abhilfe als auch Ausnutzung beschleunigen – eine unabhängige Sicherheitsprüfung ersetzt sie nicht.

Das war sicherheitsrelevant, weil GitHub den Ausdruck bereits vor der Ausführung durch die Shell erweitert. Ein manipuliertes Issue mit einem einfachen Anführungszeichen konnte dadurch die vorgesehene Zeichenkette beenden und eigene Shell-Befehle anhängen. Eine nachgelagerte Bereinigung mit sed kam zu spät: Zu diesem Zeitpunkt war die gefährliche Interpretation durch die Shell bereits möglich.

Auch der Trigger issues: opened machte den Inhalt nicht vertrauenswürdig. In einem öffentlichen Repository kann grundsätzlich jeder Nutzer, der ein Issue eröffnen darf, dessen Titel kontrollieren. Eine Bedingung, die lediglich die Art des GitHub-Ereignisses prüft, verhindert keine Shell-Injektion über vom Angreifer gelieferte Daten.

Der Commit führte „Copilot Autofix powered by AI“ als Co-Autor auf. Die vorliegenden Belege klären jedoch nicht abschließend, ob Copilot die unsichere Änderung selbst erzeugte oder eine von Menschen verfasste Änderung lediglich mitprüfte. Belastbar ist daher: Copilot war mit der Änderung verbunden und erkannte die Injektion nicht – eine eindeutige Urheberschaft des Modells ist damit nicht bewiesen.

Wie der Red Agent die Lücke fand

Wiz’ Red Agent untersuchte die öffentliche GitHub-Organisation von Snowflake automatisiert auf riskante CI/CD-Muster. Dabei erkannte das System, dass der Jira-Workflow nicht vertrauenswürdige Issue-Daten in einem run:-Block verarbeitete. Daraus leitete der Agent ab, dass ein speziell formulierter öffentlicher Issue-Titel beliebige Befehle auf dem von GitHub bereitgestellten Actions-Runner ausführen könnte.

Am 23. Juni – fünf Tage nach dem Zusammenführen der anfälligen Änderung – eröffnete der Agent im Rahmen von Snowflakes HackerOne-Programm ein präpariertes Issue. Der Titel brach aus der vorgesehenen Shell-Zeichenkette aus. Der eingeschleuste Befehl übermittelte die Jira-Zugangsdaten über einen Out-of-Band-Callback, der für diesen autorisierten Proof of Concept kontrolliert wurde.

Es handelte sich damit nicht um einen unkontrollierten Einbruch, sondern um einen genehmigten Sicherheitstest. Die technische Schwachstelle war dennoch real: Ein öffentliches Issue konnte einen Workflow-Schritt erreichen, der mit internen Zugangsdaten arbeitete, und daraus eine Möglichkeit zur Befehlsausführung machen.

Welche Zugriffe offengelegt wurden

Der kompromittierte Workflow hatte Zugriff auf die Konfiguration des internen Snowflake-Jiras – darunter die Jira-URL, die E-Mail-Adresse des Nutzers und ein API-Token. Der wiederhergestellte Token war dem Konto qa@snowflake.net zugeordnet. Wiz nutzte ihn, um sich am internen Jira-Portal zu authentifizieren und die mögliche Reichweite des Zugriffs zu prüfen.

Die Berichterstattung nennt Lesezugriffe auf Jira-Projekte aus den Bereichen Engineering, Sicherheits-Compliance und Bug-Bounty-Aktivitäten. Die vorliegenden Belege liefern allerdings weder eine vollständige Aufstellung der Token-Berechtigungen noch ein abschließendes Verzeichnis aller erreichbaren Datensätze. Die präziseste Schlussfolgerung lautet daher: Der Token ermöglichte den Zugriff auf sensible interne Jira-Inhalte, nicht nachweislich auf sämtliche Snowflake-Systeme oder uneingeschränkte Unternehmensdaten.

Betroffen war die CI/CD-Automatisierung des Repositorys. Eine veröffentlichte Version des Snowflake Connector für .NET wurde nicht als betroffen gemeldet, weil die Schwachstelle im GitHub-Actions-Workflow und nicht im Laufzeitcode des Connectors lag.

Snowflakes Reaktion

Wiz meldete die Schwachstelle am 23. Juni. Snowflake korrigierte den Workflow noch am selben Tag und rotierte die offengelegten Jira-Zugangsdaten am folgenden Tag.

Anschließend wertete Snowflake die Audit-Logs aus und kam zu dem Ergebnis, dass Wiz während des relevanten Zeitfensters der einzige Akteur war. Wiz erklärte zudem, die im Rahmen des Proof of Concept abgerufenen Daten sicher gelöscht zu haben.

Ein unbefugter Zugriff durch Dritte wurde nicht gemeldet. Ebenso wurde keine CVE-Nummer vergeben und keine betroffene Connector-Version identifiziert. Diese Einschränkungen beschreiben den bestätigten Schaden, machen das ursprüngliche Workflow-Design aber nicht unbedenklich: Ein frei wählbarer Issue-Titel hätte niemals Bestandteil eines Shell-Befehls in einem Workflow werden dürfen, der interne Zugangsdaten verarbeitet.

Die Lehre für GitHub Actions und KI-Codeprüfung

Der Vorfall geht über Snowflake und Copilot hinaus. GitHub-Ausdrücke wie Issue- und Pull-Request-Titel, Branch-Namen oder Kommentare sollten immer als potenziell bösartige Eingaben behandelt werden, sobald sie in einen Shell-Befehl gelangen.

Sicherere Workflows sollten:

• nicht vertrauenswürdige Werte über Umgebungsvariablen statt direkt in run:-Skripte übergeben;
• strukturierte Werkzeuge wie jq zum Erzeugen von JSON verwenden, anstatt Shell-Zeichenketten zusammenzusetzen;
• Daten an der Grenze zur Shell korrekt quoten und validieren;
• Zugangsdaten möglichst aus Workflow-Schritten heraushalten, die angreiferkontrollierte Inhalte verarbeiten;
• KI-generierte oder KI-geprüfte Sicherheitsänderungen genauso gründlich kontrollieren wie Code von Menschen.

Der Fall zeigt eine neue Dynamik in der Anwendungssicherheit: Ein KI-gestütztes Codetool kann eine gefährliche Änderung übersehen, während ein autonomer offensiver Agent dieselbe Lücke innerhalb weniger Tage findet und bestätigt. Automatisierung kann sowohl Abhilfe als auch Ausnutzung beschleunigen – eine unabhängige Sicherheitsprüfung ersetzt sie nicht.