Un difetto nel workflow GitHub Actions del repository pubblico di Snowflake ha permesso, tramite issue appositamente create, l'esecuzione di comandi con accesso alle credenziali interne Jira. Nessuna compromissione di clienti o rilasci del connettore .NET, ma l'incidente evidenzia i rischi delle automazioni CI/CD.
Un team di ricercatori di Wiz ha individuato una vulnerabilità di injection nel workflow GitHub Actions del repository pubblico snowflakedb/snowflake-connector-net di Snowflake. Il problema, riscontrato nel file .github/workflows/jira_issue.yml, consentiva a un utente malintenzionato di inserire comandi arbitrari tramite la creazione di una issue su GitHub, sfruttando la gestione non sicura dei dati forniti dall'utente nel titolo e nel corpo dell'issue.
Come funzionava l'exploit e quali dati erano a rischio
Il workflow vulnerabile veniva attivato all'apertura di una issue pubblica e utilizzava direttamente i valori forniti dall'utente all'interno di un blocco shell run:, senza adeguata sanitizzazione. In questo modo, era possibile iniettare comandi che venivano eseguiti con le stesse autorizzazioni del runner, incluso l'accesso alle variabili d'ambiente JIRA_BASE_URL, JIRA_USER_EMAIL e JIRA_API_TOKEN. Queste credenziali appartenevano all'account qa@snowflake.net e garantivano accesso in sola lettura a diversi progetti Jira interni, tra cui quelli di ingegneria, sicurezza e bug bounty su snowflakecomputing.atlassian.net.
Tempistiche, fix e impatto reale
Wiz ha segnalato la vulnerabilità a Snowflake tramite HackerOne il 23 giugno 2026. Lo stesso giorno, Snowflake ha corretto il workflow tramite la pull request #1402, sostituendo l'espansione diretta delle espressioni GitHub con l'uso di variabili d'ambiente passate come argomenti a jq. Il workflow vulnerabile era stato introdotto cinque giorni prima, il 18 giugno, con la merge della pull request #1218. Secondo Snowflake, non sono emerse evidenze di accessi non autorizzati e il token Jira è stato ruotato il 24 giugno. I log di audit interni non sono stati resi pubblici.
Origine della vulnerabilità e raccomandazioni
La causa principale è stata una modifica automatica suggerita da GitHub Copilot Autofix, anche se la cronologia delle commit non attribuisce con certezza la paternità del codice vulnerabile a Copilot. GitHub aveva già documentato questo tipo di rischio nel luglio 2025, raccomandando di non interpolare direttamente dati non affidabili nei blocchi run:, ma di utilizzare variabili intermedie. Al momento, non risultano CVE, punteggi CVSS o segnalazioni CISA KEV associate a questo incidente, né aggiornamenti del connettore .NET collegati al problema. Non sono stati rilevati casi di sfruttamento malevolo o compromissione di clienti.
