„Critical vulnerabilities can still be introduced and approved within workflows involving AI coding agents and can still pass established automated security checks.“ – So steht es in einem aktuellen Wiz-Blogpost. Der Satz beschreibt einen Vorfall im Juni 2026. Ein autonomer KI-Agent hat innerhalb weniger Tage eine kritische Schwachstelle in einem öffentlichen GitHub-Repository von Snowflake gefunden und ausgenutzt. Der Code stammte von KI, die Schwachstelle passierte alle automatisierten Prüfungen.
Das ist keine Theorie. Es geht um echten Code, echte Credentials und einen Angriff auf die Infrastruktur eines führenden Cloud-Datenunternehmens. Hier die Schritte: Was ist passiert? Warum versagten die üblichen Sicherheitsmechanismen? Und was heißt das für deine Workflows?
Der Fund: Eine Script-Injection im GitHub-Actions-Workflow
Wiz Research war im Rahmen von Snowflakes HackerOne-Programm unterwegs. Ihr Werkzeug: Red Agent, ein autonomer, KI-gesteuerter Sicherheitsforschungsagent. Er scannte die GitHub-Organisation von Snowflake und wurde im Repository snowflakedb/snowflake-connector-net fündig. In einer Datei namens jira_issue.yml – ein GitHub-Actions-Workflow, der automatisch ein Jira-Ticket erstellt, wenn jemand ein GitHub-Issue eröffnet.
Der Workflow war anfällig für eine Script-Injection. Jeder, der ein GitHub-Issue mit einem manipulierten Titel eröffnete, konnte beliebige Befehle im Runner des Workflows ausführen. Ein unauthentifizierter Angriff. Ohne Zugang oder spezielle Rechte. Das ist bemerkenswert – aber die Hintergründe sind es mehr.
Die Schwachstelle entstand durch eine Kette von Umständen, nicht durch einen einzelnen Fehler. Ein Pull Request (PR #1218) mit dem Titel „SNOW-2069227: Update jira workflows“ brachte die Änderung in den Code. In diesem PR wurde ein sicheres Muster durch eine direkte Interpolation von unkontrolliertem Input ersetzt. Die Zeile nutzte ${{ github.event.issue.title }} direkt in einem Shell-Befehl. Die Absicherung per sed-Escaping kam zu spät – nachdem GitHub die Template-Expansion bereits durchgeführt hatte. Ein einfaches Anführungszeichen im Issue-Titel genügte, um aus der Echo-Zeile auszubrechen und Code einzuschleusen.
Warum die Sicherheitsprüfung versagte
Hier wird es interessant. Der PR wurde nicht blind gemerged. Er durchlief mehrere Sicherheitsstufen, die alle nichts bemerkten. Erste Stufe: GitHub Advanced Security. Dieser Scan analysierte die finale Revision des PRs – genau den Code, der später live ging. Trotzdem wurde die Injection nicht erkannt. Der Scan extrahierte sogar den verwundbaren Workflow – aber ohne Warnung.
Zweite Stufe: die Beteiligung von KI. Innerhalb desselben PRs hatte GitHub Copilot Autofix einen Fix für eine andere Datei (jira_close.yml) beigesteuert. Copilot wird in dem Blogpost als Co-Autor genannt, der den gemergten PR und die Code-Änderung überprüfte – und grünes Licht gab, ohne die kritischen Schwachstellen zu bemerken. Ob die eigentliche Code-Änderung KI-assistiert war, bleibt unklar. Entscheidend ist: Eine KI hat mitgeprüft, und niemand hat den Fehler gesehen.
Dazu kommt eine dritte Komponente, die wie eine offene Sicherheitstür wirkt: Der Workflow hatte eine if-Bedingung, die wie eine Zugriffsbeschränkung aussah. Doch sie prüfte auf github.event.pull_request – und bei Events vom Typ issues ist dieses Feld immer leer. Die Bedingung reduzierte sich also auf einen Vergleich, der immer wahr ist. Jeder Benutzer – ob angemeldet oder nicht – konnte den Workflow auslösen. Ein klassischer Fall von falsch verstandener Sicherheitslogik.
So funktionierte der Angriff
Wiz‘ Red Agent identifizierte die Schwachstelle und nutzte sie bis zur Eskalation aus. Der Agent erstellte ein GitHub-Issue mit einem manipulierten Titel, der nach der Template-Expansion den Shell-Befehl sprengte. Ziel: die Jira-Zugangsdaten aus der Umgebung zu exfiltrieren. Der erste Versuch schlug fehl, weil ein Kommentarzeichen (#) den Rest der Zeile auffraß und zu einem Syntaxfehler führte.
Der Red Agent stoppte nicht. Er analysierte den Fehler, baute den Payload um und schickte einen zweiten Versuch. Diesmal nutzte er ; echo ', um die Shell-Syntax korrekt zu schließen. Innerhalb weniger Sekunden lief der Callback auf einer Azure-IP (20.106.182.197) ein und offenbarte base64-kodierte Zugangsdaten. Der exfiltrierte Token gehörte zu qa@snowflake.net und erlaubte Lesezugriff auf verschiedene Jira-Projekte von Snowflake, darunter Engineering, Security Compliance und Bug Bounty Tracking.
Die Tricktechnik ist bekannt. Bemerkenswert ist, dass ein KI-Agent eigenständig einen Fehler behebt und seine Angriffsstrategie anpasst. Das kannten wir bisher nur aus Forschungslaboren. Jetzt sehen wir es in der Praxis – und es funktioniert schnell.
Die Reaktion von Snowflake: Schnell und sauber
Nachdem der Red Agent die Schwachstelle gefunden und validiert hatte, meldete Wiz sie am 23. Juni 2026 über HackerOne (Report #3819931). Snowflake reagierte professionell. Noch am selben Tag wurde der verwundbare Workflow gepatcht – die sichere env-Variable und das jq --arg-Muster wurden wiederhergestellt. Das Jira-Token wurde rotiert, und eine detaillierte Prüfung der Audit-Logs bestätigte, dass während des fünftägigen Exposure-Zeitraums niemand anderes als Wiz auf die Daten zugegriffen hatte.
Snowflake betont in ihrer offiziellen Antwort, dass man die Verantwortung ernst nehme und die Erkenntnisse mit der Branche teilen wolle. Der Vorfall wurde nicht unter den Teppich gekehrt, sondern als Gelegenheit genutzt, Sicherheitspraktiken zu verbessern. Das ist vorbildlich – auch wenn der Anlass unangenehm war.
Die Timeline zeigt, wie dünn die Zeitfenster geworden sind: Am 18. Juni wurde der verwundbare PR gemerged. Fünf Tage später – am 23. Juni – fand der autonome Agent die Lücke und nutzte sie aus. Innerhalb weniger Stunden. Tagelange manuelle Analyse? Fehlanzeige. Das ist das neue Tempo, auf das sich Unternehmen einstellen müssen.
Was wir daraus lernen müssen
Erste Lehre: der Umgang mit KI-generiertem Code. KI-Tools wie Copilot generieren Code auf Basis wahrscheinlicher Muster – und diese Muster können veraltet oder unsicher sein. Im konkreten Fall hat ein PR das bewährte, sichere Muster durch eine direkte Interpolation ersetzt – vermutlich ein „einfacher“ Fix, wie er in vielen Codebases vorkommt. Sicherheitsteams müssen KI-unterstützte Pull Requests genauso streng prüfen wie von Menschen geschriebene. Static Analysis und Security-Scans dürfen nicht nur auf die letzte Revision schauen, sondern müssen auch die semantische Sicherheit der Änderungen abdecken.
Zweite Lehre: die Erkennungszeiten. Red Agent hat die Schwachstelle in fünf Tagen gefunden und ausgenutzt – vollautomatisch. In einer Welt mit autonomen Angriffsagenten gibt es keine 90-Tage-Fristen mehr. Unternehmen brauchen schnelle Patch-Zyklen und kurzlebige Credentials. Ein Jira-Token, das wochenlang gültig ist, ist ein unnötiges Risiko. Privilege Access Management und regelmäßige Rotation sollten Standard sein.
Dritte Lehre, vielleicht die wichtigste: Sicherheitsmuster müssen explizit durchgesetzt werden. Im verantwortlichen PR wurde ein sicheres Pattern einfach entfernt – ohne dass die Sicherheitslösung angeschlagen hätte. Das passiert, wenn statische Analyse-Regeln auf Code-Snippets abzielen, nicht auf die Abwesenheit von bestimmten Mustern. Prüfe in deiner eigenen CI/CD-Pipeline nicht nur auf bekannte Schwachstellen, sondern auch auf unsichere Codierungsmuster wie direkte Interpolation von Kontextwerten in Shell-Befehle.
Fazit: Die neue Ära von Angriff und Verteidigung
Dieser Vorfall markiert einen Wendepunkt. Zum ersten Mal sehen wir in freier Wildbahn, wie ein autonomer KI-Agent einen kompletten Angriffszyklus durchläuft – von der Entdeckung über die Exploitation bis zur Exfiltration. Gleichzeitig zeigt er, wie verletzlich CI/CD-Pipelines sind, die auf menschliche Prüfer und herkömmliche Scanner vertrauen. Die Lücke war nicht exotisch – eine klassische Script-Injection, nur eben in einem GitHub-Actions-Workflow. Dass GitHub Advanced Security sie nicht erkannt hat, ist ein Weckruf für alle, die blind auf automatisierte Sicherheitschecks vertrauen.
Es gibt Gegenmittel. Kurzlebige Credentials, strikte Validierung von Inputs, Semgrep-Regeln gegen gefährliche Interpolationsmuster und eine Security-Kultur, die KI-Code genauso skeptisch betrachtet wie menschlichen Code. Und vielleicht der wichtigste Punkt: Die Verteidigung darf nicht hinter der Angriffstechnik zurückbleiben. Wiz‘ Red Agent zeigt, wie KI die offensive Sicherheit automatisiert. Dieselbe Technologie steckt auch in defensiven Tools – sie muss nur konsequent eingesetzt werden.
Für dich als Entwickler oder DevOps-Verantwortlicher heißt das: Schau nicht weg, wenn es um deine Workflows geht. Überprüfe, wo du github.event-Daten in Shell-Befehle einbindest. Setze Regeln, die solche Muster verbieten. Der Feind schläft nicht – und lernt auch noch dazu.
Quelle: wiz.io
