Il token Jira di Snowflake: una vulnerabilità cofirmata da Copilot, e l'umano che GitHub sostiene l'abbia scritta

Il 23 giugno 2026 Red Agent, un agente di sicurezza autonomo sviluppato da Wiz, ha aperto una issue su un repository GitHub pubblico di proprietà di Snowflake e ne è tornato con una credenziale. Il repository era snowflakedb/snowflake-connector-net, e il workflow responsabile, .github/workflows/jira_issue.yml, ha lo scopo di creare un ticket Jira ogni volta che qualcuno apre una issue — inseriva il titolo del ticket in un comando shell invece di passarlo tramite una variabile d'ambiente, così un titolo appositamente costruito veniva eseguito come codice sul runner di GitHub Actions. Il token recuperato da Red Agent si autenticava come qa@snowflake.net su snowflakecomputing.atlassian.net e conferiva accesso in lettura ai progetti Jira engineering, security-compliance e bug-bounty di Snowflake. La vulnerabilità era attiva da cinque giorni. Wiz ha pubblicato la propria analisi completa il 17 agosto 2026. Questo incidente è catalogato come record 2026-08-17-snowflake-jira-zhao-dao-can presso il Orca AI Incident Archive, che contiene l'intero insieme di record con i suoi livelli di affidabilità e le fonti citate.

L'interpolazione, e la guardia che non è mai stata eseguita

Il workflow è stato attivato sull'evento GitHub "issues: opened". Chiunque avesse un account GitHub poteva farlo scattare aprendo un issue su un repository pubblico — nessun invito, nessun ruolo di maintainer, nessun fork. Il passaggio vulnerabile leggeva il titolo dell'issue in una variabile di shell: TITLE=$(echo '${{ github.event.issue.title }}' | sed ...), con due filtri che avevano lo scopo di effettuare l'escape delle virgolette doppie e degli apici singoli prima che la stringa fosse assemblata.

Il difetto è nell'ordine delle operazioni, non nell'escaping. GitHub sostituisce il contenuto dell'espressione nel testo dello script prima ancora che bash lo analizzi, quindi un apice singolo all'interno del titolo dell'issue chiude la stringa quotata che echo tiene aperta. I due filtri sed vengono eseguiti all'interno di quello stesso script, dopo la sostituzione, e non possono correggere una quotatura che ha già cambiato il modo in cui la riga viene analizzata. L'analisi di Wiz afferma esplicitamente che l'escaping arriva troppo tardi per impedire il breakout, e che un titolo costruito con un apice di chiusura e un punto e virgola aggiunge comandi scelti dall'attaccante allo step di esecuzione.

Un secondo controllo avrebbe dovuto restringere il pubblico e non lo ha fatto. Il job conteneva una condizione if che confrontava github.event.pull_request.user.login con il login del bot whitesource-for-github-com, evidentemente per impedire che le pull request automatiche delle dipendenze aprissero ticket. In un evento issues non esiste affatto un oggetto pull request, quindi il confronto avviene con una proprietà null. La documentazione di GitHub stessa, citata da The Hacker News, afferma che la dereferenziazione di una proprietà inesistente restituisce una stringa vuota; l'analisi di Wiz giunge allo stesso risultato tramite il valore null. In entrambi i casi la condizione risultava vera per ogni utente, e l'eccezione per il bot è diventata un lasciapassare per internet.

Ciò che ha reso l'iniezione meritevole di segnalazione anziché routine è stato il contesto in cui si trovava. Lo stesso passaggio conteneva JIRA_BASE_URL, JIRA_USER_EMAIL e JIRA_API_TOKEN come variabili d'ambiente, quindi l'esecuzione arbitraria di comandi sul runner aveva una credenziale a portata di mano anziché un substrato vuoto. Nessuna versione di Snowflake Connector for .NET è stata identificata come interessata: la debolezza risiedeva nell'automazione CI/CD del repository, non nel codice del connettore distribuito.

Ciò che Red Agent ha preso, e ciò che dice di aver buttato via

Il resoconto di Wiz sullo sfruttamento è ciò che distingue questo caso dalla semplice scoperta di uno scanner. Il primo payload usava un carattere hash, che ha commentato la parentesi di chiusura dell'assegnazione TITLE=$(...) e ha prodotto un errore di sintassi bash invece di un callback. L'agente ha letto l'errore e ha riscritto il payload per chiudere il blocco shell con un punto e virgola e una nuova virgoletta per echo, poi ha ricevuto una chiamata out-of-band. Il payload usava curl per raggiungere un sottodominio di oast.me con i valori codificati in base64 delle tre variabili delle credenziali, e il callback è arrivato dall'IP Azure 20.106.182.197, un indirizzo che Wiz attribuisce a un runner di GitHub Actions.

Il token restituito era un token API Jira per qa@snowflake.net, e Wiz descrive la sua portata come accesso in lettura che abbraccia i progetti di ingegneria, conformità alla sicurezza e monitoraggio del bug bounty sull'istanza cloud Atlassian di Snowflake. Questo è il danno che l'archivio registra: non l'esecuzione di codice su una macchina di build per cinque giorni, ma una credenziale che poteva leggere le code dei ticket in cui vengono registrati bug irrisolti di ingegneria e sicurezza — inclusi, secondo la descrizione di Wiz, il tracker del bug bounty.

Wiz afferma di aver eliminato in modo sicuro tutto ciò a cui ha avuto accesso durante la proof of concept. Snowflake, in una dichiarazione a CSO Online, ha affermato che il rapporto «è stato immediatamente analizzato e correttо» e che «la nostra indagine non ha trovato prove di accesso non autorizzato»; il blog di Wiz aggiunge che Snowflake ha esaminato i log di audit per la finestra di cinque giorni e non ha trovato alcun uso da parte di terzi oltre agli indirizzi di test di Wiz stesso. Snowflake non ha pubblicato quei log, quindi la conclusione che non vi siano altri attori si basa sul suo resoconto e sul riassunto che Wiz ne fa, anziché su documenti che chiunque al di fuori delle due organizzazioni possa leggere.

Chi ha scritto la riga vulnerabile

Quella domanda ha dato origine alla seconda storia, più ampia. La PR #1218, intitolata "SNOW-2069227: Update jira workflows", è stata integrata tramite squash merge il 18 giugno 2026 come commit 4a1b8ce, e il commit di squash elenca Copilot Autofix powered by AI tra i suoi coautori. Il titolo originale di Wiz faceva leva esattamente su questo, descrivendo la falla come presente in una pull request assistita da GitHub Copilot, e la copertura iniziale della stampa specializzata seguì la stessa linea: il titolo di SC Media recitava "L'agente di Wiz trova una falla nel repository Snowflake nel codice co-scritto da GitHub Copilot Autofix".

La posizione di GitHub, riportata da The Next Web e sintetizzata in una nota di ricerca della Cloud Security Alliance, è che la sua revisione interna ha rilevato che «una persona ha scritto i contributi che hanno portato alla vulnerabilità» e che Copilot Autofix «non li ha né esaminati né contribuito ad essi». La base tecnica di tale confutazione si trova nella cronologia git. Il squash-merge comprime una pull request in un unico commit e riporta in avanti ogni trailer di coautore indipendentemente dalle righe toccate da tale autore, quindi una riga di coautore registra la partecipazione alla pull request, non la paternità di uno specifico hunk. Il commit coautoriale di Copilot nella stessa pull request, 6d0e2fa, ha modificato jira_close.yml, un workflow diverso dal jira_issue.yml vulnerabile. L'interpolazione non sicura è attribuita al commit 094038e, datato 25 agosto 2025 e attribuito da GitHub a un ingegnere Snowflake, sfc-ghpathak; la PR #1218 ha portato quel pattern sul branch predefinito a giugno 2026.

Wiz non ha ritirato la scoperta e ha cambiato l'impostazione il giorno della pubblicazione. Il suo blog contiene un aggiornamento pubblicato alle 19:57 UTC del 17 agosto che descrive Copilot come "un coautore che ha controllato la PR sottoposta a merge e la modifica al codice" che "l'ha identificato come del tutto sicuro" senza rilevare le vulnerabilità, e ammette che "non è chiaro se la modifica al codice sia stata assistita dall'AI". In quella ricostruzione, il fallimento dell'AI riguarda la revisione, non la paternità: la pull request sottoposta a merge recava una cofirma di Copilot e l'iniezione è sopravvissuta. CSO Online cita Ami Luttwak, CTO di Wiz, secondo cui l'attribuzione chiara tra umani e AI "sta diventando un po' più difficile da stabilire" e "guardare soltanto ai coautori della PR non basta".

Ciò che i due resoconti condividono merita di essere separato da ciò che contestano. Entrambi concordano sul fatto che il commit squash contenga il trailer di co-autore di Copilot Autofix e che il workflow fosse sfruttabile. Nessuno dei due contesta che GitHub Advanced Security abbia scansionato la revisione finale della pull request, estratto jira_issue.yml e non abbia segnalato l’injection — Wiz lo riporta come un mancato rilevamento, mentre la replica di GitHub riguarda l’autorialità e non la scansione. Ciò che resta irrisolto è se Copilot abbia esaminato o meno le righe vulnerabili: Wiz afferma che una revisione è stata eseguita e le ha lasciate passare, GitHub sostiene che lo strumento non abbia avuto alcun ruolo rispetto a esse, e i log che potrebbero risolvere la questione sono in possesso di una delle due aziende. Il resoconto riporta entrambe le versioni anziché scegliere.

Cinque giorni, e cosa è cambiato dopo

La correzione è stata rapida una volta arrivata la segnalazione. Wiz ha presentato tramite il programma HackerOne di Snowflake il report #3819931 il 23 giugno e ha notificato il team di sicurezza di Snowflake via Slack lo stesso giorno; Snowflake ha effettuato il merge della PR #1402, commit 1dc7766, che ha sostituito l'espansione diretta delle espressioni con variabili d'ambiente passate a jq come argomenti. La cronologia di Wiz colloca la rotazione del token Jira al 24 giugno, e The Hacker News riporta la stessa separazione. L'introduzione di Wiz, al contrario, afferma che Snowflake ha risolto la vulnerabilità e ruotato la credenziale "lo stesso giorno" — una discrepanza all'interno della fonte primaria che il resoconto non dovrebbe occultare. La correzione è arrivata il 23 giugno; la rotazione è datata 24 giugno nella tabella di Wiz.

La divulgazione ha seguito i tempi di Snowflake: Wiz fissa una scadenza per la divulgazione pubblica al 25 luglio 2026, trenta giorni dopo una risoluzione del 25 giugno ai sensi della policy del programma, e ha pubblicato l'analisi il 17 agosto. La dichiarazione di Snowflake a CSO Online affermava che l'azienda «apprezza la segnalazione responsabile di Wiz» e che stava collaborando con Wiz per condividere gli insegnamenti con il settore. Né l'analisi di Wiz né il rapporto di The Hacker News riportano un identificatore CVE, un punteggio CVSS o una voce nel catalogo delle vulnerabilità sfruttate attivamente di CISA; la falla era una configurazione di workflow in un repository pubblico, non una libreria distribuita, quindi non è mai entrata in un database delle vulnerabilità nel modo consueto.

Cosa stabilisce il verbale, e cosa non stabilisce

L'archivio classifica questo caso come una scoperta di ricerca anziché un evento di deployment, con severità alta, un grado di confidenza A, coinvolgimento dell'AI confermato e un danno reale registrato; la sua data, 17 agosto 2026, è il giorno in cui Wiz ha pubblicato, mentre l'incidente stesso copre dal 18 al 23 giugno. Il nucleo stabilito è ristretto e verificabile: un workflow pubblico ha interpolato testo controllato dall'attaccante in un comando shell, la sua condizione di guardia veniva confrontata con una proprietà che è nulla su quell'evento, un token Jira si trovava nello stesso step, un agente autonomo lo ha sfruttato e Snowflake ha integrato una correzione e ruotato la credenziale entro un giorno.

Le parti che sono inferenza anziché documentazione sono quelle che i resoconti informali tendono ad appiattire. Copilot Autofix è documentato come coautore della pull request e non è documentato come autore delle righe vulnerabili; l'inquadramento IA-contro-IA che ha dominato il primo ciclo di notizie è stato in parte ritirato dall'organizzazione giornalistica nel giro di poche ore e smentito da GitHub. Se la revisione AI della pull request sottoposta a merge abbia esaminato jira_issue.yml è ancora una questione fattuale aperta, non una questione risolta. E l'ampiezza dell'accesso, pur essendo descritta in dettaglio da Wiz, non è stata verificata in modo indipendente: nessuna autorizzazione Jira, esecuzione di workflow o registro di audit è stato reso pubblico.

Il pattern di correzione è quello che le stesse linee guida di GitHub raccomandavano da luglio 2025: passare i dati non attendibili delle issue in una variabile d'ambiente e consegnarli a jq come argomento, invece di espanderli all'interno di un blocco run. Il commit unito di Snowflake fa esattamente questo, e la gestione corretta resta sul branch predefinito. Per chiunque legga il verbale come precedente, la conclusione duratura riguarda l'attribuzione più che l'iniezione: quando una pull request coinvolge diversi esseri umani e diversi agenti, il trailer del co-autore non può dire chi ha scritto una riga, e sia Wiz sia GitHub alla fine lo hanno affermato con parole diverse.