Un AI Security Agent a hacké Snowflake. L'histoire Copilot était du bruit.

Un AI agent est entré dans le Jira interne de Snowflake en juin, et la partie sur laquelle presque tout le monde a insisté était la mauvaise. Première version : GitHub Copilot aurait écrit le code vulnérable, parabole parfaite d'AI poisoning AI. Elle a tenu quelques heures. Wiz a corrigé sa disclosure le même jour, GitHub conteste clairement attribution, et ce qui reste après correction est plus étrange et utile : autonomous agent a trouvé un flaw live, écrit exploit, debugged son own failed payload et extrait working credentials, end to end, pendant que scanners conventionnels sur same code ne voyaient rien. Voilà l'histoire importante.

Points clés - Red Agent de Wiz, autonomous offensive security agent, a trouvé script injection dans GitHub Actions workflow du repo public snowflake-connector-net et l'a exploitée pour voler Jira token. Aucun human au clavier entre discovery et credential exfiltration. - Flaw live le 18 juin 2026, trouvé, exploité, reporté le 23 juin via HackerOne programme Snowflake. Snowflake patch same day, audit logs montrent Wiz unique actor. - Initial claim Copilot wrote bug retiré en heures. Vulnerable pattern human-authored; documented Copilot Autofix contribution autre file, co-author label squash-merge artefact. - GitHub Advanced Security a scanné exact vulnerable revision et raté. Pattern scanner et agent ont vu même code, un seul l'a compris. - Partie réellement agentic, narrow mais réelle : diagnostiquer failed exploit et le réécrire. Reste good automation avec language model.

Ce qui s'est passé

Timeline depuis Wiz disclosure et réponse Snowflake :

• 18 juin 2026. PR #1218 merged dans snowflakedb/snowflake-connector-net, repo public du connector .NET. Workflow jira_issue.yml réécrit pour auto-créer Jira tickets à l'ouverture GitHub issue. Safe pattern, title via env vers jq --arg, remplacé par direct interpolation du title dans shell run: block.

• 23 juin. Red Agent flags workflow injectable sous HackerOne. Il construit exploit, l'envoie, rencontre shell syntax error dans own payload, diagnostique, réécrit et réussit second attempt. Azure-hosted GitHub Actions runner callback vers Wiz listener avec base64 Jira API token de service account. Wiz reports same day.

• 23 juin. Snowflake patch, restaure safe pattern.

• 24 juin. Token revoked/rotated. Audit logs : seulement Wiz sur five-day exposure window. Wiz dit avoir supprimé PoC data.

• 17 août. Wiz publie write-up Gal Nagli et update 19:57 UTC pour clarifier Copilot co-author du merged PR, mais unclear si vulnerable change AI-assisted.

Token donnait read access à internal Jira : engineering, security compliance, bug bounty. No customer data, shipped connector unaffected.

Le 23 juin 2026, Red Agent autonome de Wiz a trouvé/exploité script injection dans GitHub Actions workflow de snowflake-connector-net, exfiltrant Jira token avec read access à internal engineering/security/bounty projects, cinq jours après flaw live et sans human involvement, selon Wiz Research disclosure. Snowflake patch same day, aucun third-party access dans logs.

Permission chain, link par link

Une leçon sur trust CI.

1. Trigger. issues: opened, donc any GitHub account pouvait lancer workflow. Conditional gate toujours true pour event, selon technical coverage.

2. Injection. TITLE=$(echo '${{ github.event.issue.title }}' | sed ...). GitHub expand ${{ }} avant shell, sed escaping arrive trop tard. Single quote ferme string, reste exécute shell.

3. Environment. Runner est machine pleine credentials by design. Jira API token nécessaire pour créer tickets.

4. Exfiltration. Token base64 envoyé out-of-band à Wiz, rien suspect logs.

5. Prize. Token auth internal Atlassian avec read access engineering/security/bounty.

Chaque link ordinary approved infrastructure. Vulnerability était composition, pas single misconfig. Blast radius workflow = tout ce que runner atteint. Same lesson agent governance: question n'est pas what agent is, mais what can touch.

Exploit chained cinq layers de legitimate trust: unauthenticated issue trigger, quote injection shell escape, runner Jira token, out-of-band exfiltration, internal Jira read access. Template expansion avant shell escaping explique sanitisation tardive, selon Wiz.

Ce qui était agentic et ce qui ne l'était pas

Deux mauvaises lectures: scanner marketing ou Skynet. Détails refusent les deux.

Automation ordinaire avec model. Scan/flag. Red Agent crawle workflows pour untrusted interpolation dans run:. Vulnerability class connue, static rule pourrait plausiblement flag. Target/reading/exploitability skilled mais proche attack-surface management.

Réellement agentic. Exploit loop. First payload comment char casse syntaxe. Agent lit bash error, diagnostique malformed payload, réécrit, succeeds second attempt. Puis valide token et blast radius. Novel runtime failure adaptation unprompted n'est pas signature matching. Attempt, observe, correct = agent loop, comme agentic architecture. Offensive, Fortune 500, unsupervised, notable.

Pas l'agent. Scope/ethics/disclosure humains. HackerOne sandbox authorised. Autonomy real mais bounded. Wiz launched Red Agent en mars, GA late July, partly Claude Opus. Capability est product rentable.

Scan/triage automation; agentic core exploit loop : shell syntax error, diagnosis, rewrite, success second attempt, token validation et blast radius sans human help, selon Wiz disclosure.

La Copilot Row est la partie la moins intéressante

Premiers headlines : Copilot wrote bug. Record : non. Copilot Autofix documented contribution était jira_close.yml, different file. Vulnerable interpolation dans human-attributed commit; GitHub dit Copilot neither wrote nor reviewed lines. Co-author label = squash-merge trailer artefact. Wiz amended, media corrected. Ami Luttwak à CSO: co-authors insuffisants quand multiple agents run every PR.

Deux facts coexistent. GitHub Advanced Security scanned final vulnerable revision et n'a rien flag, undisputed. Specific claim Copilot authored flaw unsupported. AI-assisted review missed critical bug. C'est vraie story sur limits of AI review, pas AI writing bug.

Wiz a d'abord implied Copilot wrote vulnerable code, puis clarified documented contribution était different file et co-author label squash-merge artefact. GitHub dit human engineer wrote flaw. Undisputed : GitHub Advanced Security scanned vulnerable revision et flagged nothing, selon Wiz update et CSO.

Que faire maintenant

Si vous exécutez GitHub Actions avec des secrets, voici ce qu'il faut faire cette semaine :

1. Grep ${{ github.event.* }} dans run: blocks. Issue/PR titles, branches, comments interpolés shell = injectable. Use env: + quoting ou jq --arg.

2. Runners = credential stores. Minimum scopes, OIDC short-lived, untrusted-trigger workflows (issues, pull_request_target, comments) internet-facing.

3. AI review pas last line. Scanner GitHub passed exact code. Layer checks, avoid one-vendor review/authorship/scanning dependency.

4. Five-day window est lent. Agent zero knowledge à working credentials under week. Update dwell-time assumptions, same-day credential rotation runbook.

FAQ

Copilot a-t-il écrit la vulnerability Snowflake ?

Non selon current evidence. Co-author label mais documented change autre file, squash artefact, GitHub dit human engineer. True: Advanced Security missed injection.

Comment agent Wiz est entré dans Jira ?

Issue title direct shell interpolation, crafted title -> arbitrary commands runner -> Jira token -> out-of-band exfil -> internal Jira. Patch same day, rotation next day.

Était-ce une vraie attaque ?

Sanctioned via HackerOne. Wiz seul actor dans logs, no customer data. Technique fonctionne identiquement unsanctioned.

Que signifie pour AI security agents ?

Offensive agents ahead defensive. Agent autonomous found/exploited/scoped real flaw alors scanner n'a rien vu. Agent-speed discovery nouvelle baseline.

En bref

Sans Copilot drama : expensive scanner cleared code; autonomous agent weaponised same code et corrected own mistakes. Five-day merged-to-machine-exploit gap est chiffre important. Offensive agents sont product, pas demo. Attribution sera oubliée, capability non.

Si vous calibrez autonomie offensive/defensive dans pipelines, c'est un sujet client régulier. Contactez-moi.

Sources

• 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 (publié 2026-08-17, mis à jour 2026-08-17 19:57 UTC, consulté 2026-08-29)

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

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

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