La società di sicurezza Wiz ha pubblicato il 17 agosto una ricerca che descrive come il suo agente autonomo di offensive security abbia scoperto e sfruttato una vulnerabilità di script injection in un workflow di GitHub Actions appartenente al repository pubblico snowflakedb/snowflake-connector-net, usando poi la falla per esfiltrare un token che concedeva accesso in lettura al Jira interno di Snowflake.

La sequenza temporale è insolitamente stretta

La vulnerabilità è entrata in produzione quando PR #1218 è stato unito il 18 giugno 2026. Wiz l’ha identificata, sfruttata e segnalata tramite HackerOne il 23 giugno; Snowflake ha applicato la correzione lo stesso giorno nel commit 1dc7766, e ha ruotato il token di Jira il 24 giugno. L’esposizione è durata cinque giorni. Il token si autenticava come qa@snowflake.net nel tenant Atlassian di Snowflake, concedendo accesso in lettura ai progetti di engineering, security-compliance e bug bounty tracking.

Ciò che la cornice comune sbaglia

La storia circola come "un’AI ha scritto il bug e un’altra AI lo ha sfruttato". Questa simmetria è la parte che nessuno può sostenere con certezza. La posizione di GitHub, riferita ai reporter, è che i contributi che hanno portato alla vulnerabilità siano stati scritti da un umano e non siano stati né revisionati né contribuiti da Copilot. Lo stesso post di Wiz aggiunge un aggiornamento ammettendo che non è chiaro se la modifica del codice sia stata assistita dall’AI, e nota che il contributo documentato di Copilot Autofix in quella pull request era una correzione separata a un file diverso. Dunque l’attribuzione dell’autorialità è contestata dal vendor e attenuata dal ricercatore — eppure è l’affermazione che sta guidando la copertura.

Il risultato indiscusso è il più grave

Ciò che nessuno contesta: un agente autonomo ha assemblato da solo l’intera kill chain — ricognizione, scoperta di un workflow iniettabile, sfruttamento, esfiltrazione delle credenziali e movimento laterale in un sistema SaaS separato — contro un importante fornitore di piattaforme dati. E chiunque abbia scritto la falla, la scansione di GitHub non l’ha rilevata prima della merge. È un risultato che riguarda la copertura difensiva, e non dipende in alcun modo dalla disputa sull’autorialità.

Cosa è stato raggiunto e cosa no

Vale la pena nominare una terza distorsione. Si trattava del workflow CI di un repository pubblico di un connettore, e l’accesso ottenuto era accesso in lettura ai progetti Jira. Non era la piattaforma dati di Snowflake, e non erano dati dei clienti. Snowflake afferma che le proprie indagini non hanno trovato prove di accesso non autorizzato oltre ai ricercatori, e che i log di audit mostrano che Wiz era l’unica terza parte sull’endpoint. "Snowflake violata" e "lettura di Jira tramite un runner di Actions" non sono la stessa frase.