Copilot Autofix öffnete eine Shell-Injektion in Snowflakes CI/CD-Pipeline

Ein Sicherheitsfix, geschrieben von GitHub’s Copilot Autofix und am 18. Juni 2026 in ein Snowflake-Repository gemerged, entfernte ein bereinigtes Eingabemuster und ließ die CI/CD-Pipeline des Unternehmens für Befehlsinjektionen offen, und fünf Tage später fand ein autonomer KI‑Forschungsagent die Lücke, nutzte sie aus und extrahierte funktionierende Jira‑Anmeldedaten aus einem GitHub‑Actions‑Runner, Wiz Research gab am 17. August 2026 bekannt.

Die Schwachstelle befand sich in jira_issue.yml, einem GitHub‑Actions‑Workflow im snowflakedb/snowflake-connector-net, dem öffentlichen Repository für Snowflakes .NET‑Datenconnector. Der Workflow wurde ausgelöst, sobald jemand ein GitHub‑Issue öffnete, und interpolierte den Titel des Issues (vollständig vom Ersteller kontrollierter Text) direkt in ein Shell‑Skript. Da der Auslöser issues: opened war, konnte jedes GitHub‑Konto im Internet ihn ohne Authentifizierung erreichen.

Wiz’s „Red Agent“, ein autonomes Sicherheitstool, das über Snowflakes HackerOne‑Bug‑Bounty‑Programm operiert, markierte den Workflow, entwickelte einen funktionierenden Exploit und exfiltrierte ein Jira‑API‑Token aus der Umgebung des Runners. Snowflake patchte den Workflow noch am selben Tag, an dem der Bericht einging, dem 23. Juni 2026, drehte das Anmeldezeichen einen Tag später und teilte Wiz mit, dass die Audit‑Logs keinen anderen Akteur zeigten, der während des fünf‑tägigen Fensters auf die exponierten Systeme zugegriffen habe.

Der “Autofix” entfernte den Sanitizer

Der Commit, der das injizierbare Muster einführte, kam über PR #1218, “SNOW-2069227: Update jira workflows” zustande, gemerged am 18. Juni 2026. Die Historie des Pull‑Requests zeigt einen menschlichen Autor, der seit August 2025 an der Jira‑Automatisierung arbeitet – und mittendrin einen von Copilot Autofix powered by AI mitverfassten Commit, den GitHub‑Advanced‑Security‑Bot, der vorgeschlagene Fixes für Code‑Scanning‑Alarme generiert.

Der KI‑Vorschlag änderte, wie der Workflow den Issue‑Titel behandelte. Der bestehende Code leitete den Titel über eine env:-Variable weiter und baute seine JSON‑Payload mit jq --arg auf, ein Muster, das unzuverlässigen Text aus der Shell fernhält. Der vorgeschlagene Ersatz verzichtete darauf zugunsten einer direkten Zeichenketten‑Erweiterung:

“ run: | TITLE=$(echo '${{ github.event.issue.title }}' | sed 's/"/\"/g' | sed "s/'/\'/g") “

Das sed-Escaping wird ausgeführt, nachdem die GitHub‑Template‑Engine den Titel bereits in das Skript eingesetzt hat. Ein einzelnes Anführungszeichen im Titel bricht aus dem echo '...'-Wrapper aus, und alles danach wird als Shell‑Befehl ausgeführt. Die eigene Dokumentation von GitHub für Copilot Autofix beschreibt die Funktion als Erzeugung „eines einzelnen vorgeschlagenen Fixes für einen Alarm, den Sie selbst prüfen und anwenden“ – der Prüfschritt ist hier das Schlupfloch.

Der Workflow enthielt zudem eine Guard‑Bedingung, die scheinbar einschränkte, wer ihn auslösen könne:

“ if: (github.event_name == 'issues' && github.event.pull_request.user.login != 'whitesource-for-github-com[bot]') “

Bei Issue‑Events ist github.event.pull_request immer null, sodass der Vergleich stets true ergibt. Jeder GitHub‑Nutzer kam somit durch das Gate.

Ein Agent auf jeder Seite des Exploits

Der erste Exfiltrationsversuch des Red Agent scheiterte. Seine Payload nutzte das #-Kommentarzeichen, um den Rest der injizierten Zeile zu verschlucken, wobei der Kommentar zudem die schließende Klammer von TITLE=$(...) konsumierte, sodass der Runner einen Bash‑Syntaxfehler zurückgab, anstatt den Befehl auszuführen. Laut Wiz‑Bericht analysierte der Agent den Fehler, schrieb seine Payload um, um den Shell‑Block mit ; echo ' zu schließen, und versuchte es erneut.

Die funktionierende Payload, übermittelt als Issue‑Titel, kodierte die Umgebungsvariablen JIRA_API_TOKEN, JIRA_USER_EMAIL und JIRA_BASE_URL des Runners in Base64 und sendete sie über curl an einen Out‑of‑Band‑Listener. Der Rückruf kam innerhalb von Sekunden von einem Azure‑gehosteten GitHub‑Actions‑Runner.

Das wiedergewonnene Token authentifizierte sich als qa@snowflake.net bei snowflakecomputing.atlassian.net und hatte Lesezugriff auf Snowflakes Engineering‑, Sicherheits‑Compliance‑ und Bug‑Bounty‑Tracking‑Projekte.

Snowflakes Behebung, gemerged in PR #1402 am 23. Juni 2026, stellte die sichere env:-Variable und das jq --arg-Parsing‑Muster wieder her. Das Jira‑Token wurde am 24. Juni 2026 widerrufen und rotiert. Wiz erklärte, dass es alle während des Proof‑of‑Concept‑Tests abgerufenen Daten sicher gelöscht habe.

“Snowflake schätzt die verantwortungsvolle Meldung und Zusammenarbeit von Wiz zu diesen Erkenntnissen im Rahmen unseres Vulnerability‑Disclosure‑ und Bug‑Bounty‑Programms HackerOne”, sagte das Unternehmen in einer mit dem Wiz‑Report veröffentlichten Erklärung. “Die Meldung ging am 23. Juni 2026 ein, wurde sofort untersucht und behoben, und unsere Untersuchung ergab keine Anzeichen unbefugten Zugriffs.”

Was das fünf‑tägige Fenster zeigt

Die Offenlegung fällt in die Mitte eines dokumentierten Musters: KI‑unterstützte Änderungen, die schneller durch die Review gelangen als die Sicherheitsannahmen es zulassen. Snowflakes eigene Audit‑Logs machen diesen Vorfall nachvollziehbar: sie ermöglichen dem Unternehmen zu erklären – und Wiz zu bestätigen – dass das Expositionsfenster keinen Zugriff durch Dritte erzeugte. Die Analyse der Audit‑Logs von Snowflake bestätigte, dass während des fünf‑tägigen Fensters keine externen Dritten auf den Endpunkt zugegriffen haben.

Der Zeitstrahl verdichtet zudem eine Abfolge, die die Branche bislang als hypothetisch betrachtete. Ein Coding‑Assistent entfernte ein Verteidigungsmuster, das speziell zum Schutz vor Shell‑Injection implementiert worden war, weil dem Assistenten kein Hinweis darauf vorlag, warum dieses Muster existierte. Ein offensiver Agent fand das Ergebnis daraufhin innerhalb von Tagen, nutzte es aus und korrigierte seinen Exploit selbst anhand der Live‑Fehlermeldungen. Die Angriffsseite operierte ohne Menschen am Keyboard; auf der Coding‑Seite erzeugte die KI die Änderung, ein Mensch setzte den Vorschlag um und mergte ihn – genau der Review‑Schritt, der versagte.

Wiz’ Bericht empfiehlt, dass KI‑generierte Pull‑Requests dieselbe statische Analyse durchlaufen wie menschlicher Code, dass Teams die Lebensdauer von Anmeldeinformationen verkürzen, um mit automatisierten Entdeckungs‑Geschwindigkeiten Schritt zu halten, und dass Guardrails Agenten daran hindern, strukturierte Parser durch direkte Zeichenketten‑Interpolation zu ersetzen. Check Point verlegte die Prompt‑Inspektion für KI‑Verkehr in Unternehmens‑Firewalls bereits im Sommer, und Unite.AI hat Agent‑Sandbox‑Escapes behandelt sowie agentische Systeme, die reale Produktionsziele erreichen, während die offensive Seite reift. Der Snowflake‑Vorfall ist dieselbe Geschichte, die aus einer CI‑Pipeline erzählt wird: die Schwachstelle war fünf Tage aktiv, und der einzige Grund, warum er als Fallstudie und nicht als Sicherheitsvorfall erscheint, ist, welcher Agent zuerst dort war.