Ein AI Security Agent hackte Snowflake. Die Copilot Story war Noise.

Ein AI Agent brach im Juni in Snowflakes internes Jira ein, und der Teil, mit dem fast alle anfingen, war der falsche. Die erste Version der Story sagte, GitHub Copilot habe den vulnerablen Code geschrieben, eine saubere Parabel über AI, die AI vergiftet. Diese Version hielt ein paar Stunden. Wiz korrigierte seine eigene Disclosure noch am selben Tag, GitHub bestreitet die Attribution klar, und was nach der Korrektur übrig bleibt, ist seltsamer und nützlicher: Ein autonomer Agent fand einen Live Flaw, schrieb einen Exploit, debugte seinen eigenen fehlgeschlagenen Payload und zog funktionierende Credentials, end to end, während die konventionellen Scanner auf demselben Code nichts sahen. Das ist die Story, die Ihre Zeit verdient.

Wichtigste Erkenntnisse - Wiz' Red Agent, ein autonomer Offensive Security Agent, fand eine Script Injection in einem GitHub Actions Workflow im öffentlichen Snowflake Repo snowflake-connector-net und exploitete sie, um einen Jira Token zu stehlen. Kein Human berührte die Tastatur zwischen Discovery und Credential Exfiltration. - Der Flaw ging am 18. Juni 2026 live und wurde am 23. Juni gefunden, exploitated und reported, alles über Snowflakes HackerOne Programme. Snowflake patchte am selben Tag, und seine Audit Logs zeigen, dass Wiz der einzige Actor im Window war. - Der initiale Claim, Copilot habe den Bug geschrieben, wurde innerhalb von Stunden zurückgenommen. Das vulnerable Pattern war in einer human-authored Change; Copilot Autofix' dokumentierter Beitrag war eine andere Datei, und das Co-author Label war ein Squash-merge Artefakt. - GitHub Advanced Security scannte exakt die vulnerable Revision und verpasste sie. Ein Pattern-matching Scanner sah denselben Code, über den ein Agent reasoned, und nur einer davon verstand ihn. - Der wirklich agentic Teil war narrow, aber real: einen fehlgeschlagenen Exploit diagnostizieren und umschreiben. Der Rest war gute Automation mit einem Language Model darin.

Was passiert ist

Die Timeline, vollständig aus Wiz' Disclosure und Snowflakes Response:

• 18. Juni 2026. PR #1218 wird in snowflakedb/snowflake-connector-net gemerged, Snowflakes öffentliches .NET Connector Repo. Es schreibt einen Workflow namens jira_issue.yml um, der automatisch Jira Tickets erstellt, wenn jemand ein GitHub Issue öffnet. Die Rewrite ersetzt ein sicheres Pattern, Issue Title via Environment Variable in jq --arg, durch direkte Interpolation des Titles in einen Shell run: Block.

• 23. Juni. Red Agent, Wiz' autonomer Security Research Agent, flaggt den Workflow als injectable, während es Snowflakes GitHub Organisation unter dem HackerOne Bug Bounty Programme scannt. Es baut einen Exploit, feuert ihn ab, trifft einen Shell Syntax Error im eigenen Payload, diagnostiziert den Error, schreibt den Payload neu und hat beim zweiten Attempt Erfolg. Ein Azure-hosted GitHub Actions Runner ruft Wiz' Listener mit einem base64-encoded Jira API Token zurück, gebunden an einen Service Account. Wiz reported ihn am selben Tag via HackerOne.

• 23. Juni, gleicher Tag. Snowflake patcht den Workflow und stellt das sichere Pattern wieder her.

• 24. Juni. Der Jira Token wird revoked und rotated. Snowflakes Audit-log Review findet keinen Access durch jemand anderen als Wiz während des fünftägigen Exposure Window. Wiz sagt, es habe die Daten aus seinem Proof of Concept gelöscht.

• 17. August. Wiz veröffentlicht den Write-up von Gal Nagli, Head of Threat Exposure bei Wiz Research, und aktualisiert ihn am selben Tag um 19:57 UTC, um klarzustellen, dass Copilot ein Co-author war, der den gemergten PR geprüft und freigegeben hatte, und dass unklar ist, ob die vulnerable Change überhaupt AI-assisted war.

Der Token hatte Read Access auf Snowflakes internes Jira: Engineering, Security Compliance und das Bug Bounty Programme selbst. Keine Customer Data wurde berührt, und der ausgelieferte Connector war nie betroffen.

Am 23. Juni 2026 fand und exploitete Wiz' autonomer Red Agent eine Script Injection in einem GitHub Actions Workflow im Snowflake Repository snowflake-connector-net und exfiltrierte einen Jira Token mit Read Access auf interne Engineering-, Security-compliance- und Bug-bounty-Projekte, fünf Tage nachdem der Flaw live gegangen war und ohne Human Involvement, laut Wiz Researchs Disclosure. Snowflake patchte am selben Tag und fand in seinen Audit Logs keinen Third-party Access.

Die Permission Chain, Link für Link

Der Exploit ist eine saubere Lektion darin, wie viel Trust eine CI Pipeline still hält. Folgen Sie, was ein einziges crafted Issue Title erreichen konnte:

1. Der Trigger. Der Workflow lief auf issues: opened, also konnte jeder GitHub Account auf der Welt ihn durch Öffnen eines Issues auslösen. Ein Conditional Check, der Access gaten sollte, evaluierte auf Issue-opened Events immer zu true, laut der Technical Coverage.

2. Die Injection. Der neue Code machte TITLE=$(echo '${{ github.event.issue.title }}' | sed ...). GitHub expandiert das ${{ }} Template bevor die Shell läuft, also kommt das sed Escaping zu spät. Ein einzelnes Quote im Title schließt den String und der Rest des Titles läuft als Shell.

3. Die Environment. Commands laufen jetzt in einem GitHub Actions Runner, einer Machine voller Credentials by design. Dieser hielt einen Jira API Token für einen Service Account, weil das Erstellen von Jira Tickets der ganze Job des Workflows war.

4. Die Exfiltration. Der Payload base64-encodete den Token und schickte ihn als Out-of-band Callback an Wiz' Listener, sodass nichts Verdächtiges je in den Workflow Logs erschien.

5. Der Preis. Der Token authentifizierte gegen Snowflakes interne Atlassian Environment mit Read Access über Engineering-, Security-compliance- und Bug-bounty-Projekte.

Jeder Link in dieser Chain ist ordinary, approved, boring Infrastructure: ein Public Repo, ein Workflow, der seinen Job macht, ein Service Account mit den Permissions, die er braucht. Die Vulnerability war keine einzelne Misconfiguration; sie war die Composition. Der Blast Radius eines Workflows ist alles, was sein Runner erreichen kann, und Runner können normalerweise mehr erreichen, als das Team, das sie geschrieben hat, erinnert. Es ist dasselbe Argument, das ich mache, wenn Clients nach Agent Governance fragen: Die Frage ist nie, was der Agent ist, sondern was der Agent berühren kann.

Der Exploit verkettete fünf Layers legitimen Trusts: Ein unauthenticated GitHub Issue triggerte den Workflow, eine Single-quote Injection brach aus der Shell aus, die Runner Environment hielt einen Jira Service-account Token, ein Out-of-band Callback exfiltrierte ihn, und der Token öffnete Read Access auf Snowflakes internes Jira. GitHubs Template Expansion läuft vor Shell Escaping, weshalb die Sanitisation zu spät kam, laut Wiz' Write-up.

Was agentic war und was nicht

Ich will hier präzise sein, weil "AI Agent hacks Snowflake" zu zwei faulen Lesarten einlädt: Das war nur ein Scanner mit besserem Marketing, oder Skynet ist los. Keine überlebt die Details.

Ordinary Automation mit einem Model darin. Scanning und Flagging. Red Agents CI/CD Capability crawlt GitHub Organisations auf Workflow Files, die untrusted Input in run: Blocks interpolieren. Das ist eine gut verstandene Vulnerability Class mit recognisable Shape, und jira_issue.yml zu flaggen ist die Art von Sache, die eine gute Static Rule plausibel tun könnte. Target wählen, Workflow lesen, Exploitability beurteilen: skilled, aber nahe an dem, was Wiz bereits als Continuous Attack-surface Management verkauft.

Genuinely agentic. Der Exploit Loop. Der erste Payload des Agents benutzte ein Comment Character, das die Shell Syntax brach und scheiterte. Er las den Bash Error, arbeitete heraus, warum der Payload malformed war, schrieb ihn um, sodass das Script richtig geschlossen wurde, und hatte beim zweiten Attempt Erfolg. Dann validierte er, dass der gestohlene Token wirklich gegen Snowflakes Jira funktionierte, und assessed, was der Token erreichen konnte. Einen novel Runtime Failure im eigenen Attack zu diagnostizieren und unprompted anzupassen ist kein Signature Matching. Dieser Loop, attempt, observe, correct, trennt Agent von Scanner, und es ist derselbe Loop, über den ich in Agentic Architecture allgemeiner geschrieben habe. Ihn offensiv gegen ein Fortune-500 Target unsupervised laufen zu sehen, ist ein First, den man notieren sollte.

Nicht der Agent. Scope, Ethics und Disclosure. Red Agent lief innerhalb von Snowflakes HackerOne Programme, einer Sandbox, die ein Human bei Wiz ausgewählt und authorised hatte. Die Autonomy war real, aber bounded, sanctioned und monitored, genau der Punkt für Defenders. Wiz launched Red Agent im März und machte ihn Ende Juli generally available, built partly on Anthropic's Claude Opus. Die Capability ist jetzt ein Product, das jedes Security Team mieten kann, also wird die offensive Version dieses Loops sehr gewöhnlich werden.

Red Agents Scanning und Triage waren Automation mit einem Model darin; der agentic Core war der Exploit Loop: Als sein erster Payload einen Shell Syntax Error warf, diagnostizierte der Agent den Bash Failure, schrieb den Payload um und war beim zweiten Attempt erfolgreich, validierte dann den Token und mappte seinen Blast Radius, alles ohne Human Help, laut Wiz' Disclosure.

Die Copilot Row ist der uninteressanteste Teil

Die ersten Headlines sagten, Copilot habe den Bug geschrieben. Der Record sagt etwas anderes. Copilot Autofix' dokumentierter Beitrag zu PR #1218 war ein separater Fix an einer anderen Datei, jira_close.yml. Die vulnerable Interpolation saß in einem Commit, der einem named Snowflake Engineer zugeschrieben war, und GitHub sagte Reportern, seine interne Review habe ergeben, dass Copilot Autofix diese Lines weder geschrieben noch reviewed habe. Das "co-authored by Copilot" Label auf dem gemergten PR war ein Artefakt eines Squash Merge, der den Trailer mitnahm. Wiz amendete seinen Post am selben Tag; The Register korrigierte seine Story. Wiz CTO Ami Luttwaks Comment gegenüber CSO ist die ehrliche Takeaway: Wenn mehrere Agents auf jedem PR laufen, reicht "just looking at co-authors of the PR" nicht aus, um festzustellen, wer was geschrieben hat.

Zwei Dinge können gleichzeitig true sein. GitHub Advanced Security, das Copilot Autofix nutzt, scannte die finale Revision dieses PR inklusive des vulnerable Workflows und flaggte die Injection nicht; das steht in Wiz' Account und GitHub hat es nicht bestritten. Und der spezifische Claim, Copilot habe den Flaw authored, ist unsupported. AI-assisted Review verpasste einen Critical Bug in Code, den es als fine cleared. Das ist eine echte Story über Limits von AI Review; es ist nur keine Story darüber, dass AI den Bug schrieb, und beides zu conflaten hilft niemandem, der entscheidet, wie viel Trust AI Review auf eigenen PRs verdient.

Wiz implizierte zunächst, Copilot habe geholfen, den vulnerablen Code zu schreiben, und stellte noch am selben Tag klar, dass Copilot Autofix' dokumentierter Beitrag eine andere Datei im selben PR betraf und das Co-author Label ein Squash-merge Artefakt war. GitHub sagt, ein Human Engineer habe den flawed Refactor geschrieben und Copilot habe ihn nie reviewed. Unbestritten: GitHub Advanced Security scannte die vulnerable Revision und flaggte nichts, laut Wiz' Updated Post und CSOs Reporting.

Was Sie jetzt tun sollten

Wenn Sie GitHub Actions mit Secrets betreiben, diese Woche:

1. Greppen Sie Ihre Workflows nach ${{ github.event.* }} innerhalb von run: Blocks. Jede Interpolation von Issue Titles, PR Titles, Branch Names oder Comment Bodies in Shell ist injectable, full stop. Schieben Sie den Value in eine env: Variable und übergeben Sie ihn mit richtigem Quoting oder parsen Sie ihn mit jq --arg. Das ist das Pattern, das Snowflake wiederhergestellt hat.

2. Nehmen Sie an, Ihre Runner sind Credential Stores. Scopen Sie Workflow Tokens auf Minimum, bevorzugen Sie short-lived OIDC Credentials gegenüber long-lived Service-account Tokens und behandeln Sie jeden Workflow, der durch untrusted Events (issues, pull_request_target, Comments) getriggert wird, als Internet-facing Code.

3. Lassen Sie AI Review nicht Ihre letzte Line sein. GitHubs eigener Scanner sah genau diesen Code und passierte ihn. Layern Sie Ihre Checks und seien Sie suspicious bei Workflows, wo Review, Authorship und Scanning alle an Models eines Vendors delegated sind.

4. Erwarten Sie, dass ein Fünf-tage Window langsam wirkt. Ein Agent ging von Zero Knowledge dieses Repos zu Working Credentials in weniger als einer Woche. Wenn Ihr Disclosure Process Months of Attacker Dwell Time annimmt, aktualisieren Sie die Assumption und halten Sie ein Credential-rotation Runbook bereit, das am selben Tag ausgeführt werden kann, wie Snowflake es tat.

FAQ

Hat GitHub Copilot die Snowflake Vulnerability geschrieben?

Nein, nicht nach der aktuellen Evidence. Copilot Autofix war Co-author auf dem gemergten PR, aber seine dokumentierte Change war in einer anderen Datei, das Label ein Squash-merge Artefakt, und GitHub sagt, ein Human Engineer habe den vulnerablen Code geschrieben. Was true ist: GitHub Advanced Security scannte die vulnerable Revision und verpasste die Injection.

Wie kam der Wiz Agent in Snowflakes Jira?

Er fand einen Workflow, der Issue Titles direkt in ein Shell Script interpolierte. Ein Issue mit crafted Title auszulösen, ließ arbitrary Commands auf dem Runner laufen, der einen Jira Service-account Token hielt. Der Agent exfiltrierte den Token über einen Out-of-band Callback und nutzte ihn, um interne Jira Projects zu lesen. Snowflake patchte den Workflow am Tag des Reports und rotierte den Token am Tag danach.

War das ein echter Attack?

Es war ein sanctioned Attack. Red Agent operierte unter Snowflakes HackerOne Bug Bounty Programme, Wiz disclosed sofort, und Snowflakes Audit Logs bestätigten, dass Wiz der einzige Actor in den fünf Tagen war, in denen der Flaw live war. Keine Customer Data wurde accessed. Aber die Technique funktioniert identisch für einen unsanctioned Agent, und genau das ist der Punkt.

Was bedeutet das für AI Security Agents?

Dass offensive Agents den defensiven voraus sind. Ein autonomer Agent fand, exploitete und scopte einen Real Flaw Tage nach dem Ship, während der Automated Scanner auf demselben Code nichts sah. Defenders sollten Agent-speed Discovery als neue Baseline annehmen und davon ausgehen, dass alles Internet-triggerable mit dieser Speed probed wird.

Fazit

Ziehen Sie das Copilot Drama ab, bleiben zwei Facts. Ein konventioneller, teurer Security Scanner reviewed diesen Code und cleared ihn. Ein autonomer Agent las denselben Code, verstand ihn gut genug, um ihn zu weaponise, und fixte seine eigenen Fehler entlang des Wegs. Der Fünf-tage Gap zwischen "merged" und "exploited by a machine" ist die Zahl, auf die Security Teams starren sollten, denn offensive Agents sind jetzt ein Product, kein Research Demo, und sie nehmen keine Weekends. Die Copilot Attribution Row wird nächsten Monat vergessen sein. Die Capability nicht.

Wenn Sie herausarbeiten, wie viel Autonomy Agents, offensiv oder defensiv, in Ihren eigenen Pipelines bekommen sollen, ist das ein Gespräch, das ich regelmäßig mit Clients führe. Kontakt aufnehmen.

Quellen

• Wiz Research (Gal Nagli), "Wiz Red Agent Finds Its Way Into Snowflake's Internal Jira Through a Flaw in a GitHub Copilot-Assisted PR": https://www.wiz.io/blog/red-agent-snowflake-copilot-cicd-bug (veröffentlicht 2026-08-17, aktualisiert 2026-08-17 19:57 UTC, abgerufen 2026-08-29)

• Wiz, "Introducing the Wiz Red Agent - AI-Powered Attacker": https://www.wiz.io/blog/introducing-the-wiz-red-agent (veröffentlicht 2026-03-23, abgerufen 2026-08-29)

• Cybersecurity News, "AI Agent Hacks Snowflake GitHub Workflow": https://cybersecuritynews.com/ai-agent-hacks-snowflake-github-workflow/ (veröffentlicht 2026-08-20, abgerufen 2026-08-29)

• CSO Online, "Snowflake flaw slips past AI checks, gets exploited by another AI": https://www.csoonline.com/article/4211501/snowflake-flaw-slips-past-ai-checks-gets-exploited-by-another-ai.html (veröffentlicht 2026-08-19, abgerufen 2026-08-29)

• Infosecurity Magazine, "Wiz AI Agent Finds Critical Snowflake GitHub Repo Flaw": https://www.infosecurity-magazine.com/news/wiz-ai-agent-finds-snowflake/ (veröffentlicht 2026-08-18, abgerufen 2026-08-29)

• daily.dev (from The Next Web), "GitHub disputes Wiz's claim that Copilot Autofix wrote a Snowflake flaw": https://daily.dev/posts/github-disputes-wiz-s-claim-that-copilot-autofix-wrote-a-snowflake-flaw-ybruxnh95 (veröffentlicht 2026-08-18, abgerufen 2026-08-29)

• snowflakedb/snowflake-connector-net repository: https://github.com/snowflakedb/snowflake-connector-net (abgerufen 2026-08-29)