GitLab rilascia patch d'emergenza per la vulnerabilità GraphQL non autenticata CVSS 9.4

Marcus Chen Staff Engineer (Backend & Cloud), YuSMP Group · Sicurezza backend, cloud e piattaforma per prodotti US ed EU

In sintesi

Cos'è CVE-2026-19478

L'API GraphQL di GitLab accetta payload di direttive che indicano al server come elaborare una query. Nelle versioni 18.2–19.2, una direttiva appositamente contraffatta può aggirare l'autorizzazione su mutazioni che scrivono o eliminano dati di progetti pubblici — senza alcuna credenziale. Il punteggio CVSS di 9.4 riflette tre fattori: l'attacco è raggiungibile via rete, non richiede autenticazione e non è necessaria alcuna interazione da parte della vittima.

L'ambito riguarda i progetti pubblici e i dati utente, non i repository privati protetti da autenticazione. Questa distinzione è rilevante per la prioritizzazione, ma non riduce l'urgenza per i team che ospitano progetti open source pubblici, demo per clienti o istanze con visibilità pubblica abilitata. La cronologia del codice, le issue, i file di configurazione CI e i metadati associati sono tutti scrivibili o eliminabili dall'attaccante non autenticato.

La vulnerabilità correlata CVE-2026-19650 sfrutta un meccanismo diverso: l'endpoint multiplex GraphQL di GitLab accetta più operazioni raggruppate in una singola richiesta, e la protezione CSRF non si applica quando le operazioni vengono trasmesse via HTTP GET. Un attaccante può creare un link o incorporare una richiesta su qualsiasi pagina visitata dal bersaglio, e il browser della vittima esegue una mutazione a suo nome. CVSS 7.1 riflette che è necessaria una qualche interazione dell'utente, ma l'impatto finale è identico a CVE-2026-19478.

Chi è interessato e cosa fare

La tabella seguente copre l'intero intervallo interessato e la correzione per ogni ramo:

Gli aggiornamenti zero-downtime sono supportati per i deployment GitLab multi-nodo, quindi gli ambienti di produzione con capacità di rolling upgrade possono patchare senza pianificare una finestra di manutenzione. Le istanze single-nodo richiederanno un breve riavvio. I percorsi di aggiornamento sono documentati nella guida di aggiornamento standard di GitLab.

Se il patching non è veramente possibile oggi (freeze delle modifiche, lungo processo di release), il controllo provvisorio consiste nel disabilitare la visibilità pubblica dei progetti a livello di istanza: Area amministrativa → Impostazioni → Generale → Visibilità e controlli di accesso → impostare la visibilità predefinita dei progetti su Privato e impedire ai membri di modificarla. È una misura d'emergenza dirompente, non un fix — aggiornare non appena la finestra si apre.

La lezione GraphQL per i propri prodotti

Entrambi i CVE condividono un pattern alla radice che vale la pena interiorizzare se il proprio team sviluppa API GraphQL: i controlli di autorizzazione e CSRF devono essere applicati al livello di esecuzione delle query, non solo al livello dei resolver o del middleware HTTP. L'elaborazione delle direttive in particolare è un percorso di esecuzione facile da sotto-testare, perché opera prima della logica del resolver e si trova al di fuori del modello mentale tipico che la maggior parte degli sviluppatori applica quando scrive test.

Se il proprio prodotto espone un'API GraphQL — specialmente una con accesso pubblico alle query — le domande immediate sono: la pipeline di elaborazione delle direttive applica l'autorizzazione? L'endpoint multiplex valida il CSRF per le operazioni che cambiano stato indipendentemente dal metodo HTTP? Non sono preoccupazioni esotiche; sono esattamente le lacune che hanno prodotto due CVE critici in una piattaforma di produzione utilizzata da centinaia di migliaia di organizzazioni. Un audit di sicurezza del livello API è il modo più affidabile per rispondere a queste domande prima che lo faccia un ricercatore esterno — o un attaccante.

Cosa significa per il mercato italiano

GitLab è la piattaforma CI/CD e di gestione del codice sorgente preferita da una grande quota dei team di ingegneria europei e americani di medie dimensioni, e in particolare per quelli che necessitano di un deployment on-premises o in cloud privato per ragioni di compliance o residenza dei dati. Questa preferenza è esattamente il motivo per cui una vulnerabilità scrittura/eliminazione senza autenticazione nell'API è un problema di ordine superiore: i team più propensi a gestire GitLab self-managed sono quelli con le ragioni più stringenti per proteggere ciò che contiene.

La priorità pratica: se l'istanza GitLab è esposta su Internet, è un'attività da completare nella stessa giornata. Se si trova dietro una VPN senza progetti pubblici, è comunque necessario patchare entro questo sprint — CVSS 9.4 non rimane nel backlog. Se un freeze delle modifiche blocca l'aggiornamento, applicare il blocco della visibilità pubblica descritto sopra e documentare il controllo compensativo nel registro dei rischi.

Cosa fare oggi

1. Trovare ogni istanza GitLab self-managed. Le installazioni GitLab non censite sono comuni nelle organizzazioni cresciute tramite acquisizioni o autonomia dei team. Non si può patchare ciò che non si conosce.
2. Verificare il numero di versione di ogni istanza. Area amministrativa → Aiuto o l'API GitLab GET /api/v4/version restituisce la versione corrente. Qualsiasi risultato compreso tra 18.2 e 19.2.3 (incluso) necessita del patch odierno.
3. Dare priorità alle istanze esposte su Internet. Qualsiasi GitLab accessibile da Internet o da un segmento di rete non controllato dalla propria organizzazione deve essere trattato come un'attività di aggiornamento P0.
4. Applicare la versione corretta per il proprio ramo. Seguire il percorso di aggiornamento documentato da GitLab per la versione corrente; non saltare versioni major. L'aggiornamento zero-downtime si applica ai setup multi-nodo.
5. Se il patching è bloccato, limitare la visibilità dei progetti pubblici. Area amministrativa → Impostazioni → Generale → Visibilità e controlli di accesso. Documentare questo come controllo compensativo temporaneo.
6. Esaminare i log di audit per attività GraphQL anomale. Verificare eliminazioni inattese, modifiche alle impostazioni dei progetti o mutazioni in massa su progetti pubblici nei giorni precedenti la scoperta di questo bollettino.
7. Verificare che l'aggiornamento sia andato a buon fine. Dopo l'upgrade, chiamare GET /api/v4/version e confermare che il numero di versione corrisponda alla versione corretta.

Domande frequenti

Fonti

GitLab — Patch Release: 19.2.4, 19.1.6, 19.0.8, 18.11.11, 17 agosto 2026 (fonte primaria)
IT-Boltwise — GitLab stopft kritische GraphQL-Schwachstelle (copertura indipendente)
CyberSecurityNews — GitLab Patches Critical Security Vulnerabilities