Il 18 giugno 2026 un commit co-firmato da "Copilot Autofix powered by AI" ha introdotto una vulnerabilità di script injection nella pipeline CI/CD del connettore .NET di Snowflake. Cinque giorni dopo, Wiz Red Agent — agente AI autonomo di ricerca vulnerabilità — ha identificato la falla, l'ha sfruttata per rubare credenziali Jira interne e ricevuto una callback da un runner Azure. L'incidente documenta per la prima volta in modo verificabile il ciclo completo: intelligenza artificiale che genera una regressione di sicurezza, intelligenza artificiale che la scopre e la sfrutta.
- Copilot Autofix ha rimosso un pattern sicuro con variabili d'ambiente e
jq --arg, sostituendolo con interpolazione diretta di${{ github.event.issue.title }}in un bloccorun:shell - La condizione
if:protettiva era logicamente bypassabile: su eventoissues:openedil riferimentogithub.event.pull_request.user.loginè semprenull, quindi il controllo risulta sempretrue - Wiz Red Agent ha ricevuto callback out-of-band dall'IP Azure 20.106.182.197 con credenziali base64-encoded autenticate come
qa@snowflake.netpersnowflakecomputing.atlassian.net - Snowflake ha patchato il 23 giugno 2026 con commit
1dc7766, ripristinando il patternenv+jq --arg; l'audit non ha rilevato accessi non autorizzati oltre ai test Wiz
Come il pattern sicuro è diventato vulnerabile
Il repository snowflakedb/snowflake-connector-net conteneva una GitHub Actions workflow che processava i titoli delle issue aperte. Il codice originale usava due guardie: una variabile ISSUE_TITLE in env: e il parser JSON jq --arg, che tratta il contenuto come dato letterale anziché come codice eseguibile.
Nel commit 4a1b8ce di PR #1218, Copilot Autofix ha rimosso entrambe le guardie. Al loro posto ha inserito TITLE=$(echo '${{ github.event.issue.title }}' | sed ...) seguito da un echo che interpolava la variabile direttamente in shell. L'input non fidato — il titolo di una issue GitHub aperta da qualsiasi utente autenticato — diventava così eseguibile.
La co-autorship "Copilot Autofix powered by AI" è visibile nel messaggio commit. La fonte non specifica se il maintainer umano (sfc-gh-hpathak) abbia revisionato manualmente il PR prima del merge, né se l'AI abbia agito autonomamente o su richiesta esplicita di fix.
La condizione if che non proteggeva nulla
Il workflow includeva una condizione if: apparentemente protettiva: github.event.pull_request.user.login != 'whitesource-for-github-com[bot]'. Il problema logico è immediato: il trigger era issues:opened, non pull_request. Su quel tipo di evento, github.event.pull_request esiste sempre come oggetto null. Il confronto null != 'stringa' restituisce sempre true in GitHub Actions. La condizione quindi non filtrava alcun input: qualsiasi utente autenticato poteva aprire una issue e iniettare comandi.
Questo meccanismo è documentato nel diff del commit e confermato dalla logica di runtime di GitHub Actions. Non è un bypass sofisticato ma una vulnerabilità strutturale nel workflow stesso, introdotta insieme alla regressione di parsing.
L'exploit: da errore sintattico a credenziali esfiltrate
Wiz Red Agent ha scoperto la vulnerabilità il 23 giugno 2026. Secondo il report di Wiz, l'agente non si è arrestato al primo fallimento. Ha autonomamente analizzato l'errore di sintassi bash, adattato il payload da un carattere # a una sequenza ; echo ', e ricevuto una callback out-of-band dall'indirizzo IP 20.106.182.197 — un runner Azure GitHub Actions.
"Rather than stopping or failing, Red Agent: 1. autonomously analyzed the syntax execution error 2. adjusted its payload... 3. successfully received the out-of-band callback"
— Wiz Research
Il log di esecuzione mostra una curl verso un listener controllato da Wiz. Il payload ha restituito credenziali base64-encoded, decodificate come token autenticato per l'account qa@snowflake.net sull'istanza Jira snowflakecomputing.atlassian.net. Il token ha garantito accesso in lettura a progetti engineering, security compliance e bug bounty tracking di Snowflake. La fonte non specifica il volume esatto di dati consultabili durante il test.
Remediation e dichiarazione Snowflake
Il report HackerOne #3819931 è stato ricevuto da Snowflake il 23 giugno 2026. La stessa giornata, il maintainer sfc-gh-mcepiga ha aperto PR #1402 con commit 1dc7766 che ripristinava il pattern originale: variabile ISSUE_TITLE in env:, parsing con jq --arg title "$ISSUE_TITLE" --arg body "$ISSUE_BODY". La finestra di esposizione è durata cinque giorni, dal 18 al 23 giugno.
In una dichiarazione riportata da Wiz, Snowflake ha confermato: "The disclosure was received on June 23, 2026, and it was immediately investigated and remediated, and our investigation found no evidence of unauthorized access". Le credenziali Jira sono state revocate e rotate. I log di audit non hanno rilevato accessi di terzi durante la finestra.
Cosa fare adesso
Le implicazioni operative emergono chiaramente dal caso. Le organizzazioni che usano AI coding assistant in CI/CD devono implementare controlli che blocchino pattern di regressione noti prima del merge, indipendentemente dall'autore umano o AI. Il meccanismo specifico qui documentato — interpolazione stringa in shell al posto di env+jq --arg — è rilevabile in review automatizzata.
- Auditare le GitHub Actions workflow per sostituzioni di
envvariables con interpolazione diretta in blocchirun:shell, in particolare su eventi triggerabili da utenti esterni (issues,issue_comment,pull_request_target) - Verificare che le condizioni
if:usino riferimenti a oggetti esistenti per il tipo di evento dichiarato nel trigger; ungithub.event.pull_requestsu workflowissues:openedè sempre null e invalida qualsiasi controllo basato su di esso - Valutare l'uso di short-lived credentials per service account CI/CD, con scope limitato al singolo job e revoca automatica post-esecuzione, per ridurre la persistenza di token esfiltrabili
- Implementare gate di sicurezza pre-merge che rilevino pattern di injection shell in workflow YAML, trattando i commit AI-autogenerati con lo stesso rigore — non con meno — dei commit umani
Non è documentato se Snowflake abbia implementato guardrails aggiuntivi oltre al singolo fix. Il brief non specifica misure correttive strutturali post-incidente.
La doppia faccia dell'AI in sicurezza
L'incidente sfugge alla narrazione binaria — AI buona contro AI cattiva. Il medesimo strumento, Copilot Autofix, ha generato la regressione. Un altro strumento, Wiz Red Agent, l'ha scoperta e sfruttata. Entrambi gli eventi sono probabilistici, automatizzati, privi di intenzione. La lezione non è demonizzare l'AI ma riconoscere che la velocità di generazione automatica supera la velocità di review umana, e che i guardrails devono essere anch'essi automatici.
La fonte sottolinea esplicitamente: "how AI coding assistants can inadvertently introduce workflow injection vulnerabilities, and how automated AI agents can rapidly surface them in the wild". La rapidità è il fattore nuovo: cinque giorni tra introduzione e scoperta, un ciclo che le revisioni manuali tradizionali difficilmente coprirebbero. Le implicazioni per la governance del codice generato da AI — in particolare in pipeline CI/CD con accesso a credenziali di produzione — sono immediate e concrete.
Fonti
- https://www.wiz.io/blog/red-agent-snowflake-copilot-cicd-bug
- https://github.com/snowflakedb/snowflake-connector-net/pull/1218
- https://github.com/snowflakedb/snowflake-connector-net/commit/4a1b8cecd65b899540e4324715557d6b080ddeb5
- https://github.com/snowflakedb/snowflake-connector-net/commit/1dc7766
- https://github.com/snowflakedb/snowflake-connector-net/pull/1402
- https://github.com/snowflakedb/snowflake-connector-net
Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.