GitLab, Snowflake e Forminator espongono progetti, CI/CD e siti WordPress

🛡️ Executive Summary

• GitLab corregge CVE-2026-19478, falla GraphQL CVSS 9.4 che può permettere a utenti non autenticati di modificare o cancellare progetti pubblici.
• Un workflow GitHub Actions di Snowflake consentiva command injection tramite il titolo di una issue e poteva esporre credenziali Jira interne.
• Forminator CVE-2026-15748 permette upload PHP senza autenticazione e potenziale RCE su WordPress con specifiche configurazioni dei moduli.

Tre nuove vulnerabilità riportano l’attenzione sulla supply chain dello sviluppo software e sulle applicazioni Web esposte pubblicamente. GitLab ha distribuito una patch critica fuori calendario per CVE-2026-19478, falla GraphQL capace in determinate condizioni di consentire a un utente non autenticato di modificare o cancellare progetti pubblici. Snowflake ha corretto invece un workflow GitHub Actions vulnerabile a command injection attraverso semplici issue pubbliche, con credenziali Jira presenti nell’ambiente di esecuzione. Su WordPress, Forminator, installato su oltre 600.000 siti, ha risolto CVE-2026-15748, vulnerabilità CVSS 9.8 che permette l’upload arbitrario di file e può arrivare all’esecuzione di codice PHP.

GitLab corregge una falla GraphQL critica senza autenticazione

CVE-2026-19478 interessa GitLab Community Edition ed Enterprise Edition e ha ricevuto un punteggio CVSS 9.4. Secondo il Critical Patch Release di GitLab, in determinate condizioni un attaccante remoto privo di credenziali può sfruttare una direttiva GraphQL per modificare o cancellare progetti pubblici e dati degli utenti. Sono interessate tutte le release dalla 18.2 precedenti alla 18.11.11, la serie 19.0 prima della 19.0.8, la 19.1 prima della 19.1.6 e la 19.2 prima della 19.2.4. GitLab.com e GitLab Dedicated risultano già aggiornati, mentre gli amministratori delle installazioni self-managed devono intervenire direttamente. GitLab non ha divulgato quale direttiva GraphQL sia coinvolta né le condizioni precise necessarie per completare l’attacco, riducendo temporaneamente le informazioni disponibili per sviluppare un exploit. Non risultano inoltre, al momento della disclosure, evidenze pubbliche di sfruttamento attivo. La vulnerabilità arriva in un periodo nel quale la superficie DevOps è sottoposta a forte pressione: pochi giorni fa GitLab era già comparsa insieme a Fastjson e OpenJudge in un ciclo di vulnerabilità critiche, confermando quanto repository, CI/CD e sistemi di gestione del codice siano diventati infrastrutture ad alto valore.

Una seconda falla GitLab consente mutation attraverso richieste GET

Lo stesso aggiornamento risolve CVE-2026-19650, classificata High con CVSS 7.1. Il problema riguarda il gestore delle query multiplex GraphQL e deriva da una validazione insufficiente delle richieste: un utente non autenticato può, in determinate condizioni e con l’interazione della vittima, eseguire mutation attraverso richieste GET. L’impatto è inferiore rispetto alla CVE critica perché richiede user interaction, ma entrambe le vulnerabilità interessano la stessa superficie GraphQL e sono state corrette nello stesso rilascio straordinario. GitLab sottolinea che l’aggiornamento non introduce nuove migrazioni e non dovrebbe comportare downtime nei deployment multi-node. Per le organizzazioni che gestiscono istanze self-hosted il problema non riguarda soltanto i repository sorgente: GitLab può custodire secret, pipeline, runner, configurazioni di deployment e token di automazione, rendendo qualsiasi compromissione del control plane potenzialmente estendibile alla supply chain. È lo stesso rischio emerso quando GitHub Actions è stato trasformato in una rete distribuita attraverso workflow pubblici, mostrando come l’automazione dello sviluppo costituisca ormai una superficie offensiva autonoma.

Una issue GitHub permetteva di eseguire comandi nel workflow Snowflake

Il caso Snowflake non nasce da una vulnerabilità nel prodotto commerciale, ma dal repository pubblico snowflakedb/snowflake-connector-net. Wiz Research ha individuato nel workflow .github/workflows/jira_issue.yml una script injection attivabile semplicemente aprendo una nuova issue GitHub con un titolo appositamente costruito. Il workflow interpolava direttamente github.event.issue.title all’interno di un blocco shell run:; un carattere quote opportunamente inserito permetteva di interrompere il comando previsto e aggiungere istruzioni arbitrarie. L’ambiente conteneva inoltre JIRA_BASE_URL, JIRA_USER_EMAIL e JIRA_API_TOKEN, consentendo ai ricercatori di dimostrare l’accesso in lettura ai progetti interni Snowflake relativi a engineering, security compliance e bug bounty. Wiz ha segnalato il problema il 23 giugno 2026 e Snowflake lo ha corretto lo stesso giorno, ruotando successivamente il token. L’analisi forense non avrebbe rilevato accessi di terze parti durante i cinque giorni nei quali il workflow vulnerabile è rimasto online. La vulnerabilità si inserisce nella crescente attenzione verso workflow GitHub manipolabili anche da agenti AI e automazioni autonome, dove codice apparentemente periferico può diventare il percorso più breve verso secret e sistemi interni.

Copilot aveva approvato la modifica che introduceva la regressione

La dinamica Snowflake contiene anche un elemento significativo sul rapporto tra AI coding assistant e sicurezza del codice. La modifica vulnerabile era entrata nel repository il 18 giugno con una pull request il cui commit finale indicava Copilot Autofix powered by AI come co-autore. Secondo Wiz, il cambiamento sostituiva un precedente pattern più sicuro, nel quale il titolo dell’issue veniva passato attraverso una variabile d’ambiente e gestito con jq --arg, con l’interpolazione diretta dentro lo script shell. Il controllo assistito da Copilot non ha evidenziato la regressione. Wiz precisa però che non è possibile stabilire se l’intera modifica originaria sia stata generata dall’AI: il dato verificabile è la partecipazione di Copilot Autofix al commit e il mancato riconoscimento della vulnerabilità. Il caso rafforza il problema già emerso con agenti AI capaci di intervenire direttamente sui sistemi di sviluppo e sulle pipeline: l’automazione può ridurre i tempi di produzione, ma non conserva necessariamente il contesto storico che spiega perché un pattern apparentemente più complesso fosse stato scelto proprio per evitare una injection. Non a caso Google ha recentemente indicato la supply chain open source come una delle superfici destinate a crescere maggiormente.

Forminator permette l’upload di PHP senza autenticazione

Sul fronte WordPress, CVE-2026-15748 interessa Forminator Forms fino alla versione 1.56.1 ed è valutata CVSS 9.8. Il problema risiede nella funzione handle_file_upload(), dove la validazione dei tipi di file può essere aggirata attraverso una configurazione artefatta del campo di upload. Per sfruttarla il sito deve utilizzare un modulo contenente contemporaneamente un campo File Upload e un campo Select. L’attaccante non autenticato può quindi forgiare la configurazione inviata al gestore pubblico del form e caricare file arbitrari, compresi payload PHP. Wordfence precisa che la configurazione standard protegge normalmente la directory di upload attraverso .htaccess, impedendo l’esecuzione PHP; il rischio RCE diventa concreto soprattutto quando l’amministratore ha configurato una Custom File Upload Storage root che non possiede la stessa protezione. La vulnerabilità è stata corretta in Forminator 1.56.2, rilasciato il 31 luglio. La falla arriva dopo una sequenza particolarmente intensa di exploit WordPress capaci di portare dalla superficie Web alla code execution e conferma il rischio rappresentato dai plugin molto diffusi quando un endpoint pubblico di upload permette di superare i controlli sui file.

Tre falle diverse convergono sulla fiducia concessa all’automazione

GitLab, Snowflake e Forminator non condividono la stessa vulnerabilità, ma mostrano lo stesso problema architetturale: un componente progettato per automatizzare un’operazione legittima riceve input controllabile dall’esterno e gli concede più fiducia del necessario. GitLab permette a GraphQL di modificare dati attraverso una direttiva non sufficientemente vincolata; il workflow Snowflake inseriva il titolo di una issue pubblica direttamente in una shell che disponeva di credenziali Jira; Forminator consentiva a dati forniti attraverso un modulo pubblico di influenzare la configurazione dell’upload. La risposta operativa è già disponibile in tutti e tre i casi: aggiornare immediatamente le installazioni GitLab self-managed, considerare corretta la pipeline Snowflake ma verificare pattern analoghi nei propri GitHub Actions e portare Forminator almeno alla 1.56.2. Per gli amministratori WordPress resta particolarmente utile anche riesaminare le precedenti vulnerabilità critiche che hanno interessato plugin e componenti del CMS, perché la sola applicazione della patch non sostituisce l’inventario delle estensioni e delle configurazioni che espongono funzionalità sensibili direttamente a Internet.