La differenza era sostanziale. GitHub espande l'espressione prima che il comando venga interpretato dalla shell. Un titolo contenente un apostrofo poteva quindi chiudere la stringa prevista e aggiungere comandi shell scelti dall'attaccante. L'uso successivo di sed per ripulire il valore non poteva annullare un'interpretazione già avvenuta a monte.

Anche il trigger issues: opened non rendeva il titolo affidabile: qualunque utente in grado di aprire una issue nel repository pubblico poteva controllarne il contenuto. Un controllo limitato all'attività sulle issue non impediva dunque l'interpolazione di dati forniti dall'attaccante.

Il commit attribuiva “Copilot Autofix powered by AI” come coautore e la revisione assistita dall'AI non aveva segnalato il problema. Tuttavia, le evidenze disponibili non stabiliscono se Copilot abbia generato la modifica non sicura oppure se abbia semplicemente partecipato alla revisione di un cambiamento scritto da una persona. La conclusione più prudente è che Copilot fosse associato alla modifica e non abbia rilevato l'iniezione, non che l'autore effettivo del codice sia stato dimostrato.

Come l'ha individuata il Red Agent

Il Red Agent di Wiz ha analizzato l'organizzazione GitHub pubblica di Snowflake alla ricerca di schemi rischiosi nei sistemi CI/CD. Ha identificato il workflow Jira come un componente che trasferiva dati non attendibili in un blocco shell run: e ha dedotto che un titolo di issue appositamente costruito avrebbe potuto consentire l'esecuzione arbitraria di comandi sul runner GitHub Actions.

Il 23 giugno — cinque giorni dopo l'unione della modifica vulnerabile — l'agente ha aperto una issue manipolata nell'ambito del programma di divulgazione HackerOne di Snowflake. Il titolo è uscito dalla stringa shell prevista e ha fatto sì che il workflow inviasse le credenziali Jira a un callback out-of-band, cioè a un endpoint esterno usato per verificare in modo controllato l'esecuzione del payload.

Non si è trattato di un'intrusione incontrollata, ma di un test di sicurezza autorizzato. Il risultato tecnico restava significativo: una normale issue pubblica poteva raggiungere un passaggio del workflow che gestiva credenziali interne e trasformarsi in esecuzione di comandi.

Quale accesso è stato esposto

Il workflow compromesso aveva accesso alla configurazione Jira interna di Snowflake, inclusi l'URL del servizio, l'indirizzo email dell'utente e il token API. Il token recuperato era associato a qa@snowflake.net; Wiz lo ha utilizzato per autenticarsi al portale Jira interno e valutare la possibile esposizione.

Le ricostruzioni disponibili descrivono un accesso in lettura a progetti Jira relativi a ingegneria, conformità e sicurezza e attività di bug bounty. Le evidenze fornite non definiscono però l'intero insieme dei permessi del token né offrono un inventario definitivo di tutti i dati raggiungibili. La conclusione sostenibile è quindi che il token consentisse l'accesso a contenuti Jira interni sensibili, non che garantisse accesso illimitato ai sistemi Snowflake.

L'asset vulnerabile era l'automazione CI/CD del repository. Non è stata segnalata alcuna versione distribuita del connettore Snowflake per .NET interessata, perché il problema riguardava il workflow GitHub Actions e non il codice eseguito dal connettore.

La risposta di Snowflake

Wiz ha segnalato la vulnerabilità il 23 giugno. Snowflake ha corretto il workflow nello stesso giorno e ha ruotato la credenziale Jira esposta il giorno successivo.

L'azienda ha poi esaminato i log di audit e ha concluso che Wiz era l'unico attore presente durante la finestra di esposizione. Wiz ha inoltre dichiarato di aver cancellato in modo sicuro i dati ottenuti durante la prova di concetto.

Non sono stati segnalati accessi non autorizzati da parte di terzi, non è stata riportata un'assegnazione CVE e non è stata identificata alcuna versione del connettore interessata. Questi elementi delimitano l'impatto confermato, ma non rendono sicuro il design originale del workflow: un titolo di issue pubblico non avrebbe dovuto diventare parte di un comando shell in un processo che gestiva credenziali interne.

La lezione per la sicurezza CI/CD

Il caso va oltre Snowflake e Copilot. Titoli di issue e pull request, nomi dei branch, commenti e altri valori provenienti dalle espressioni GitHub devono essere trattati come input potenzialmente ostile ogni volta che entrano in un comando shell.

Un workflow più sicuro dovrebbe:

• passare i valori non attendibili tramite variabili d'ambiente invece di interpolarli direttamente negli script run:;
• usare strumenti strutturati come jq per costruire JSON, evitando di assemblare stringhe shell;
• applicare quotatura e validazione al confine con la shell;
• tenere le credenziali lontane, quando possibile, dai passaggi che elaborano contenuti controllabili dall'esterno;
• sottoporre le modifiche generate o revisionate dall'AI allo stesso livello di controllo indipendente riservato al codice scritto da una persona.

L'episodio mostra con particolare chiarezza una dinamica emergente: un sistema di coding assistito dall'AI può non riconoscere una modifica pericolosa in una pipeline CI/CD, mentre un agente offensivo autonomo può individuarla e verificarla nel giro di pochi giorni. L'automazione può accelerare sia la correzione sia lo sfruttamento delle falle, ma non sostituisce una revisione indipendente.

La differenza era sostanziale. GitHub espande l'espressione prima che il comando venga interpretato dalla shell. Un titolo contenente un apostrofo poteva quindi chiudere la stringa prevista e aggiungere comandi shell scelti dall'attaccante. L'uso successivo di sed per ripulire il valore non poteva annullare un'interpretazione già avvenuta a monte.

Anche il trigger issues: opened non rendeva il titolo affidabile: qualunque utente in grado di aprire una issue nel repository pubblico poteva controllarne il contenuto. Un controllo limitato all'attività sulle issue non impediva dunque l'interpolazione di dati forniti dall'attaccante.

Il commit attribuiva “Copilot Autofix powered by AI” come coautore e la revisione assistita dall'AI non aveva segnalato il problema. Tuttavia, le evidenze disponibili non stabiliscono se Copilot abbia generato la modifica non sicura oppure se abbia semplicemente partecipato alla revisione di un cambiamento scritto da una persona. La conclusione più prudente è che Copilot fosse associato alla modifica e non abbia rilevato l'iniezione, non che l'autore effettivo del codice sia stato dimostrato.

Come l'ha individuata il Red Agent

Il Red Agent di Wiz ha analizzato l'organizzazione GitHub pubblica di Snowflake alla ricerca di schemi rischiosi nei sistemi CI/CD. Ha identificato il workflow Jira come un componente che trasferiva dati non attendibili in un blocco shell run: e ha dedotto che un titolo di issue appositamente costruito avrebbe potuto consentire l'esecuzione arbitraria di comandi sul runner GitHub Actions.

Il 23 giugno — cinque giorni dopo l'unione della modifica vulnerabile — l'agente ha aperto una issue manipolata nell'ambito del programma di divulgazione HackerOne di Snowflake. Il titolo è uscito dalla stringa shell prevista e ha fatto sì che il workflow inviasse le credenziali Jira a un callback out-of-band, cioè a un endpoint esterno usato per verificare in modo controllato l'esecuzione del payload.

Non si è trattato di un'intrusione incontrollata, ma di un test di sicurezza autorizzato. Il risultato tecnico restava significativo: una normale issue pubblica poteva raggiungere un passaggio del workflow che gestiva credenziali interne e trasformarsi in esecuzione di comandi.

Quale accesso è stato esposto

Il workflow compromesso aveva accesso alla configurazione Jira interna di Snowflake, inclusi l'URL del servizio, l'indirizzo email dell'utente e il token API. Il token recuperato era associato a qa@snowflake.net; Wiz lo ha utilizzato per autenticarsi al portale Jira interno e valutare la possibile esposizione.

Le ricostruzioni disponibili descrivono un accesso in lettura a progetti Jira relativi a ingegneria, conformità e sicurezza e attività di bug bounty. Le evidenze fornite non definiscono però l'intero insieme dei permessi del token né offrono un inventario definitivo di tutti i dati raggiungibili. La conclusione sostenibile è quindi che il token consentisse l'accesso a contenuti Jira interni sensibili, non che garantisse accesso illimitato ai sistemi Snowflake.

L'asset vulnerabile era l'automazione CI/CD del repository. Non è stata segnalata alcuna versione distribuita del connettore Snowflake per .NET interessata, perché il problema riguardava il workflow GitHub Actions e non il codice eseguito dal connettore.

La risposta di Snowflake

Wiz ha segnalato la vulnerabilità il 23 giugno. Snowflake ha corretto il workflow nello stesso giorno e ha ruotato la credenziale Jira esposta il giorno successivo.

L'azienda ha poi esaminato i log di audit e ha concluso che Wiz era l'unico attore presente durante la finestra di esposizione. Wiz ha inoltre dichiarato di aver cancellato in modo sicuro i dati ottenuti durante la prova di concetto.

Non sono stati segnalati accessi non autorizzati da parte di terzi, non è stata riportata un'assegnazione CVE e non è stata identificata alcuna versione del connettore interessata. Questi elementi delimitano l'impatto confermato, ma non rendono sicuro il design originale del workflow: un titolo di issue pubblico non avrebbe dovuto diventare parte di un comando shell in un processo che gestiva credenziali interne.

La lezione per la sicurezza CI/CD

Il caso va oltre Snowflake e Copilot. Titoli di issue e pull request, nomi dei branch, commenti e altri valori provenienti dalle espressioni GitHub devono essere trattati come input potenzialmente ostile ogni volta che entrano in un comando shell.

Un workflow più sicuro dovrebbe:

• passare i valori non attendibili tramite variabili d'ambiente invece di interpolarli direttamente negli script run:;
• usare strumenti strutturati come jq per costruire JSON, evitando di assemblare stringhe shell;
• applicare quotatura e validazione al confine con la shell;
• tenere le credenziali lontane, quando possibile, dai passaggi che elaborano contenuti controllabili dall'esterno;
• sottoporre le modifiche generate o revisionate dall'AI allo stesso livello di controllo indipendente riservato al codice scritto da una persona.

L'episodio mostra con particolare chiarezza una dinamica emergente: un sistema di coding assistito dall'AI può non riconoscere una modifica pericolosa in una pipeline CI/CD, mentre un agente offensivo autonomo può individuarla e verificarla nel giro di pochi giorni. L'automazione può accelerare sia la correzione sia lo sfruttamento delle falle, ma non sostituisce una revisione indipendente.