// TOM'S HARDWARE ITALIA — CYBERSECURITY
GitLab, falla critica: progetti pubblici cancellabili senza login
Una direttiva GraphQL può consentire a un attaccante remoto di modificare o cancellare progetti pubblici e dati degli utenti su alcune installazioni GitLab. La vulnerabilità, identificata come CVE-2026-19478, è una code injection classificata critica con un punteggio CVSS di 9.4. In determinate condizioni può essere sfruttata senza autenticazione, senza interazione dell’utente e con una bassa complessità d’attacco.
GitLab ha distribuito il 17 agosto 2026 le versioni 19.2.4, 19.1.6, 19.0.8 e 18.11.11 per Community Edition ed Enterprise Edition. Sono vulnerabili tutte le release dalla 18.2 alla 18.11.10, oltre ai rami 19.0 precedenti alla 19.0.8, 19.1 precedenti alla 19.1.6 e 19.2 precedenti alla 19.2.4. Il problema riguarda le installazioni self-managed e mette a rischio l’integrità e la disponibilità dei contenuti accessibili pubblicamente.
Lo stesso aggiornamento corregge CVE-2026-19650, una vulnerabilità CSRF ad alta gravità con punteggio CVSS 7.1. Il difetto interessa la validazione delle richieste nel gestore delle query GraphQL multiplex e può permettere a un utente non autenticato di eseguire mutation attraverso richieste GET. In questo caso è però necessaria l’interazione della vittima, condizione che restringe il perimetro dell’attacco rispetto alla falla critica.
Entrambe le vulnerabilità coinvolgono tutte le tipologie di installazione self-managed, salvo indicazioni differenti del produttore. GitLab raccomanda quindi di applicare le patch immediatamente, seguendo la guida ufficiale all’aggiornamento per la modalità di distribuzione utilizzata. Gli amministratori devono installare la release corretta del proprio ramo, senza limitarsi a una versione intermedia ancora esposta.
GitLab.com e GitLab Dedicated utilizzano già versioni corrette, quindi i rispettivi clienti non devono eseguire interventi. Per le infrastrutture gestite direttamente, l’aggiornamento non introduce nuove migrazioni e, nelle configurazioni multi-nodo, non dovrebbe richiedere tempi di inattività. Questo consente di applicare la correzione senza le operazioni aggiuntive normalmente associate alle modifiche dello schema dei dati.
I dettagli tecnici completi delle due vulnerabilità non sono ancora pubblici. GitLab prevede di divulgarli nel proprio issue tracker 90 giorni dopo il rilascio delle patch, secondo la procedura indicata nel bollettino. Fino ad allora, il perimetro confermato resta quello descritto dal produttore: le istanze self-managed che eseguono una versione vulnerabile devono passare a una delle quattro release corrette.
Aggiungi Tom's Hardware alle tue fonti preferite su Google