Una vulnerabilità corretta da Snowflake il 23 giugno 2026 ha mostrato quanto possa essere fragile l’automazione DevOps quando tratta input pubblici come affidabili. Nel repository pubblico snowflakedb/snowflake-connector-net, un semplice issue su GitHub poteva innescare l’esecuzione di comandi nel workflow e arrivare a esporre credenziali interne Jira.
Per chi guida un’azienda, il punto non è solo “un bug su GitHub”: è la conferma che pipeline CI/CD, script automatici e segreti tecnici possono diventare una porta d’ingresso reale, anche senza colpire direttamente il software distribuito ai clienti.
Cosa è successo davvero
Secondo la segnalazione pubblicata da Wiz e ripresa il 17 agosto 2026, il problema riguardava il repository pubblico di Snowflake per il connettore .NET, in particolare il file .github/workflows/jira_issue.yml.
Questo workflow si attivava quando veniva aperto un issue pubblico su GitHub. Il punto critico era che il titolo e il contenuto dell’issue, quindi dati controllabili da chiunque, venivano inseriti direttamente in un blocco run: della shell. In pratica, input non fidati finivano dentro un comando eseguito automaticamente.
Nello stesso workflow erano inoltre disponibili variabili sensibili legate a Jira, tra cui JIRA_BASE_URL, JIRA_USER_EMAIL e JIRA_API_TOKEN. Questo ha creato la combinazione più pericolosa in questi scenari: un trigger pubblico, input manipolabile e segreti accessibili nello stesso contesto di esecuzione.
Wiz afferma di aver sfruttato la debolezza durante un test autorizzato, ottenendo un callback dal runner di GitHub Actions e recuperando il token API Jira usato dal workflow. Secondo la ricostruzione riportata, quel token apparteneva all’account qa@snowflake.net e consentiva accesso in lettura a progetti Jira relativi a ingegneria, conformità di sicurezza e bug bounty su snowflakecomputing.atlassian.net.
È importante però distinguere bene i fatti: non risultano versioni del connettore .NET compromesse, non è stato identificato un impatto sui rilasci software e Snowflake ha dichiarato di non aver trovato prove di accessi non autorizzati. Inoltre, allo stato delle informazioni pubbliche del 17 agosto 2026, non risultavano CVE, punteggio CVSS o inserimento nel catalogo CISA KEV.
Perché la vulnerabilità è stata possibile
Il caso è interessante perché non nasce da un attacco sofisticato contro l’infrastruttura cloud, ma da un errore di progettazione dell’automazione.
Il workflow prendeva contenuti provenienti da un issue pubblico e li espandeva direttamente in shell. Questa è una pratica nota come pericolosa: se l’input contiene caratteri o costrutti interpretati dalla shell, può trasformarsi in comando eseguibile.
C’era poi un secondo problema logico. Il workflow verificava github.event.pull_request.user.login, ma l’evento in questione era un issue, non una pull request. Quella proprietà quindi non esisteva. In GitHub Actions, il riferimento a una proprietà inesistente viene valutato come stringa vuota. Il controllo previsto non fermava dunque il flusso come ci si sarebbe aspettato, lasciando passare un normale issue fino al job vulnerabile.
In altre parole, non si è trattato di una sola svista, ma dell’unione di tre errori tipici:
- fidarsi di input pubblici;
- esporre segreti nello stesso job;
- affidarsi a controlli condizionali non coerenti con l’evento reale.
Le date chiave del caso Snowflake
La cronologia aiuta a capire la finestra di esposizione.
Il workflow vulnerabile è arrivato sul branch di default il 18 giugno 2026, con il merge della pull request #1218. Wiz ha segnalato il problema a Snowflake tramite HackerOne il 23 giugno 2026, nel report #3819931. Nello stesso giorno Snowflake ha corretto il workflow con la pull request #1402, sostituendo l’espansione diretta delle espressioni GitHub con variabili d’ambiente passate come argomenti a jq.
Wiz ha inoltre riferito che il token Jira è stato ruotato il 24 giugno. Secondo Snowflake, la revisione interna non ha rilevato utilizzi esterni non correlati durante la finestra di esposizione di cinque giorni.
Questo aspetto è rilevante: la tempestività nella risposta ha probabilmente contenuto il rischio. Ma il caso dimostra anche quanto breve possa essere il tempo utile a un attaccante quando una pipeline pubblica espone segreti.
Il tema dell’AI nel codice: attenzione alle conclusioni facili
La notizia è stata associata anche a GitHub Copilot Autofix. Wiz descrive la falla come derivante da una modifica collegata a Copilot Autofix, ma la cronologia pubblica dei commit, da sola, non prova che le righe vulnerabili siano state scritte direttamente dall’assistente AI.
Dai dettagli disponibili emerge che un commit esplicitamente co-firmato da Copilot riguardava un file diverso, jira_close.yml, mentre il refactor insicuro di jira_issue.yml compare in un commit separato del 25 agosto 2025 attribuito a un utente umano. Entrambe le modifiche sono poi confluite nel merge del 18 giugno 2026, dove Copilot Autofix compare tra i co-autori.
Per le aziende, il messaggio utile non è cercare un colpevole “umano o AI”, ma capire che il codice generato, suggerito o rifattorizzato automaticamente va revisionato con la stessa severità del codice scritto a mano. In alcuni casi, con ancora più attenzione, soprattutto quando tocca automazioni, autenticazione o gestione dei segreti.
Perché questo caso riguarda anche chi non usa Snowflake
Molte PMI pensano alla sicurezza come a firewall, antivirus e backup. Sono elementi essenziali, ma oggi una parte del rischio si concentra nelle automazioni: repository Git, integrazioni tra strumenti, pipeline di build, ticketing, notifiche e script di supporto.
Un repository pubblico può contenere workflow che aprono ticket, eseguono test, pubblicano pacchetti o dialogano con sistemi interni. Se uno di questi flussi usa credenziali reali e si attiva su eventi generati dall’esterno, il confine tra “strumento di sviluppo” e “superficie d’attacco” si assottiglia moltissimo.
Anche in contesti meno strutturati di Snowflake, il problema si presenta in forme simili:
- script che leggono testo da email o moduli web;
- job automatici che usano account tecnici con privilegi eccessivi;
- chiavi API salvate in chiaro o distribuite in troppi ambienti;
- automazioni create velocemente e mai sottoposte a verifica di sicurezza.
La lezione è semplice: non serve una piattaforma enterprise per avere un rischio enterprise.
Cosa significa per la tua azienda
Se la tua azienda usa GitHub, GitLab, Azure DevOps o anche semplici script di automazione collegati a servizi cloud, questo episodio suggerisce alcune azioni pratiche immediate.
Primo: separa gli input pubblici dai segreti. Un workflow attivato da issue, form, webhook o altri eventi esterni non dovrebbe mai eseguire shell command costruiti direttamente con quei contenuti. E soprattutto non dovrebbe avere a disposizione token sensibili se non strettamente necessario.
Secondo: applica il principio del privilegio minimo. I token tecnici devono poter fare solo ciò che serve davvero, per il minor tempo possibile. Un account Jira con accesso a più progetti interni, ad esempio, amplia inutilmente l’impatto potenziale di una fuga di credenziali.
Terzo: rivedi i workflow CI/CD come faresti con un server esposto su Internet. Le pipeline non sono “solo sviluppo”: sono infrastruttura critica. Vale la pena far controllare i processi, i repository e la gestione dei segreti con un approccio strutturato di sicurezza informatica.
Quarto: rafforza il controllo operativo sugli endpoint e sugli account tecnici. Chi mantiene notebook aziendali, postazioni amministrative e ambienti di sviluppo deve avere criteri chiari di aggiornamento, inventario e configurazione. In questo senso una gestione centralizzata del parco macchine e degli strumenti, come un servizio di desktop IT management, aiuta a ridurre errori e scorciatoie.
Quinto: prepara la risposta all’incidente prima che serva. Se un token viene esposto, bisogna sapere subito chi lo ruota, dove si trovano i log, quali sistemi potrebbero essere coinvolti e come verificare eventuali accessi anomali. Senza una procedura chiara, anche un incidente contenuto rischia di trasformarsi in fermo operativo.
Sesto: non trascurare il backup, ma capiscilo per quello che è. Un buon remote backup è fondamentale per resilienza e continuità, ma non risolve la fuga di credenziali o l’abuso di token. Serve dentro una strategia più ampia, non come unica misura di protezione.
Le lezioni più utili da portare a casa
Il caso Snowflake non indica, sulla base delle fonti pubbliche, un compromesso dei clienti o del prodotto rilasciato. Ma è comunque un campanello d’allarme importante per tre motivi.
Il primo è organizzativo: le automazioni nate per far risparmiare tempo possono introdurre rischi sproporzionati se non vengono progettate con criteri di sicurezza.
Il secondo è tecnico: i segreti nelle pipeline devono essere trattati come accessi privilegiati, non come semplici variabili di comodo.
Il terzo è culturale: anche quando si usano strumenti evoluti, inclusi assistenti AI, la responsabilità finale resta del processo di revisione, del controllo delle modifiche e della segregazione degli accessi.
Per molte aziende italiane il problema non è “evitare il bug perfetto”, ma costruire processi che rendano gli errori meno pericolosi e più rapidi da individuare. È questa la differenza tra un incidente gestibile e una crisi operativa.
Domande frequenti
I clienti Snowflake sono stati compromessi?
Dalle informazioni pubbliche riportate, no. Snowflake ha dichiarato di non aver trovato prove di accessi non autorizzati e non risultano release del connettore .NET coinvolte.
Il problema riguardava il prodotto o solo l’automazione interna?
Il problema era nel workflow GitHub Actions del repository pubblico, quindi nell’automazione CI/CD e nella gestione delle credenziali collegate, non nel software distribuito ai clienti.
Cosa dovrebbe controllare subito una PMI?
Workflow automatici attivati da input esterni, token API presenti nelle pipeline, privilegi degli account tecnici e procedure di rotazione credenziali in caso di incidente.