GitLab, CVE-2026-19478 sfruttata attivamente pochi giorni dopo la divulgazione

La vulnerabilità CVE-2026-19478 di GitLab è stata osservata in attività reali pochi giorni dopo la sua divulgazione pubblica. La rilevazione risale al 21 agosto 2026 e arriva da watchTowr, che ha individuato tentativi contro la propria rete di honeypot.

La società ha dichiarato di aver riprodotto il problema pochi minuti dopo la divulgazione. Il difetto consente a un attaccante remoto e non autenticato di intervenire su progetti GitLab pubblicamente accessibili, senza credenziali e senza interazione da parte degli utenti.

Una code injection attraverso GraphQL

La falla riguarda una direttiva GraphQL e viene classificata come code injection, con riferimento a CWE-94. In determinate condizioni, una richiesta appositamente costruita può permettere di modificare o cancellare progetti e dati associati.

La descrizione pubblicata da NVD conferma che l’attacco può essere eseguito da remoto contro progetti pubblici e dati degli utenti. Non sono richiesti privilegi preliminari, mentre la complessità dell’attacco è considerata bassa.

Il vettore CVSS v3 è pari a 9.4:

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

La riservatezza è valutata con impatto basso, ma integrità e disponibilità risultano fortemente compromesse. In pratica, l’attaccante potrebbe alterare contenuti e configurazioni oppure rendere indisponibili componenti essenziali dei progetti.

Repository cancellati e merge falsificati

Secondo watchTowr, le conseguenze non si limitano alla modifica di singoli dati. Uno sfruttamento riuscito può includere:

• cancellazione di interi repository;
• alterazione dei dati dei progetti;
• falsificazione dei record di merge;
• esclusione o blocco dei maintainer;
• apparente integrazione di una correzione mai realmente applicata.

La falsificazione dei record di merge è particolarmente delicata perché può compromettere la fiducia nei processi di sviluppo. Un progetto potrebbe mostrare una modifica come già integrata, mentre il codice corretto non è stato effettivamente applicato o verificato.

Il problema riguarda soprattutto le istanze esposte a Internet con repository pubblici e funzionalità GraphQL raggiungibili dall’esterno. Non è stato indicato un gruppo criminale responsabile degli attacchi osservati.

Versioni GitLab interessate

Sono vulnerabili entrambe le edizioni GitLab Community Edition (CE) ed Enterprise Edition (EE).

Le versioni coinvolte sono:

• ramo 18.2, nelle release precedenti a 18.11.11;
• ramo 19.0, nelle release precedenti a 19.0.8;
• ramo 19.1, nelle release precedenti a 19.1.6;
• ramo 19.2, nelle release precedenti a 19.2.4.

GitLab ha corretto il difetto nelle versioni:

• 18.11.11;
• 19.0.8;
• 19.1.6;
• 19.2.4.

Gli amministratori devono verificare il ramo in uso e applicare la release corretta, senza limitarsi a controllare il numero principale della versione. Un’istanza aggiornata a una release precedente alla correzione resta esposta.

La velocità dello sfruttamento riduce il margine operativo

La sequenza osservata da watchTowr mostra un intervallo molto breve tra divulgazione e attività di sfruttamento. Jake Knott, principal security researcher della società, ha collegato questa rapidità all’uso di strumenti e processi abilitati dall’intelligenza artificiale.

Si tratta di un’osservazione sull’accelerazione delle attività offensive, non dell’attribuzione a uno specifico attore. Il punto operativo è però chiaro: dopo la pubblicazione dei dettagli tecnici, la finestra disponibile per aggiornare i sistemi può essere molto ridotta.

La vulnerabilità non risulta indicata, nelle informazioni disponibili, come inclusa nel catalogo CISA KEV. Non è quindi disponibile una relativa scadenza CISA. L’assenza dal catalogo non riduce tuttavia la priorità dell’intervento: lo sfruttamento in-the-wild è stato osservato direttamente da watchTowr.

Aggiornare GitLab e controllare i log

La misura principale consiste nell’aggiornare le istanze CE o EE alle versioni corrette: 18.11.11, 19.0.8, 19.1.6 oppure 19.2.4, in base al ramo installato.

Se l’aggiornamento immediato non è possibile, GitLab raccomanda di adottare una delle seguenti mitigazioni:

• limitare l’accesso non autenticato all’endpoint /api/graphql;
• rimuovere completamente l’accesso ai repository pubblici.

Queste misure riducono la superficie esposta, ma non sostituiscono la correzione del software. Dopo l’aggiornamento, è opportuno verificare che le restrizioni temporanee siano state rimosse solo quando il rischio è effettivamente rientrato.

Le organizzazioni che non hanno ancora applicato le patch dovrebbero esaminare i log web cercando richieste contenenti:

@gl_introduced

Il controllo deve includere anche indicatori di scansione, probing e tentativi di sfruttamento. Vanno confrontati i cambiamenti recenti a repository, dati di progetto, record di merge e permessi dei maintainer.

Alterazioni non autorizzate, repository scomparsi, maintainer rimossi o merge inattesi richiedono una verifica degli account coinvolti, dei log applicativi e delle copie di backup. In presenza di modifiche sospette, non è sufficiente ripristinare il repository: bisogna controllare anche metadati, autorizzazioni e cronologia delle operazioni.