Wo Wiz' Agent tatsächlich eingedrungen ist

Wiz hat einen autonomen KI-Agenten namens Red Agent gebaut, der nach ausnutzbaren Fehlern sucht, wie es ein menschlicher Penetrationstester tun würde, und dann selbst handelt. Auf Snowflakes öffentliche GitHub-Repositories angesetzt, fand er eine Skript-Injection-Lücke in einer GitHub-Actions-Workflow-Datei namens jira_issue.yml im Repository snowflakedb/snowflake-connector-net, Snowflakes quelloffenem .NET-Connector. Der Fehler erlaubte es jedem, ein GitHub-Issue mit einem präparierten Titel zu eröffnen und dadurch Snowflakes eigene Automatisierung einen Teil dieses Titels als Shell-Befehl ausführen zu lassen, ganz ohne Anmeldung.

Der erste Versuch von Red Agent scheiterte. Der Runner meldete einen Syntaxfehler, statt die Payload auszuführen. Statt aufzugeben, las der Agent die Fehlermeldung, schrieb den präparierten Issue-Titel selbstständig um und versuchte es erneut. Der zweite Versuch durchbrach die Shell-Zeichenkette und erreichte eine vom Angreifer kontrollierte Domain, wobei ein base64-kodiertes Jira-API-Token exfiltriert wurde. Entdeckung, Anpassung, Ausnutzung und Verifizierung des erlangten Zugriffs geschahen alle in einer einzigen Sitzung, ohne dass ein Mensch den nächsten Schritt vorgab.

Das gestohlene Token war gültig und als Snowflake-Service-Account authentifiziert, was Lesezugriff auf eine interne Jira-Instanz mit Projekten zu Engineering, Sicherheits-Compliance und Bug-Bounty-Tracking gewährte. Der verwundbare Code war seit dem Merge des PR #1218 am 18. Juni 2026 aktiv, der ein sicheres Parsing-Muster durch direkte Variableninterpolation in einem Shell-Befehl ersetzt hatte. Snowflake patchte ihn am 23. Juni 2026, stellte das sichere Muster wieder her und widerrief sowie erneuerte das exponierte Token; eine Prüfung der Protokolle ergab, dass während des fünftägigen Expositionsfensters keine externe Partei darauf zugegriffen hatte.

Wiz nannte Copilot als Mitautor des Fehlers

Wiz' ursprünglicher Bericht verwies auf den Commit, der die Lücke einführte, und stellte fest, dass GitHub Copilot Autofix darin als Mitautor erschien. Die Erzählung schrieb sich von selbst: Ein KI-Coding-Assistent hatte offenbar genau den Fehler mitverfasst, den ein KI-Sicherheitsagent anschließend autonom fand und ausnutzte - auf beiden Seiten ohne Mensch.

Die Mitautoren-Zeile war real, und Squash-Merges lassen solche Belege solider aussehen, als sie sind. Ein Pull Request kann viele einzelne Commits von vielen Beitragenden enthalten, aber ein Squash-Merge fasst sie alle zu einem einzigen Commit auf dem Hauptzweig zusammen, und jede Mitautoren-Zeile aus jedem dieser Commits wandert in das zusammengefasste Ergebnis mit. Ein Name in dieser Zeile dokumentiert Beteiligung irgendwo im Pull Request, nicht Autorschaft einer bestimmten Zeile. Als Wiz seinen Beitrag am 17. August 2026 aktualisierte, hatte sich die eigene Formulierung bereits dahin abgeschwächt, dass unklar sei, ob Copilot überhaupt an den verwundbaren Zeilen mitgewirkt habe.

GitHubs Commit-Historie sagt: ein Mensch hat es geschrieben

GitHub führte eine eigene interne Prüfung desselben Repositories durch und kam zu einem anderen Schluss. Demnach habe ein menschlicher Snowflake-Ingenieur die unsichere Umgestaltung verfasst, in einem separaten Commit vom 25. August 2025, rund zehn Monate bevor der verwundbare Pull Request gemergt wurde, und Copilot Autofix habe diese konkreten Zeilen weder geprüft noch dazu beigetragen.

Copilots tatsächlicher Mitautoren-Commit innerhalb des Pull Request #1218 änderte eine andere Datei, jira_close.yml, die mit den verwundbaren jira_issue.yml-Zeilen, die Red Agent ausnutzte, nichts zu tun hatte. Als der Pull Request zu einem einzigen Merge-Commit zusammengefasst wurde, wanderte Copilots Mitautoren-Zeile trotzdem mit, angeheftet an eine Änderung, die es nie berührt hatte.

Der Streit steht nun öffentlich mit zwei unvereinbaren Darstellungen und ohne unabhängigen Schiedsrichter da. Wiz verweist auf eine Mitautoren-Zeile in der lebendigen Commit-Historie; GitHub verweist auf eine interne Prüfung desselben Repositories, die die Autorschaft anders liest. Niemand außerhalb der beiden Unternehmen hat den Zugriff, der nötig wäre, um zu klären, welche Lesart zutrifft.

Die Governance-Lücke, die jedes KI-gestützte Team bemerken sollte

Einen KI-Coding-Assistenten und einen KI-Sicherheitsscanner in derselben Pipeline zu betreiben, wird zunehmend zum Standard, nicht zur Ausnahme. Wenn unter diesem Setup etwas schiefgeht, können sowohl die Partei, die den Fehler findet, als auch das Tool, dem seine Verursachung vorgeworfen wird, KI-Systeme sein, und der einzige Beleg, auf den sich beide Seiten berufen können, ist die Commit-Historie eines Repositories. Diese Historie ist nur so vertrauenswürdig wie die Praktiken, die sie hervorgebracht haben, und ein routinemäßiger Squash-Merge hat gerade bewiesen, dass er den Namen eines Beitragenden an den Fehler eines anderen anheften kann, ohne dass es jemand beabsichtigt hat.

Der Fehler selbst blieb fünf Tage offen und brauchte fünf weitere Tage bis zum Patch. Der Streit darüber, wer ihn geschrieben hat, dauerte länger als die Lücke selbst - und das zwischen zwei Anbietern mit den Ressourcen und dem Repository-Zugriff, um es ordentlich zu untersuchen. Ein Unternehmen mit weniger Disziplin bei der Bewahrung der Commit-Historie seiner eigenen Workflow-Dateien, und ohne feste Antwort darauf, wer intern eine Zuschreibungs-Behauptung veröffentlichen darf, bevor sie zu einem öffentlichen Streit wird, wird seine Version nicht so sauber auflösen.

Weiterlesen: Eine Beteiligung wog schwerer als alle drei Fonds  |  Ein gesperrtes Frontier-Modell ist wieder online