Snowflakes Jira-Token: Ein Fehler, den Copilot mitunterzeichnet hat – und der Mensch, der ihn laut GitHub geschrieben hat

Am 23. Juni 2026 eröffnete Red Agent, ein von Wiz entwickelter autonomer Sicherheitsagent, ein Issue in einem öffentlichen GitHub-Repository von Snowflake und kam mit einem Zugangsdatensatz zurück. Das Repository war snowflakedb/snowflake-connector-net, und der betroffene Workflow .github/workflows/jira_issue.yml dient dazu, jedes Mal ein Jira-Ticket anzulegen, wenn jemand ein Issue eröffnet – er baute den Ticket-Titel in einen Shell-Befehl ein, statt ihn über eine Umgebungsvariable zu übergeben, sodass ein manipulierter Titel als Code auf dem GitHub-Actions-Runner ausgeführt wurde. Das Token, das Red Agent erbeutete, authentifizierte sich als qa@snowflake.net gegenüber snowflakecomputing.atlassian.net und gewährte Lesezugriff auf Snowflakes Jira-Projekte für Engineering, Security-Compliance und Bug-Bounty. Die Schwachstelle war fünf Tage lang aktiv. Wiz veröffentlichte seine vollständige Analyse am 17. August 2026. Dieser Vorfall ist als Datensatz 2026-08-17-snowflake-jira-zhao-dao-can im Orca AI Incident Archive verzeichnet, das den vollständigen Datensatzbestand mit seinen Konfidenzgraden und zitierten Quellen enthält.

Die Interpolation und die Prüfung, die nie lief

Der Workflow wurde durch das GitHub-Ereignis „issues: opened“ ausgelöst. Jeder mit einem GitHub-Konto konnte ihn auslösen, indem er in einem öffentlichen Repository ein Issue eröffnete – keine Einladung, keine Maintainer-Rolle, kein Fork. Der anfällige Schritt las den Issue-Titel in eine Shell-Variable ein: TITLE=$(echo '${{ github.event.issue.title }}' | sed ...), mit zwei Filtern, die doppelte und einfache Anführungszeichen maskieren sollten, bevor die Zeichenkette zusammengesetzt wurde.

Der Fehler liegt in der Reihenfolge der Operationen, nicht im Escaping. GitHub setzt den Inhalt des Ausdrucks in den Skripttext ein, bevor bash ihn überhaupt parst, sodass ein einfaches Anführungszeichen im Issue-Titel die Zeichenkette in Anführungszeichen schließt, die echo offen hält. Die beiden sed-Filter laufen innerhalb desselben Skripts, nach der Ersetzung, und können die Quotierung nicht reparieren, die bereits verändert hat, wie die Zeile geparst wird. Wiz’ Analyse stellt ausdrücklich fest, dass das Escaping zu spät kommt, um den Ausbruch zu verhindern, und dass ein Titel, der mit einem schließenden Anführungszeichen und einem Semikolon konstruiert wurde, Befehle nach Wahl des Angreifers an den Ausführungsschritt anhängt.

Eine zweite Kontrolle sollte den Zielkreis einschränken, tat es aber nicht. Der Job enthielt eine if-Bedingung, die github.event.pull_request.user.login mit dem Login des whitesource-for-github-com-Bots verglich, offenbar um zu verhindern, dass automatisierte Dependency-Pull-Requests Tickets einreichen. Bei einem issues-Ereignis gibt es überhaupt kein Pull-Request-Objekt, daher erfolgt der Vergleich gegen eine null-Eigenschaft. GitHubs eigene Dokumentation, zitiert von The Hacker News, besagt, dass die Dereferenzierung einer nicht existierenden Eigenschaft einen leeren String ergibt; Wiz' Analyse kommt über den null-Wert zum selben Ergebnis. In beiden Fällen wurde die Bedingung für jeden Benutzer als wahr ausgewertet, und die Ausnahme für den Bot wurde zu einem Durchlass für das Internet.

Was die Injection berichtenswert statt routinemäßig machte, war ihr Umfeld. Derselbe Schritt enthielt JIRA_BASE_URL, JIRA_USER_EMAIL und JIRA_API_TOKEN als Umgebungsvariablen, sodass bei beliebiger Befehlsausführung auf dem Runner Zugangsdaten in Reichweite waren statt einer leeren Grundlage. Es wurde keine Version von Snowflake Connector for .NET als betroffen identifiziert: Die Schwachstelle lag in der CI/CD-Automatisierung des Repositorys, nicht im ausgelieferten Connector-Code.

Was Red Agent genommen hat und was es eigenen Angaben zufolge weggeworfen hat.

Wiz' Darstellung der Ausnutzung ist der Teil, der dies von einem Scanner-Fund unterscheidet. Der erste Payload verwendete ein Hash-Zeichen, das die schließende Klammer der Zuweisung TITLE=$(...) auskommentierte und statt eines Callbacks einen Bash-Syntaxfehler erzeugte. Der Agent las den Fehler und schrieb den Payload neu, um den Shell-Block mit einem Semikolon und einem neuen echo-Anführungszeichen zu schließen, und erhielt dann einen Out-of-Band-Aufruf. Der Payload nutzte curl, um eine Subdomain von oast.me mit base64-kodierten Werten der drei Credential-Variablen zu erreichen, und der Callback kam von der Azure-IP 20.106.182.197, einer Adresse, die Wiz einem GitHub Actions Runner zuordnet.

Das zurückgegebene Token war ein Jira-API-Token für qa@snowflake.net, und Wiz beschreibt seine Reichweite als Lesezugriff auf Engineering-, Security-Compliance- und Bug-Bounty-Tracking-Projekte auf Snowflakes Atlassian-Cloud-Instanz. Das ist der Schaden, den das Archiv dokumentiert: nicht Codeausführung auf einer Build-Maschine über fünf Tage, sondern ein Credential, das die Ticket-Warteschlangen lesen konnte, in denen nicht behobene Engineering- und Sicherheitsfehler eingetragen werden – darunter, nach Wiz’ Beschreibung, der Bug-Bounty-Tracker.

Wiz gibt an, alles, worauf es während des Proof of Concept zugegriffen hat, sicher gelöscht zu haben. Snowflake sagte in einer Stellungnahme gegenüber CSO Online, der Bericht sei „umgehend untersucht und behoben“ worden, und „unsere Untersuchung ergab keine Hinweise auf einen unbefugten Zugriff“; Wiz’ Blog ergänzt, Snowflake habe die Audit-Logs für den Fünf-Tage-Zeitraum geprüft und keine Nutzung durch Dritte außerhalb von Wiz’ eigenen Testadressen festgestellt. Snowflake hat diese Logs nicht veröffentlicht, sodass die Feststellung, dass keine anderen Akteure beteiligt waren, auf seiner Darstellung und auf Wiz’ Zusammenfassung davon beruht und nicht auf Dokumenten, die irgendjemand außerhalb der beiden Organisationen lesen kann.

Wer hat die anfällige Zeile geschrieben?

Diese Frage führte zur zweiten, größeren Geschichte. PR #1218 mit dem Titel „SNOW-2069227: Update jira workflows“ wurde am 18. Juni 2026 als Commit 4a1b8ce per Squash-Merge zusammengeführt, und der Squash-Commit führt Copilot Autofix powered by AI unter den Co-Autoren auf. Die ursprüngliche Schlagzeile von Wiz baute genau darauf auf und beschrieb die Schwachstelle als in einem von GitHub Copilot unterstützten Pull Request gelegen, und die frühe Branchenberichterstattung folgte derselben Linie – die Schlagzeile von SC Media lautete: „Wiz-Agent findet Schwachstelle im Snowflake-Repo in Code, an dem GitHub Copilot Autofix als Co-Autor beteiligt war“.

GitHubs Position – berichtet von The Next Web und zusammengefasst in einer Forschungsnotiz der Cloud Security Alliance – ist, dass seine interne Prüfung ergeben habe, „ein Mensch habe die Beiträge verfasst, die zu der Schwachstelle geführt haben“, und dass Copilot Autofix „sie weder geprüft noch zu ihnen beigetragen“ habe. Die technische Grundlage für diese Entgegnung liegt in der Git-Historie. Squash-Merging fasst einen Pull Request zu einem einzigen Commit zusammen und übernimmt jeden Co-Autor-Trailer unabhängig davon, welche Zeilen dieser Autor berührt hat; eine Co-Autor-Zeile verzeichnet also die Beteiligung am Pull Request, nicht die Urheberschaft an einem bestimmten Hunk. Der von Copilot mitverfasste Commit im selben Pull Request, 6d0e2fa, änderte jira_close.yml – einen anderen Workflow als den verwundbaren jira_issue.yml. Die unsichere Interpolation wird dem Commit 094038e vom 25. August 2025 zugeschrieben, den GitHub einem Snowflake-Engineer namens sfc-ghpathak zuordnet; PR #1218 brachte dieses Muster im Juni 2026 auf den Default-Branch.

Wiz zog den Befund nicht zurück und änderte die Darstellung am Tag der Veröffentlichung. In seinem Blog findet sich ein am 17. August um 19:57 UTC veröffentlichtes Update. Darin wird Copilot als „{{1}}einen Co-Autor, der den zusammengeführten PR und die Codeänderung geprüft hat{{/1}}“ beschrieben; dieser habe „ihn als unbedenklich eingestuft“, ohne die Schwachstellen zu bemerken, und es wird eingeräumt, dass „{{2}}unklar ist, ob die Codeänderung KI-unterstützt war.{{/2}}“ In dieser Darstellung liegt das Versagen der KI bei der Prüfung, nicht bei der Autorschaft: Der zusammengeführte Pull Request trug eine Copilot-Mitunterzeichnung, und die Injection überstand dies. CSO Online zitiert Wiz-CTO Ami Luttwak mit den Worten, eine klare Zuordnung zwischen Menschen und KI „lasse sich etwas schwerer herstellen“, und dass „es nicht ausreicht, nur die Co-Autoren des PR zu betrachten.“

Was die beiden Darstellungen gemeinsam haben, sollte von dem getrennt werden, was sie bestreiten. Beide stimmen darin überein, dass der Squash-Commit den Co-Autor-Trailer von Copilot Autofix trägt und dass der Workflow ausnutzbar war. Keine von beiden stellt infrage, dass GitHub Advanced Security die endgültige Revision des Pull Requests gescannt, jira_issue.yml extrahiert und die Injection nicht markiert hat – Wiz führt dies als verpassten Fund an, und GitHubs Erwiderung dreht sich um die Autorenschaft, nicht um den Scan. Ungelöst bleibt, ob Copilot die verwundbaren Zeilen überhaupt geprüft hat: Wiz sagt, es sei eine Prüfung gelaufen, die sie unbeanstandet passiert habe; GitHub sagt, das Tool sei an ihnen nicht beteiligt gewesen; und die Protokolle, die das klären würden, liegen bei einem der beiden Unternehmen. Der Bericht gibt beide Darstellungen wieder, statt sich für eine zu entscheiden.

Fünf Tage, und was sich danach änderte

Die Reparatur ging schnell voran, sobald der Bericht eingegangen war. Wiz reichte die Meldung am 23. Juni über Snowflakes HackerOne-Programm als Bericht #3819931 ein und benachrichtigte Snowflakes Sicherheitsteam noch am selben Tag per Slack; Snowflake führte PR #1402, Commit 1dc7766, zusammen, wodurch die direkte Ausdruckserweiterung durch Umgebungsvariablen ersetzt wurde, die jq als Argumente übergeben werden. Wiz' Zeitplan legt die Rotation des Jira-Tokens auf den 24. Juni, und The Hacker News berichtet dieselbe Aufteilung. Wiz' eigene Einleitung wiederum besagt, Snowflake habe die Schwachstelle behoben und die Zugangsdaten „noch am selben Tag“ rotiert – eine Abweichung innerhalb der Primärquelle, die der Bericht nicht überdecken sollte. Der Fix wurde am 23. Juni eingespielt; die Rotation ist in Wiz' Tabelle auf den 24. Juni datiert.

Die Offenlegung richtete sich nach Snowflakes Zeitplan: Wiz datiert eine Frist für die öffentliche Offenlegung auf den 25. Juli 2026, dreißig Tage nach einem Beschluss vom 25. Juni gemäß der Richtlinie des Programms, und veröffentlichte die Analyse am 17. August. In seiner Erklärung gegenüber CSO Online sagte Snowflake, das Unternehmen {{1}}begrüße Wiz' verantwortungsvolle Meldung{{/1}} und arbeite mit Wiz zusammen, um die Lehren mit der Branche zu teilen. Weder Wiz' Analyse noch der Bericht von The Hacker News enthält eine CVE-Kennung, einen CVSS-Score oder einen Eintrag in CISA-Katalog bekannter ausgenutzter Schwachstellen; die Schwachstelle war eine Workflow-Konfiguration in einem öffentlichen Repository, keine mitgelieferte Bibliothek, sodass sie nie auf üblichem Wege in eine Schwachstellendatenbank gelangte.

Was die Aktenlage belegt – und was nicht

Das Archiv stuft dies als Forschungsergebnis statt als Deployment-Ereignis ein, mit hohem Schweregrad, Konfidenzstufe A, bestätigter KI-Beteiligung und dokumentiertem realen Schaden; sein Datum, der 17. August 2026, ist der Tag, an dem Wiz veröffentlichte, und der Vorfall selbst erstreckt sich vom 18. bis 23. Juni. Der gesicherte Kern ist schmal und überprüfbar: Ein öffentlicher Workflow interpolierte von Angreifern kontrollierten Text in einen Shell-Befehl, seine Schutzbedingung wurde mit einer Eigenschaft verglichen, die bei diesem Ereignis null ist, ein Jira-Token befand sich im selben Schritt, ein autonomer Agent nutzte dies aus, und Snowflake hat innerhalb eines Tages einen Fix gemergt und die Zugangsdaten rotiert.

Die Teile, die eher Schlussfolgerung als dokumentierter Beleg sind, werden bei oberflächlichen Nacherzählungen oft eingeebnet. Copilot Autofix ist als Co-Autor des Pull Requests dokumentiert und nicht als Autor der verwundbaren Zeilen; die KI-gegen-KI-Darstellung, die den ersten Nachrichtenzyklus prägte, wurde von der berichtenden Organisation innerhalb von Stunden teilweise zurückgenommen und von GitHub widerlegt. Ob die KI-Überprüfung des zusammengeführten Pull Requests jira_issue.yml betrachtet hat, ist weiterhin eine offene Tatsachenfrage, keine geklärte. Und der Umfang des Zugriffs ist zwar von Wiz ausführlich beschrieben, aber nicht unabhängig geprüft worden: Weder Jira-Berechtigungen noch Workflow-Läufe noch Audit-Datensätze wurden öffentlich gemacht.

Das Fix-Muster entspricht dem, das GitHubs eigene Anleitung seit Juli 2025 empfohlen hatte – nicht vertrauenswürdige Issue-Daten in eine Umgebungsvariable übergeben und sie jq als Argument übergeben, statt sie in einem run-Block zu expandieren. Der gemergte Commit von Snowflake macht genau das, und die korrigierte Handhabung bleibt im Standardbranch erhalten. Für alle, die den Vorgang als Präzedenzfall lesen, betrifft die dauerhafte Erkenntnis eher die Attribution als die Injection: Wenn ein Pull Request mehrere Menschen und mehrere Agenten umfasst, kann der Co-Author-Trailer nicht sagen, wer eine Zeile geschrieben hat, und sowohl Wiz als auch GitHub sagten dies am Ende mit unterschiedlichen Worten.