GitLab ha corretto una vulnerabilità critica con punteggio CVSS 9.4 che, in determinate condizioni, può permettere a un aggressore non autenticato di modificare o cancellare progetti pubblici e dati degli utenti tramite GraphQL. Chi utilizza un’installazione GitLab self-managed deve aggiornare immediatamente: GitLab.com e GitLab Dedicated risultano già protetti.
GitLab ha pubblicato il 17 agosto 2026 un aggiornamento di sicurezza urgente per correggere CVE-2026-19478, una vulnerabilità critica che interessa GitLab Community Edition ed Enterprise Edition.
La falla riguarda una code injection attraverso una direttiva GraphQL e, secondo GitLab, può essere sfruttata da remoto senza autenticazione e senza alcuna interazione da parte della vittima.
Il rischio più grave è concreto: in determinate condizioni un aggressore può modificare o cancellare progetti pubblici e dati degli utenti.
Per chi gestisce un server GitLab autonomamente, quindi, questo non è un aggiornamento da rimandare.
CVE-2026-19478: cosa può fare un attaccante
GitLab descrive CVE-2026-19478 come una vulnerabilità di code injection tramite GraphQL directive.
L’azienda non ha ancora pubblicato tutti i dettagli tecnici dell’attacco. Come avviene normalmente per le proprie vulnerabilità di sicurezza, GitLab prevede di rendere pubblico il relativo issue tracker circa 90 giorni dopo la patch, dando agli amministratori il tempo necessario per aggiornare.
Quello che sappiamo è già sufficiente a giustificare la classificazione Critical.
Il vettore CVSS pubblicato da GitLab indica:
- attacco eseguibile da remoto tramite rete;
- nessun account necessario;
- bassa complessità dell’attacco;
- nessuna azione richiesta alla vittima;
- impatto elevato su integrità e disponibilità dei dati.
Il punteggio complessivo è CVSS 9.4 su 10.
In pratica, non stiamo parlando semplicemente della possibilità di visualizzare qualche informazione riservata.
La vulnerabilità può permettere di alterare o eliminare contenuti.
Quali versioni di GitLab sono vulnerabili
La falla interessa sia GitLab CE sia GitLab EE, ma non tutte le versioni.
| Versione GitLab | Vulnerabile | Versione corretta |
|---|---|---|
| 18.2 fino a 18.11.10 | Sì | 18.11.11 |
| 19.0 fino a 19.0.7 | Sì | 19.0.8 |
| 19.1 fino a 19.1.5 | Sì | 19.1.6 |
| 19.2 fino a 19.2.3 | Sì | 19.2.4 |
GitLab raccomanda a tutte le installazioni self-managed interessate di passare immediatamente a una versione corretta.
Le patch disponibili sono quindi:
- GitLab 18.11.11
- GitLab 19.0.8
- GitLab 19.1.6
- GitLab 19.2.4
Se stai utilizzando una delle versioni precedenti indicate nella tabella, la priorità dovrebbe essere l’aggiornamento.
GitLab.com è vulnerabile?
No, almeno per quanto riguarda questa vulnerabilità.
GitLab conferma che GitLab.com e GitLab Dedicated stanno già utilizzando una versione corretta e i clienti di questi servizi non devono eseguire operazioni specifiche.
Il problema riguarda soprattutto chi utilizza GitLab self-managed, quindi installazioni ospitate su server propri, VPS, cloud privati o infrastrutture aziendali.
È proprio uno dei motivi per cui la gestione di software self-hosted richiede particolare attenzione agli aggiornamenti di sicurezza.
Tech iCrewPlay aveva già seguito un precedente rilascio GitLab che correggeva 13 vulnerabilità di sicurezza, compresa una falla critica legata alle pipeline CI/CD.
CVE-2026-19478 è però diversa perché non richiede autenticazione.
Come controllare quale versione di GitLab stai usando
Prima di tutto bisogna capire se l’installazione rientra tra quelle interessate.
Su una normale istanza GitLab è possibile verificare la versione dall’interfaccia amministrativa oppure dal server.
Con un’installazione Linux self-managed, uno dei metodi più comuni è controllare la versione del pacchetto GitLab installato.
L’obiettivo non è semplicemente verificare di avere “GitLab 19”, perché anche alcune versioni recentissime della serie 19 sono vulnerabili.
Devi confrontare il numero completo.
Se utilizzi:
- 18.11.10 o precedente, aggiorna almeno a 18.11.11;
- 19.0.7 o precedente, aggiorna almeno a 19.0.8;
- 19.1.5 o precedente, aggiorna almeno a 19.1.6;
- 19.2.3 o precedente, aggiorna almeno a 19.2.4.
GitLab consiglia comunque di installare l’ultima patch disponibile per il ramo supportato, non soltanto il minimo necessario per correggere questa CVE.
Come aggiornare GitLab
La procedura dipende da come è stata installata la piattaforma.
GitLab specifica che la vulnerabilità interessa le diverse tipologie di deployment quando non diversamente indicato, quindi non bisogna considerare sicura un’installazione soltanto perché utilizza Docker, Helm o un pacchetto specifico.
Prima dell’aggiornamento è consigliabile:
- verificare la versione attualmente installata;
- controllare lo stato dei backup;
- verificare eventuali requisiti di upgrade intermedi;
- programmare l’aggiornamento il prima possibile;
- controllare il corretto funzionamento dell’istanza dopo la patch.
GitLab segnala che queste versioni non introducono nuove migrazioni e, nelle configurazioni multi-node, normalmente non dovrebbero richiedere downtime.
Le installazioni Omnibus possono comunque arrestare e riavviare i servizi durante la procedura di aggiornamento.
Aggiornare basta?
Aggiornare è la prima cosa da fare, ma su un’istanza GitLab esposta a Internet io non mi fermerei lì.
Dopo aver applicato la patch conviene verificare che non siano avvenute attività anomale prima dell’aggiornamento.
In particolare controllerei:
- progetti pubblici modificati o eliminati senza spiegazione;
- modifiche inattese a repository, issue o dati utente;
- attività GraphQL insolite nei log;
- richieste provenienti da IP sconosciuti;
- modifiche di permessi o configurazioni;
- creazione o rimozione anomala di risorse;
- errori GraphQL ripetuti immediatamente prima della patch.
Questo non significa che un sistema vulnerabile sia stato automaticamente compromesso.
Serve semplicemente a verificare se esistano indicatori compatibili con un possibile abuso.
Al momento GitLab non indica pubblicamente nella propria advisory uno sfruttamento attivo della vulnerabilità. Per questo eviterei di parlare di attacchi già in corso finché non emergono prove affidabili.
Perché una falla GraphQL può essere così grave
GraphQL è un sistema utilizzato dalle applicazioni per interrogare e modificare dati attraverso API strutturate.
In condizioni normali, il server deve controllare attentamente:
- cosa può essere richiesto;
- quali operazioni sono consentite;
- chi può eseguirle;
- quali dati possono essere modificati.
Se un meccanismo GraphQL permette di alterare il comportamento previsto o di eseguire operazioni che dovrebbero essere bloccate, il problema può diventare molto serio.
Nel caso di CVE-2026-19478, GitLab parla esplicitamente di code injection attraverso una direttiva GraphQL.
Non sono ancora disponibili pubblicamente abbastanza dettagli per descrivere in sicurezza la catena tecnica completa dell’exploit, ed è meglio così: pubblicare istruzioni operative prima che la maggioranza degli amministratori abbia aggiornato aumenterebbe il rischio di abuso.
C’è anche una seconda vulnerabilità GraphQL
La patch urgente non risolve soltanto CVE-2026-19478.
GitLab ha corretto anche CVE-2026-19650, classificata High con CVSS 7.1.
In questo caso il problema riguarda una gestione impropria delle richieste GraphQL multiplex che, in determinate condizioni, poteva consentire l’esecuzione di mutazioni GraphQL tramite richieste GET.
Anche questa vulnerabilità interessa gli stessi rami:
- 18.2 prima della 18.11.11;
- 19.0 prima della 19.0.8;
- 19.1 prima della 19.1.6;
- 19.2 prima della 19.2.4.
Questo rende l’aggiornamento ancora più importante.
Perché GitLab ha pubblicato una patch straordinaria
GitLab normalmente pubblica gli aggiornamenti di sicurezza programmati due volte al mese, il secondo e il quarto mercoledì.
Questa volta ha invece rilasciato una critical patch ad hoc, proprio perché la vulnerabilità è considerata sufficientemente grave da non attendere il ciclo ordinario.
È un segnale da non sottovalutare.
Quando un produttore interrompe il proprio calendario normale per distribuire una correzione critica, gli amministratori dovrebbero trattarla con priorità elevata.
Su Tech abbiamo già visto casi analoghi con vulnerabilità critiche come quella che ha interessato Microsoft SharePoint, dove ritardare l’installazione delle patch può ampliare rapidamente la finestra disponibile agli aggressori.
Cosa fare subito se gestisci GitLab
Se utilizzi una normale utenza su GitLab.com, non devi fare nulla.
Se invece amministri un’istanza GitLab self-managed, la sequenza più sensata è questa:
- Controlla immediatamente la versione installata.
- Verifica se rientra tra quelle vulnerabili.
- Esegui un backup secondo le procedure previste dalla tua infrastruttura.
- Aggiorna almeno a 18.11.11, 19.0.8, 19.1.6 o 19.2.4, in base al ramo utilizzato.
- Controlla log e attività recenti.
- Verifica che progetti pubblici e dati degli utenti non abbiano subito modifiche inattese.
- Mantieni monitorata l’advisory ufficiale GitLab per eventuali nuove informazioni.
L’advisory ufficiale di GitLab raccomanda esplicitamente di installare la patch il prima possibile.
CVE-2026-19478 è grave soprattutto perché non richiede login
Il punteggio 9.4 non deriva soltanto dal tipo di vulnerabilità.
La combinazione è ciò che rende CVE-2026-19478 particolarmente problematica:
attacco remoto, nessuna autenticazione, nessuna interazione dell’utente e possibilità di modificare o cancellare dati.
Per una piattaforma che può contenere repository, documentazione, issue e interi progetti software, l’impatto potenziale è evidente.
Non sappiamo ancora tutti i dettagli tecnici e non abbiamo al momento conferma ufficiale di sfruttamento attivo.
Ma questo non cambia la raccomandazione.
Se gestisci un GitLab self-managed vulnerabile, aggiorna adesso.
Aspettare la pubblicazione di un proof-of-concept o la comparsa dei primi attacchi sarebbe esattamente il contrario di ciò che una patch critica pubblicata in anticipo permette di fare.
