KI-Sicherheitsagent findet Lücke in Snowflake-Workflow
Ein autonomer Sicherheitsagent von Wiz hat eine kritische Schwachstelle im öffentlichen Repository snowflakedb/snowflake-connector-net entdeckt. Über einen manipulierten GitHub-Issue-Titel konnten nicht authentifizierte Nutzer beliebige Befehle in einem GitHub-Actions-Runner ausführen.
Die Lücke steckte in der Workflow-Datei jira_issue.yml. Sie wurde am 18. Juni 2026 mit PR #1218 aktiv. Im zusammengefassten Commit war Copilot Autofix powered by AI als Co-Autor aufgeführt.
Ob die konkrete Änderung ursprünglich von Copilot oder einem Menschen geschrieben wurde, ist nicht bestätigt. Belegt ist jedoch, dass Copilot an dem Commit beteiligt war und die KI-gestützte Sicherheitsprüfung den geänderten Code ohne Beanstandung passieren ließ.
Sicheres Parsing wurde durch direkte Einbettung ersetzt
Vor der Änderung wurde der Titel eines GitHub-Issues über eine Umgebungsvariable an das Shell-Skript übergeben. Anschließend erzeugte jq daraus strukturiert die benötigten JSON-Daten. Dieses Muster verhinderte, dass Sonderzeichen im Titel als Shell-Befehle interpretiert wurden.
PR #1218 ersetzte dieses Verfahren durch die direkte Einbettung von ${{ github.event.issue.title }} in einen Shell-Befehl. Ein Angreifer konnte dadurch mit einem einfachen Anführungszeichen aus der vorgesehenen Zeichenkette ausbrechen und eigenen Code einschleusen.
Der Vorfall zeigt ein grundlegendes Problem KI-gestützter Codeänderungen: Ein funktionierendes Sicherheitsmuster kann entfernt werden, wenn dem System der historische Grund für dieses Muster fehlt.
Auch eine vermeintliche Schutzbedingung im Workflow half nicht. Sie prüfte bei einem Issue-Event ein Feld für Pull Requests. Dieses Feld ist in diesem Kontext immer null, weshalb die Bedingung für jeden GitHub-Nutzer erfüllt war.
Red Agent korrigiert seinen Exploit selbstständig
Der autonome Sicherheitsagent Red Agent entwickelte selbst einen Exploit für die Schwachstelle. Der erste Versuch scheiterte an einem Bash-Syntaxfehler. Anschließend analysierte der Agent den Fehler, passte den Payload an und führte den Angriff erfolgreich aus.
Dabei wurden Jira-Zugangsdaten für das Konto qa@snowflake.net aus dem GitHub-Actions-Runner ausgelesen. Der Token gewährte Lesezugriff auf Jira-Projekte für Entwicklung, Security Compliance und Bug-Bounty-Tracking.
Damit geht der Fall über eine theoretische Codeanalyse hinaus. Ein KI-Agent fand die Lücke innerhalb weniger Tage, entwickelte einen funktionsfähigen Angriff und reagierte eigenständig auf einen fehlgeschlagenen Versuch. Ähnliche Risiken zeigen sich, wenn KI-Agenten öffentliche Open-Source-Projekte auf GitHub bearbeiten.
Snowflake schließt die Lücke am Tag der Meldung
| Zeitpunkt | Ereignis |
|---|---|
| 18. Juni 2026 | PR #1218 wird zusammengeführt und aktiviert den anfälligen Workflow. |
| 23. Juni 2026 | Red Agent findet und validiert die Schwachstelle. Wiz meldet sie über HackerOne. |
| 23. Juni 2026 | Snowflake behebt die Lücke mit PR #1402 und stellt das sichere Muster mit Umgebungsvariable und jq wieder her. |
| Fünf Tage | Gesamtes Zeitfenster zwischen Einführung und Entdeckung der Schwachstelle. |
Snowflake widerrief und ersetzte den betroffenen Token. Nach Angaben des Unternehmens zeigten die Audit-Logs während des fünftägigen Zeitfensters keine unbefugten Zugriffe durch Dritte.
Snowflake erklärte sinngemäß, man schätze die verantwortungsvolle Meldung und Zusammenarbeit über das HackerOne-Programm. Der Schutz der eigenen Systeme habe höchste Priorität, und die Praktiken für Softwareentwicklung und Sicherheit würden kontinuierlich gestärkt.
KI-Prüfung ersetzt keine technische Kontrollschicht
Für Unternehmen im DACH-Raum ist vor allem die Kombination der Werkzeuge relevant. KI-Autofix, KI-gestützte Sicherheitsprüfung und klassische Codefreigabe bildeten in diesem Fall keine verlässliche Kontrollkette. Dieselbe Änderung konnte an mehreren Stellen automatisiert verarbeitet werden, ohne dass die Script Injection auffiel.
Das spricht nicht grundsätzlich gegen Coding-Agenten. Es spricht aber gegen die Annahme, dass eine zweite KI automatisch eine unabhängige Prüfung liefert. Wie begrenzt menschliche Freigaben bei hoher Automatisierung sein können, zeigt auch die Analyse zu Human-in-the-Loop-Verfahren bei Coding-Agenten.
Für GitHub Actions sollten direkte Einbettungen nicht vertrauenswürdiger Eingaben in run-Blöcke technisch blockiert werden. Sinnvoll sind feste Regeln in statischen Analysewerkzeugen, verpflichtende Tests für Workflow-Dateien und kurzlebige Zugangsdaten mit möglichst kleinen Berechtigungen.
Hinzu kommt das Risiko für die Software-Lieferkette. CI/CD-Systeme verfügen häufig über Zugangsdaten zu internen Diensten und können Artefakte veröffentlichen. Der Supply-Chain-Angriff auf LiteLLM-Pipelines verdeutlicht, wie weitreichend kompromittierte Geheimnisse in solchen Systemen sein können.
Automatisierte Angreifer verkürzen die Reaktionszeit
Die Schwachstelle war nur fünf Tage öffentlich aktiv, bevor sie automatisiert gefunden und ausgenutzt wurde. Für Sicherheitsverantwortliche bedeutet das, dass lange Patch-Zyklen bei öffentlich erreichbaren Workflows kaum noch vertretbar sind.
Gleichzeitig bleibt offen, ob GitHub Copilot Autofix für genau dieses unsichere Muster angepasst wurde. Unternehmen sollten daher nicht auf eine anbieterseitige Korrektur vertrauen. Eigene Richtlinien, unabhängige Scanner und begrenzte Berechtigungen reduzieren sowohl das technische Risiko als auch die Abhängigkeit von einzelnen KI-Anbietern.