GitLab corregge una falla critica GraphQL che può alterare o cancellare progetti

Una vulnerabilità critica nelle istanze self-managed

GitLab ha pubblicato il 17 agosto 2026 un aggiornamento di sicurezza straordinario, cinque giorni dopo il precedente rilascio ordinario. Il pacchetto corregge due vulnerabilità nelle edizioni Community Edition (CE) ed Enterprise Edition (EE), con impatto diverso ma entrambe legate all’uso di GraphQL.

La più grave è CVE-2026-19478, classificata da GitLab come Critical con punteggio CVSS 9.4. In determinate condizioni, un attaccante remoto non autenticato potrebbe modificare o cancellare progetti pubblici e dati degli utenti attraverso una direttiva GraphQL.

L’azienda non ha reso noto quale direttiva sia coinvolta né quali condizioni debbano verificarsi perché l’attacco abbia successo. Il vettore CVSS, tuttavia, indica un attacco eseguibile via rete, senza credenziali e senza interazione da parte della vittima:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:H

Il punteggio riflette soprattutto l’impatto sull’integrità e sulla disponibilità dei dati. La componente di riservatezza è invece valutata più contenuta.

Al 18 agosto 2026, GitLab non ha segnalato sfruttamenti della vulnerabilità. Non risultava inoltre disponibile su GitHub codice exploit pubblico riferibile a CVE-2026-19478. Non è noto se la falla sia stata inserita nel catalogo Known Exploited Vulnerabilities (KEV) della CISA.

Il secondo problema riguarda le mutation GraphQL via GET

Il secondo difetto è CVE-2026-19650, classificato High e valutato CVSS 7.1:

CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:L

La vulnerabilità consiste in una debolezza di tipo Cross-Site Request Forgery (CSRF) nel gestore delle query GraphQL multiplex. In specifiche condizioni, una validazione insufficiente delle richieste avrebbe potuto permettere a un utente non autenticato di eseguire operazioni di modifica, dette mutation, usando richieste HTTP GET.

A differenza della falla critica, questo scenario richiede l’interazione dell’utente. La vittima dovrebbe quindi compiere un’azione che consenta alla richiesta preparata dall’attaccante di essere elaborata dall’istanza GitLab.

Il problema non equivale automaticamente a un accesso completo al server. Il rischio riguarda però l’esecuzione non autorizzata di operazioni che modificano dati, con possibili conseguenze su progetti, configurazioni e risorse gestite dalla piattaforma. GitLab non ha pubblicato dettagli sufficienti per ricostruire con precisione il flusso di attacco.

Le versioni vulnerabili e quelle corrette

Le correzioni sono state pubblicate nelle versioni:

• 19.2.4
• 19.1.6
• 19.0.8
• 18.11.11

Sono vulnerabili:

• tutte le versioni 18.2 precedenti alla 18.11.11;
• le versioni 19.0 precedenti alla 19.0.8;
• le versioni 19.1 precedenti alla 19.1.6;
• le versioni 19.2 precedenti alla 19.2.4.

Gli operatori che utilizzano i rami dalla 18.2 alla 18.10 non ricevono una correzione estesa a quei rami e devono pianificare l’aggiornamento verso una versione supportata e corretta. Le versioni esatte installate possono essere verificate dalla pagina di amministrazione dell’istanza o tramite gli strumenti di gestione del pacchetto adottato.

L’intervento riguarda esclusivamente le installazioni self-managed. GitLab.com e GitLab Dedicated utilizzano già versioni corrette: per questi servizi i clienti non devono applicare aggiornamenti manuali.

L’aggiornamento non introduce nuove migrazioni e, nelle installazioni multi-node, non dovrebbe richiedere un periodo di indisponibilità. Restano comunque necessarie le verifiche operative abituali, soprattutto in ambienti con nodi distribuiti, proxy o componenti GraphQL esposti attraverso infrastrutture personalizzate.

Cosa devono fare gli amministratori

La mitigazione indicata da GitLab è l’aggiornamento a una delle quattro versioni corrette. Non sono state comunicate misure alternative equivalenti, come la disattivazione temporanea di una specifica direttiva GraphQL o una regola WAF sufficiente a bloccare entrambi i problemi.

Gli amministratori dovrebbero quindi:

1. verificare la versione dell’istanza self-managed;
2. aggiornarla a 19.2.4, 19.1.6, 19.0.8 o 18.11.11;
3. controllare i log applicativi e di accesso per richieste GraphQL anomale;
4. esaminare modifiche inattese a progetti pubblici, repository, issue, configurazioni e dati degli utenti;
5. verificare eventuali richieste GET insolite associate a operazioni GraphQL con effetti di modifica.

Il brief non indica indicatori di compromissione specifici, nomi di campagne o pattern di rete già osservati. I log, quindi, non permettono necessariamente di distinguere un tentativo riuscito da un’attività legittima senza correlare URL, identità, tempi e modifiche effettuate.

Le organizzazioni che non possono aggiornare immediatamente dovrebbero ridurre l’esposizione dell’istanza, limitando l’accesso dall’esterno secondo le proprie esigenze operative. Questa misura non è però una sostituzione della patch e non garantisce la protezione se l’istanza deve restare raggiungibile da reti non fidate.

Divulgazione tecnica attesa nei prossimi mesi

GitLab ha dichiarato di pubblicare sul proprio issue tracker i dettagli delle vulnerabilità 90 giorni dopo il rilascio della correzione. Per questi due problemi, la divulgazione tecnica è quindi attesa intorno alla metà di novembre 2026.

La tempistica non è del tutto coerente con una precedente comunicazione del 10 giugno 2026, che indicava una finestra di 30 giorni. Fino alla pubblicazione dei dettagli, restano sconosciuti la direttiva GraphQL coinvolta nella falla critica, i prerequisiti completi per lo sfruttamento e le modalità con cui la validazione delle richieste GET può essere aggirata.

L’episodio arriva dopo un report di luglio 2026 su una diversa vulnerabilità di GitLab. In quel caso, i ricercatori avevano pubblicato codice exploit funzionante contro server self-managed. La società non ha risposto immediatamente a una richiesta di commento su questo nuovo aggiornamento.

Per gli amministratori, la priorità non cambia: identificare le istanze che rientrano negli intervalli vulnerabili e portarle rapidamente a una versione corretta, senza attendere la futura pubblicazione dei dettagli tecnici.