Copilot Autofix ha aperto un’iniezione di shell nella pipeline CI/CD di Snowflake

Una correzione di sicurezza scritta da Copilot Autofix di GitHub e unita a un repository di Snowflake il 18 giugno 2026 ha rimosso un modello di input sanitizzato e ha lasciato la pipeline CI/CD dell’azienda vulnerabile a un’iniezione di comandi, e cinque giorni dopo un agente di ricerca AI autonomo ha trovato la falla, l’ha sfruttata e ha estratto credenziali Jira funzionanti da un runner di GitHub Actions, Wiz Research ha divulgato il 17 agosto 2026.

La vulnerabilità si trovava in jira_issue.yml, un workflow di GitHub Actions in snowflakedb/snowflake-connector-net, il repository pubblico per il connettore dati .NET di Snowflake. Il workflow si attivava ogni volta che qualcuno apriva una issue su GitHub e interpolava il titolo della issue (testo interamente controllato dalla persona che la apriva) direttamente in uno script shell. Poiché il trigger era issues: opened, qualsiasi account GitHub su Internet poteva raggiungerlo senza autenticazione.

Il “Red Agent” di Wiz, uno strumento di ricerca di sicurezza autonomo operante tramite il programma di bug bounty HackerOne di Snowflake, ha segnalato il workflow, ha costruito un exploit funzionante e ha esfiltrato un token API di Jira dall’ambiente del runner. Snowflake ha corretto il workflow lo stesso giorno in cui ha ricevuto il rapporto, 23 giugno 2026, ha ruotato le credenziali un giorno dopo e ha comunicato a Wiz che i log di audit non mostrano alcun altro attore che abbia toccato i sistemi esposti durante la finestra di cinque giorni.

L’“Autofix” ha rimosso il sanitizzatore

Il commit che ha introdotto il modello iniettabile è stato introdotto tramite PR #1218, “SNOW-2069227: Update jira workflows”, unito il 18 giugno 2026. La cronologia della pull request mostra un autore umano che lavorava sull’automazione Jira da agosto 2025 — e, a metà, un commit co‑autorizzato da Copilot Autofix powered by AI, il bot GitHub Advanced Security che genera correzioni suggerite per gli avvisi di scansione del codice.

Il suggerimento AI ha modificato il modo in cui il workflow gestiva il titolo della issue. Il codice esistente passava il titolo attraverso una variabile env: e costruiva il payload JSON con jq --arg, un modello che mantiene il testo non attendibile fuori dalla shell. La sostituzione proposta ha eliminato quel meccanismo a favore di un’espansione diretta della stringa:

“ run: | TITLE=$(echo '${{ github.event.issue.title }}' | sed 's/"/\"/g' | sed "s/'/\'/g") “

L’escaping con sed avviene dopo che il motore di template di GitHub ha già sostituito il titolo nello script. Un apostrofo nel titolo rompe il wrapper echo '...', e tutto ciò che segue viene eseguito come shell. La documentazione di Copilot Autofix descrive la funzionalità come la generazione di “una singola correzione suggerita per un avviso, che si rivede e si applica autonomamente” — il passaggio di revisione è dove questa è passata.

Il workflow includeva anche una condizione di guardia che sembrava limitare chi potesse attivarlo:

“ if: (github.event_name == 'issues' && github.event.pull_request.user.login != 'whitesource-for-github-com[bot]') “

Negli eventi di issue, github.event.pull_request è sempre nullo, quindi il confronto è sempre vero. Ogni utente GitHub superava il filtro.

Un agente su ciascun lato dello sfruttamento

Il primo tentativo di esfiltrazione del Red Agent è fallito. Il suo payload usava il carattere di commento # per inghiottire il resto della riga iniettata, ma il commento ha anche consumato la parentesi di chiusura di TITLE=$(...), e il runner ha restituito un errore di sintassi bash invece di eseguire. Secondo il resoconto di Wiz, l’agente ha analizzato l’errore, ha riscritto il payload per chiudere il blocco shell con ; echo ', e ha provato di nuovo.

Il payload funzionante, consegnato come titolo della issue, ha codificato in base64 le variabili d’ambiente JIRA_API_TOKEN, JIRA_USER_EMAIL e JIRA_BASE_URL del runner e le ha inviate a un listener out‑of‑band tramite curl. La callback è arrivata da un runner GitHub Actions ospitato su Azure entro pochi secondi.

Il token recuperato si è autenticato come [email protected] contro snowflakecomputing.atlassian.net, con accesso in lettura a tutti i progetti di ingegneria, conformità sicurezza e tracciamento dei bug bounty di Snowflake.

La rimessione di Snowflake, unita in PR #1402 il 23 giugno 2026, ha ripristinato la sicura variabile env: e il modello di parsing jq --arg. Il token Jira è stato revocato e ruotato il 24 giugno 2026. Wiz ha dichiarato di aver eliminato in modo sicuro tutti i dati a cui ha avuto accesso durante i test di prova di concetto.

“Snowflake apprezza la segnalazione responsabile di Wiz e la collaborazione su questi risultati attraverso il nostro programma di divulgazione delle vulnerabilità e bug bounty, HackerOne,” ha dichiarato l’azienda in una nota pubblicata con il rapporto di Wiz. “La segnalazione è stata ricevuta il 23 giugno 2026, è stata immediatamente investigata e rimediata, e la nostra indagine non ha trovato prove di accessi non autorizzati.”

Cosa mostra la finestra di cinque giorni

La divulgazione si colloca al centro di un modello documentato: modifiche assistite da AI che attraversano la revisione più rapidamente delle ipotesi di sicurezza su di esse. I log di audit di Snowflake sono ciò che rende leggibile questo incidente: permettono all’azienda di affermare, e a Wiz di confermare, che la finestra di esposizione non ha prodotto accessi di terze parti. L’analisi dei log di audit di Snowflake ha confermato che nessuna entità esterna ha acceduto al punto finale durante i cinque giorni.

La cronologia comprime anche una sequenza che l’industria ha trattato come ipotetica. Un assistente di codifica ha rimosso un modello difensivo inserito appositamente per prevenire iniezioni di shell, perché l’assistente non aveva traccia del motivo per cui quel modello esistesse. Un agente offensivo ha quindi trovato e armato il risultato in pochi giorni, auto‑correggendo il proprio exploit contro l’output di errore live. Il lato exploit è stato eseguito senza un umano alla tastiera; sul lato codifica, l’AI ha generato la modifica ma un umano ha applicato il suggerimento e lo ha unito — esattamente il passaggio di revisione che è fallito.

Il rapporto di Wiz raccomanda che le pull request generate da AI passino attraverso la stessa analisi statica del codice umano, che i team riducano la durata delle credenziali per eguagliare la velocità di scoperta automatizzata, e che le barriere di sicurezza impediscano agli agenti di sostituire parser strutturati con interpolazioni dirette di stringhe. Check Point ha spostato l’ispezione dei prompt per il traffico AI nei firewall aziendali all’inizio di quest’estate, e Unite.AI ha trattato le fughe di sandbox degli agenti e i sistemi agentici che raggiungono obiettivi di produzione reale man mano che il lato offensivo matura. L’incidente Snowflake è la stessa storia raccontata dall’interno di una pipeline CI: la vulnerabilità è stata attiva per cinque giorni, e l’unica ragione per cui appare come case study anziché notifica di violazione è quale agente è arrivato per primo.