Una vulnerabilità di script injection presente in un workflow GitHub Actions del repository pubblico snowflakedb/snowflake-connector-net di Snowflake ha consentito a un input controllato da un utente esterno di trasformarsi in comandi eseguiti all’interno del runner CI/CD. Il problema è diventato operativo il 18 giugno 2026, con il merge della pull request #1218 relativa all’automazione dei workflow Jira, ed è stato individuato cinque giorni più tardi da Red Agent, il sistema autonomo di ricerca sulla sicurezza sviluppato da Wiz Research nell’ambito del programma bug bounty HackerOne di Snowflake.
La vulnerabilità interessava il file jira_issue.yml, progettato per avviare automaticamente un workflow quando veniva aperta una nuova issue su GitHub. Il titolo dell’issue, completamente controllabile dall’utente che la creava, veniva inserito direttamente all’interno di uno script shell mediante l’espressione ${{ github.event.issue.title }}. In questa configurazione l’espansione del template di GitHub avveniva prima delle successive operazioni di escaping effettuate con sed: inserendo nel titolo un carattere opportunamente costruito era quindi possibile interrompere la stringa prevista dallo script e aggiungere nuovi comandi destinati all’esecuzione sul runner.
Il codice precedente adottava una gestione più sicura dell’input, trasferendo il titolo dell’issue attraverso una variabile env: e utilizzando jq --arg per costruire il contenuto JSON. La modifica confluita nella pull request ha sostituito questo meccanismo con l’interpolazione diretta del titolo all’interno della shell, eliminando così la separazione tra dato proveniente dall’utente e codice eseguibile. Il commit finale attribuisce a Copilot Autofix powered by AI il ruolo di coautore e la revisione assistita da Copilot non ha rilevato la vulnerabilità; Wiz ha successivamente precisato che non è possibile stabilire con certezza se la specifica modifica vulnerabile sia stata materialmente generata dall’AI, un dettaglio importante per distinguere il ruolo dell’assistente nella revisione da quello nell’effettiva produzione del codice.
Anche una condizione presente nel workflow, apparentemente destinata a limitare l’esecuzione, non forniva una protezione effettiva. Il controllo faceva riferimento a github.event.pull_request.user.login durante un evento di tipo issues; in questo contesto github.event.pull_request risulta nullo, per cui il confronto utilizzato nella condizione veniva valutato in modo da consentire comunque l’esecuzione. Dal momento che il workflow era attivato da issues: opened, qualsiasi account GitHub poteva raggiungere il percorso vulnerabile semplicemente creando una nuova issue nel repository.
Red Agent ha identificato autonomamente il pattern vulnerabile, costruito un payload e tentato di sfruttarlo direttamente contro il workflow. Il primo tentativo è terminato con un errore di sintassi Bash, perché il carattere utilizzato per commentare la parte restante del comando eliminava anche una parentesi necessaria alla corretta chiusura dell’espressione. L’agente ha analizzato l’errore restituito dal runner, modificato il payload e ripetuto autonomamente l’operazione, ottenendo questa volta l’esecuzione dei comandi e una connessione verso un endpoint esterno controllato dai ricercatori.
Attraverso questa tecnica è stato possibile estrarre dal contesto di esecuzione del runner le variabili JIRA_API_TOKEN, JIRA_USER_EMAIL e JIRA_BASE_URL, codificandole in Base64 e inviandole tramite curl. Il token recuperato risultava associato all’account qa@snowflake.net e permetteva l’accesso in lettura a progetti Jira interni relativi, tra gli altri ambiti, all’ingegneria, alla conformità di sicurezza e al programma bug bounty di Snowflake. Il test ha quindi dimostrato che una vulnerabilità presente in un repository pubblico poteva diventare un percorso di accesso verso credenziali e servizi appartenenti all’infrastruttura interna dell’azienda.
La segnalazione è stata inviata a Snowflake il 23 giugno attraverso HackerOne. Nella stessa giornata il workflow è stato corretto ripristinando la gestione del titolo mediante variabile d’ambiente e jq --arg, mentre il token Jira interessato è stato successivamente revocato e ruotato. L’analisi dei log condotta da Snowflake ha indicato che, nei cinque giorni durante i quali la vulnerabilità è rimasta esposta, le attività anomale rilevate corrispondevano ai test effettuati da Wiz e non sono emerse evidenze di accessi non autorizzati da parte di soggetti esterni.
L’episodio mostra in modo particolarmente concreto cosa può accadere quando strumenti AI vengono inseriti contemporaneamente nei processi di sviluppo e nelle attività di sicurezza automatizzata. In questo caso una modifica che eliminava un pattern di sanitizzazione già presente è passata attraverso un processo nel quale Copilot figurava come coautore e revisore senza segnalare il problema, mentre pochi giorni dopo un agente autonomo dedicato alla sicurezza ha individuato la vulnerabilità, prodotto un exploit funzionante, corretto autonomamente un primo tentativo fallito e verificato l’accesso alle credenziali presenti nel runner. Il controllo del codice generato o revisionato con strumenti AI rimane quindi parte integrante della sicurezza della pipeline CI/CD, insieme all’analisi statica dei workflow, alla separazione degli input non attendibili dal codice shell e alla riduzione dell’esposizione delle credenziali utilizzate dagli ambienti di automazione.
Questo articolo è stato redatto con il supporto di strumenti di intelligenza artificiale (AI)