Critica vulnerabilità GraphQL di GitLab CVE-2026-19478 sfruttata attivamente

Marcus Chen Staff Engineer (Backend & Cloud), YuSMP Group · Sicurezza delle infrastrutture, architettura cloud-native e toolchain DevOps per team statunitensi ed europei

In sintesi

Cos’è successo

17 agosto 2026. GitLab ha pubblicato una release di sicurezza di emergenza che corregge due vulnerabilità scoperte durante un audit interno. La falla principale, CVE-2026-19478, ha un punteggio base CVSS v3.1 di 9,4 (Critico). Una seconda vulnerabilità ad alta severità, CVE-2026-19650, è stata corretta nella stessa release. GitLab ha scelto di rilasciare la patch al di fuori del normale ciclo bimensile, segnale che adotta un approccio out-of-band per le falle critiche con bassa complessità di attacco e senza requisiti di autenticazione.

Le versioni corrette — 19.2.4, 19.1.6, 19.0.8 e 18.11.11 — non contengono nuove migrazioni del database. GitLab ha dichiarato che i deployment multi-nodo in alta disponibilità possono applicare l’aggiornamento senza richiedere downtime, eliminando la normale frizione legata alle finestre di aggiornamento. I team Cloud e DevOps che eseguono GitLab su Kubernetes o dietro load balancer possono applicare l’aggiornamento con un normale rolling restart.

19 agosto 2026. SecurityWeek ha riportato che la rete honeypot globale di WatchTowr Labs ha iniziato a rilevare tentativi di sfruttamento attivo di CVE-2026-19478 circa 48 ore dopo il rilascio della patch. Gli attaccanti sono passati dal proof-of-concept alla scansione attiva in meno di due giorni — in linea con il tipico ciclo di sfruttamento dei CVE ad alto profilo nelle toolchain DevOps.

Come funziona la vulnerabilità

CVE-2026-19478 origina nel modo in cui l’API GraphQL di GitLab elabora una specifica direttiva interna. Le direttive GraphQL sono annotazioni speciali che modificano il comportamento di esecuzione delle query; GitLab utilizza diverse direttive personalizzate nel proprio layer API. La falla consente a una richiesta GraphQL artefatta di iniettare un’operazione tramite una direttiva in modo che il server la esegua senza verificare l’identità o i permessi del chiamante rispetto alla risorsa target.

La conseguenza pratica è immediata: un attaccante che invia il payload GraphQL corretto all’endpoint /api/graphql su un’istanza vulnerabile può innescare operazioni di eliminazione o modifica su qualsiasi progetto pubblico — rimuovendo repository, issue, merge request e artefatti associati. L’attacco non richiede credenziali, utilizza una singola richiesta HTTPS e ha bassa complessità, il che lo rende banalmente scriptabile e adatto alla scansione automatizzata di massa.

L’analisi di OX Security della falla companion CVE-2026-19650 evidenzia che entrambe le vulnerabilità condividono la stessa superficie di esecuzione GraphQL, suggerendo che le due problematiche potrebbero essere varianti di un unico problema di progettazione nel modo in cui GitLab convalida le operazioni con scope di direttiva. GitLab non ha confermato pubblicamente questa relazione, ma il pattern è coerente con un gap di validazione dell’input a livello di direttiva piuttosto che con un bug isolato.

Le linee guida di rilevamento pubblicate da WatchTowr consigliano agli amministratori di cercare nei log web le richieste contenenti la stringa @gl_introduced come indicatore di attività di probe. Questa stringa compare nei payload di sfruttamento noti e nelle query Shodan utilizzate dagli attori delle minacce per enumerare le istanze esposte.

Sfruttamento attivo: cosa ha rilevato l’honeypot

WatchTowr gestisce una rete honeypot distribuita che emula servizi di livello production su più regioni geografiche. Instrumenta specificamente le istanze GitLab a diverse versioni per catturare il traffico di sfruttamento reale non appena il codice proof-of-concept circola. Per CVE-2026-19478, i primi probe hanno raggiunto la telemetria di WatchTowr entro 48 ore dalla patch — tra i più rapidi tempi di sfruttamento osservati dalla società per una vulnerabilità GitLab.

Il pattern iniziale del traffico è coerente con la scansione automatizzata di massa: richieste ad alta frequenza da IP distribuiti, che puntano all’endpoint /api/graphql con un numero ridotto di varianti di payload. Questa è l’impronta digitale di toolkit costruiti attorno al proof-of-concept pubblico piuttosto che di attacchi manuali mirati. L’implicazione per le istanze non aggiornate è significativa: qualsiasi istanza GitLab raggiungibile pubblicamente è già sotto probe e il passo dall’esplorazione all’eliminazione è banale una volta che un attaccante identifica un target vulnerabile.

Cosa significa per i team di sviluppo

GitLab self-managed è un’infrastruttura ad alto valore, non uno strumento periferico. Le istanze GitLab CE e EE tipicamente ospitano tutto il codice sorgente, la configurazione delle pipeline CI/CD, i token di accesso ai provider cloud e i segreti di deployment memorizzati nelle variabili CI protette. La perdita di un repository per eliminazione è dirompente; la perdita di segreti delle variabili CI per esfiltrazione — se dovesse emergere una variante più mirata di questa classe di exploit — costituisce un incidente alla supply chain. La superficie di attacco è l’intera pipeline di delivery del software, non solo l’interfaccia del repository.

I progetti pubblici sono il punto di ingresso, ma il raggio d’azione può estendersi ulteriormente. CVE-2026-19478 prende di mira specificamente le risorse pubbliche, ma in molti deployment GitLab enterprise i progetti pubblici condividono uno spazio di nomi con quelli privati, e gli stessi runner CI elaborano job per entrambi. A seconda di come un team ha definito lo scope delle credenziali dei runner e dei segreti a livello di progetto, un punto d’appoggio acquisito attraverso un progetto pubblico potrebbe consentire movimento laterale. I team che eseguono configurazioni miste di progetti pubblici e privati dovrebbero rivedere le impostazioni di isolamento dei runner insieme alla patch.

Gli utenti di GitLab.com (SaaS) non sono interessati e non devono intraprendere alcuna azione. La vulnerabilità è specifica ai deployment self-managed di Community Edition ed Enterprise Edition. I team su GitLab.com possono verificare il proprio modello di hosting tramite l’URL dell’istanza: se l’URL è gitlab.com, si trovano sul prodotto SaaS. Se l’URL punta a un dominio aziendale, si tratta di un deployment self-managed che deve essere aggiornato.

I team europei devono fare i conti con una scadenza di conformità più stringente. Ai sensi del DORA (Digital Operational Resilience Act), le entità del settore finanziario nell’UE sono tenute a documentare le vulnerabilità ICT e a dimostrare che le patch critiche vengono applicate entro tempi coerenti con la propria propensione al rischio. Un CVE con CVSS 9,4 attivamente sfruttato in un sistema classificato come infrastruttura ICT critica non è una questione da rinviare al prossimo sprint. I responsabili della conformità dovrebbero trattare il timestamp della patch come un evento operativo rilevante ai fini DORA e documentarlo di conseguenza.

Per i team italiani, questa vulnerabilità assume rilevanza immediata su più fronti. L’ACN (Agenzia per la Cybersicurezza Nazionale) classifica le falle con CVSS ≥ 9,0 tra le priorità assolute di intervento e ha emanato specifiche linee guida sulla sicurezza delle piattaforme DevOps e dei sistemi CI/CD. Il D.Lgs. 138/2024, che recepisce la Direttiva NIS2 in Italia (vigente dal 16 ottobre 2024), obbliga i soggetti essenziali e importanti a notificare all’ACN incidenti significativi entro 24 ore dalla presa di conoscenza: un’istanza GitLab self-managed compromessa che ospita il codice sorgente di sistemi critici rientra pienamente in questa fattispecie. Le aziende del settore finanziario e bancario, soggette anche alla vigilanza di Banca d’Italia, devono inoltre trattare questa patch come un evento ICT da registrare nel proprio framework di gestione del rischio tecnologico ai sensi delle disposizioni EBA e BCE in materia di operational resilience.

Cosa fare adesso

FAQ