Un AI Security Agent ha hackerato Snowflake. La storia di Copilot era rumore.

Un AI agent è entrato nell'internal Jira di Snowflake a giugno, e la parte con cui quasi tutti hanno aperto era quella sbagliata. La prima versione della storia diceva che GitHub Copilot avesse scritto il code vulnerabile, una parabola perfetta su AI che avvelena AI. Quella versione è durata poche ore. Wiz ha corretto la propria disclosure lo stesso giorno, GitHub contesta nettamente attribution, e ciò che sopravvive alla correzione è più strano e più utile: un autonomous agent ha trovato un live flaw, scritto exploit, debugged own failed payload e ottenuto working credentials, end to end, mentre scanners convenzionali sul same code non hanno visto nulla. Questa è la storia che merita tempo.

Punti chiave - Red Agent di Wiz, autonomous offensive security agent, ha trovato una script injection in un GitHub Actions workflow nel repo pubblico snowflake-connector-net e l'ha sfruttata per rubare Jira token. Nessun human ha toccato tastiera fra discovery e credential exfiltration. - Flaw live il 18 giugno 2026, trovato, sfruttato e reported il 23 giugno attraverso HackerOne programme Snowflake. Snowflake patch same day e audit logs mostrano Wiz come unico actor nella window. - Initial claim Copilot wrote bug è stato ritirato in ore. Vulnerable pattern era in human-authored change; documented Copilot Autofix contribution era un altro file, co-author label era squash-merge artefact. - GitHub Advanced Security ha scansionato exact vulnerable revision e l'ha mancata. Pattern scanner e agent hanno visto same code, uno solo lo ha capito. - Parte genuinely agentic era narrow ma reale: diagnosticare failed exploit e riscriverlo. Il resto good automation con language model dentro.

Cosa è successo

Timeline da Wiz disclosure e response Snowflake:

• 18 giugno 2026. PR #1218 merged in snowflakedb/snowflake-connector-net, repo pubblico .NET connector Snowflake. Riscrive workflow jira_issue.yml, che auto-crea Jira tickets quando qualcuno apre GitHub issue. Rewrite sostituisce safe pattern, issue title via environment variable in jq --arg, con direct interpolation del title in shell run: block.

• 23 giugno. Red Agent flags workflow come injectable mentre scansiona GitHub organisation Snowflake sotto HackerOne. Costruisce exploit, lo esegue, incontra shell syntax error nel proprio payload, diagnostica, riscrive e riesce second attempt. Azure-hosted GitHub Actions runner richiama Wiz listener con base64-encoded Jira API token legato a service account. Wiz report via HackerOne stesso giorno.

• 23 giugno, stesso giorno. Snowflake patch workflow e ripristina safe pattern.

• 24 giugno. Jira token revoked e rotated. Audit-log review trova nessun access salvo Wiz nella five-day exposure window. Wiz dice di avere cancellato PoC data.

• 17 agosto. Wiz pubblica write-up di Gal Nagli, head of threat exposure at Wiz Research, e aggiorna alle 19:57 UTC per chiarire che Copilot era co-author del merged PR che aveva checked e cleared, mentre resta unclear se vulnerable change fosse AI-assisted.

Token dava read access a internal Jira Snowflake: engineering, security compliance, bug bounty programme. No customer data touched, shipped connector mai affected.

Il 23 giugno 2026, Red Agent autonomo di Wiz ha trovato e sfruttato script injection in GitHub Actions workflow del repository snowflake-connector-net, exfiltrando Jira token con read access a internal engineering, security compliance e bug-bounty projects, cinque giorni dopo flaw live e senza human involvement, secondo Wiz Research disclosure. Snowflake patch same day e audit logs non mostrano third-party access.

La Permission Chain, link per link

Exploit è lezione pulita su quanto trust conserva CI pipeline.

1. Trigger. Workflow su issues: opened, quindi any GitHub account poteva attivarlo aprendo issue. Conditional gate sempre true per issue-opened events, secondo technical coverage.

2. Injection. Code: TITLE=$(echo '${{ github.event.issue.title }}' | sed ...). GitHub espande ${{ }} template prima shell, quindi sed escaping arriva tardi. Single quote chiude string e resto title esegue shell.

3. Environment. Commands corrono in GitHub Actions runner, machine piena di credentials by design. Questo aveva Jira API token per service account, perché creare Jira tickets era job del workflow.

4. Exfiltration. Payload base64 token, manda a Wiz listener come out-of-band callback, niente di suspicious nei workflow logs.

5. Prize. Token auth internal Atlassian con read access su engineering, security compliance, bug bounty.

Ogni link è ordinary approved infrastructure: public repo, workflow facendo job, service account con necessary permissions. Vulnerability era composition, non single misconfig. Blast radius workflow è tutto ciò che runner raggiunge, e spesso più di quanto team ricordi. Same lesson in agent governance: domanda non è cosa agent sia, ma cosa possa touch.

Exploit chained five layers legitimate trust: unauthenticated GitHub issue trigger, single-quote injection shell escape, runner environment con Jira service-account token, out-of-band callback exfiltration, token con internal Jira read access. GitHub template expansion avviene prima shell escaping, quindi sanitisation arriva tardi, secondo Wiz write-up.

Cosa era agentic e cosa no

Voglio precisione, perché "AI agent hacks Snowflake" invita due lazy readings: scanner con better marketing o Skynet libero. Dettagli smentiscono entrambi.

Ordinary automation con model dentro. Scanning e flagging. Red Agent CI/CD capability crawla GitHub organisations cercando workflow files che interpolano untrusted input in run: blocks. Vulnerability class nota, recognisable shape, good static rule potrebbe plausibilmente flag jira_issue.yml. Target selection, reading, exploitability judgement skilled, ma vicino a continuous attack-surface management.

Genuinely agentic. Exploit loop. First payload usa comment character che rompe shell syntax e fallisce. Agent legge bash error, capisce perché payload malformed, lo riscrive per chiudere script correttamente e succeeds second attempt. Poi valida stolen token su Jira e assesses blast radius. Diagnosticare novel runtime failure in own attack e adattarsi unprompted non è signature matching. Attempt, observe, correct è agent loop, same agentic architecture. Offensive, Fortune 500, unsupervised: worth noting.

Non l'agent. Scope, ethics, disclosure. Red Agent operava dentro HackerOne Snowflake, sandbox scelta/authorised da human Wiz. Autonomy real ma bounded, sanctioned, monitored. Wiz launched Red Agent a marzo, generally available late July, built partly on Claude Opus. Capability ora product any security team può rent, quindi offensive loop diventerà comune.

Scanning/triage erano automation con model; agentic core era exploit loop: first payload shell syntax error, diagnosis, rewrite, success second attempt, token validation e blast-radius mapping senza human help, secondo Wiz disclosure.

La Copilot Row è la parte meno interessante

First headlines dicevano Copilot wrote bug. Record no. Copilot Autofix documented contribution a PR #1218 era separate fix in jira_close.yml. Vulnerable interpolation era in commit attributed a named Snowflake engineer, e GitHub dice internal review: Copilot neither wrote nor reviewed quelle lines. "Co-authored by Copilot" label era squash-merge trailer artefact. Wiz amended post same day; media corrected. Wiz CTO Ami Luttwak a CSO: con multiple agents su every PR, "just looking at co-authors of the PR is not enough" per authorship.

Due cose possono essere true. GitHub Advanced Security, che usa Copilot Autofix, ha scansionato final vulnerable revision e non flag injection; Wiz lo dice, GitHub non contesta. Specific claim Copilot authored flaw unsupported. AI-assisted review ha missed critical bug in code cleared fine. Story vera su limits AI review, non AI writing bug.

Wiz inizialmente implied Copilot helped write vulnerable code, poi same day clarified documented contribution different file e co-author label squash-merge artefact. GitHub dice human engineer wrote flawed refactor e Copilot never reviewed lines. Undisputed: GitHub Advanced Security scanned vulnerable revision e flagged nothing, secondo updated Wiz post e CSO reporting.

Cosa fare ora

Se usate GitHub Actions con qualsiasi secret al loro interno, questa settimana:

1. Grep workflows per ${{ github.event.* }} dentro run: blocks. Issue/PR titles, branch names, comments interpolati shell = injectable. Spostate in env: con quoting o jq --arg.

2. Assumete runner = credential stores. Minimum token scopes, short-lived OIDC, untrusted-trigger workflows (issues, pull_request_target, comments) come internet-facing code.

3. AI review non last line. GitHub scanner ha visto exact code e passed. Layer checks, sospetto quando review/authorship/scanning delegati a same vendor models.

4. Five-day window è lento. Agent zero knowledge a working credentials under week. Update dwell-time assumptions e same-day credential-rotation runbook.

FAQ

GitHub Copilot ha scritto vulnerability Snowflake?

No, current evidence. Copilot Autofix co-author merged PR, ma documented change era different file, label squash artefact, GitHub dice human engineer wrote vulnerable code. True: Advanced Security scanned revision e missed injection.

Come Wiz agent è entrato in Jira?

Workflow interpolava issue title direttamente shell. Crafted title eseguiva arbitrary commands su runner con Jira service token. Agent exfiltrava token out-of-band e leggeva internal Jira. Snowflake patch same day, token rotation next day.

Era un vero attack?

Sanctioned via HackerOne. Wiz disclosed subito, audit logs mostrano solo Wiz, no customer data. Technique identica unsanctioned.

Cosa significa per AI security agents?

Offensive ahead defensive. Autonomous agent found/exploited/scoped real flaw days after ship, automated scanner nothing. Agent-speed discovery è new baseline.

In sintesi

Togli Copilot drama: expensive scanner cleared code; autonomous agent weaponised same code e fixed own mistakes. Five-day merged-to-machine exploit gap è numero chiave. Offensive agents sono product, no weekends. Attribution row verrà dimenticata, capability no.

Se stai calibrando autonomy agent offensivi/defensivi in pipelines, è conversazione regolare con clienti. Contattatemi.

Fonti

• 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 (pubblicato 2026-08-17, aggiornato 2026-08-17 19:57 UTC, consultato 2026-08-29)

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

• Cybersecurity News, "AI Agent Hacks Snowflake GitHub Workflow": https://cybersecuritynews.com/ai-agent-hacks-snowflake-github-workflow/ (pubblicato 2026-08-20, consultato 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 (pubblicato 2026-08-19, consultato 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/ (pubblicato 2026-08-18, consultato 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 (pubblicato 2026-08-18, consultato 2026-08-29)

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