Fünf Tage bis zum Exploit: KI-Agent knackt Snowflakes Jira

Der Squash-Commit, mit dem die Zeile am 18. Juni auf den Hauptzweig kam, führt «Copilot Autofix powered by AI» als Co-Autor. Wiz machte daraus zunächst die Pointe: Ein KI-Autofix habe die Injection-Lücke selbst geschaffen. GitHub widerspricht. Eine interne Prüfung habe ergeben, dass die Änderungen, die zur Lücke führten, von einem Menschen geschrieben und weder von Copilot beigesteuert noch von Copilot geprüft wurden — so berichtet es Forbes. Wiz präzisierte den Blogpost noch am selben Abend um 19:57 UTC: Copilot sei Co-Autor gewesen und habe den gemergten Pull Request als unbedenklich eingestuft, ohne die Lücke zu bemerken; ob die Code-Änderung selbst KI-unterstützt war, sei unklar. Auch The Register zog eine Korrektur nach.

Ein Blick in die öffentliche Commit-Historie stützt die Zurückhaltung: Der ausdrücklich von Copilot mitgezeichnete Commit betraf eine andere Datei (jira_close.yml), während der verwundbare Umbau von jira_issue.yml aus einem separaten Commit vom 25. August 2025 stammt, den GitHub einem Snowflake-Entwickler zuschreibt. Beides wanderte erst knapp zehn Monate später mit dem Squash-Merge in den Hauptzweig. Belegt ist damit: Copilot war am Pull Request beteiligt. Nicht belegt: dass Copilot die verwundbaren Zeilen geschrieben hat. Auch Wiz' Darstellung, der Pull Request habe ein bestehendes sicheres jq-Muster ersetzt, deckt sich nicht mit dem Diff: Ersetzt wurde eine fertige Jira-Action aus dem Marketplace, das jq-Muster kam erst mit dem Fix.

Der Agent debuggte seinen eigenen Exploit

Bemerkenswerter als die Schuldfrage ist, wie der Agent vorging. Sein erster Angriffsversuch scheiterte an einem Bash-Syntaxfehler — das Kommentarzeichen # verschluckte die schliessende Klammer. Statt abzubrechen, analysierte der Agent laut Wiz die Fehlermeldung selbst, baute den Payload um und erhielt im zweiten Anlauf den Rückkanal: base64-kodierte Zugangsdaten, gesendet vom GitHub-Runner. Das erbeutete Token gehörte zu qa@snowflake.net und öffnete Lesezugriff auf Snowflakes interne Jira-Projekte für Engineering, Security Compliance und Bug Bounty. Laut Wiz zeigen Snowflakes Audit-Logs im Fünf-Tage-Fenster keine Dritten — nur die Test-IPs von Wiz. Die Logs selbst sind nicht öffentlich.

Drei Handgriffe für deine eigenen Workflows

Falls du selbst Repositories mit GitHub Actions betreibst: Das ist kein exotischer Sonderfall. GitHub hat diese Angriffsklasse im Juli 2025 in einem eigenen Security-Blogpost beschrieben — inklusive der Empfehlung, untrusted Input über eine Zwischenvariable zu führen.

• Nie direkt interpolieren. Issue-Titel, Kommentare und Branch-Namen gehören nicht in einen run:-Block. Über eine env:-Variable einlesen und mit jq --arg weiterverarbeiten — genau das Muster, mit dem Snowflake die Lücke am 23. Juni geschlossen hat.
• if:-Bedingungen gegen den echten Event-Typ prüfen. Eine Abfrage auf ein Feld, das es beim ausgelösten Ereignis gar nicht gibt, ist kein Schutz, sondern eine offene Tür.
• Tokens kurzlebig halten. Ein Secret im Workflow ist genau so lange sicher wie der Workflow selbst.

Die eigentliche Nachricht steckt in der Zeitleiste. Fünf Tage lagen zwischen «Lücke ist live» und «autonomer Agent hat sie gefunden, ausgenutzt und den Schaden vermessen». Gal Nagli von Wiz sagte gegenüber Forbes, wer sich nicht selbst mit KI abklopfe, sei bereits im Rückstand. Dass ausgerechnet der Anbieter solcher Scanner das sagt, darf man mitdenken — die Zeitleiste bleibt trotzdem stehen.