GitLab ha corretto una vulnerabilità critica nell’AI Gateway che, in determinate condizioni, poteva consentire a un utente autenticato con accesso a Duo Agent Platform di eseguire comandi sul gateway. Il problema, identificato come CVE-2026-90970, ha un punteggio CVSS di 9,9 su 10.
L’intervento riguarda soltanto le organizzazioni che ospitano autonomamente il gateway usato per collegare un’istanza GitLab ai modelli di intelligenza artificiale. GitLab indica di aggiornare subito alle versioni 19.2.4, 19.3.2 o 19.4.1; i clienti che usano un gateway gestito da GitLab non devono invece intervenire.
Che cosa consente la vulnerabilità
La falla risiede nel modello di prompt di un custom flow, cioè un flusso di lavoro basato sull’AI che gli utenti possono creare in Duo Agent Platform per automatizzare attività composte da più passaggi.
Secondo quanto riportato nell’avviso, un utente autenticato con accesso alla piattaforma avrebbe potuto usare una configurazione di flusso appositamente costruita per uscire dalla sandbox del template. L’effetto possibile era l’esecuzione arbitraria di comandi sul gateway.
Non sono stati precisati né ulteriori requisiti dell’attacco né uno specifico ruolo utente oltre all’accesso a Duo Agent Platform. L’avviso non segnala inoltre se la vulnerabilità sia stata sfruttata in attacchi reali. Il 2 ottobre CISA ha indicato nel record della CVE che non risultava sfruttamento.
Chi deve aggiornare e chi non deve fare nulla
Il perimetro è circoscritto ai gateway self-hosted. Questa configurazione permette alle organizzazioni di mantenere nel proprio ambiente le richieste e le risposte AI, ma richiede anche di gestire direttamente l’aggiornamento del componente.
GitLab afferma di avere già aggiornato i gateway che gestisce per i clienti. Non devono agire gli utenti di GitLab.com, GitLab Dedicated e delle istanze self-managed che utilizzano un gateway ospitato da GitLab.
Chi gestisce in proprio l’AI Gateway deve invece passare a una release corretta: 19.2.4, 19.3.2 o 19.4.1. Le versioni del gateway sono separate da quelle dell’istanza GitLab e il componente viene distribuito come immagine Docker o chart Helm, con una propria procedura di aggiornamento.
Versioni coinvolte e punti ancora aperti
Non è indicata alcuna versione corretta precedente alla 19.2.4. Di conseguenza, risultano interessate le release dell’AI Gateway dalla 18.1.6 fino alla linea 19.1.
La documentazione di installazione invita in genere ad abbinare l’immagine del gateway alla stessa versione minore di GitLab. L’avviso non chiarisce però se un gateway 19.2.4 sia compatibile con GitLab 19.1 o con release precedenti, né se arriveranno correzioni per quei rami.
L’avviso non indica workaround per i gateway che non possono essere aggiornati subito. Manca anche un metodo indicato per verificare se un gateway sia stato compromesso prima dell’installazione della patch.
Perché il gateway è un componente sensibile
L’AI Gateway non è un semplice passaggio tecnico tra utente e modello: comunica sia con l’istanza GitLab sia con i fornitori dei modelli AI dell’organizzazione. In una configurazione self-hosted conserva inoltre chiavi di firma per JSON Web Token, che la guida di installazione considera credenziali sensibili.
Un’esecuzione di comandi sul gateway può quindi interessare un sistema collocato nel percorso delle richieste AI e dotato di materiali di autenticazione. È questo il punto che rende prioritaria l’installazione dell’aggiornamento per chi rientra nel perimetro interessato.
Domande frequenti
Quali versioni risolvono CVE-2026-90970?
GitLab ha corretto il problema nelle versioni AI Gateway 19.2.4, 19.3.2 e 19.4.1.
GitLab.com è coinvolto?
No. GitLab ha dichiarato di avere già corretto i gateway che ospita: GitLab.com, GitLab Dedicated e le istanze self-managed con gateway gestito da GitLab non richiedono un’azione del cliente.
Esiste una mitigazione alternativa all’aggiornamento?
L’avviso non elenca workaround per i gateway self-hosted che non possono ancora essere aggiornati.
Considerazioni finali
La distinzione tra gateway gestito e self-hosted è decisiva: evita di trasformare una vulnerabilità critica in un allarme indistinto per tutti gli utenti GitLab, ma lascia un compito urgente agli amministratori che hanno scelto di mantenere questo componente nel proprio ambiente.
Il fatto che l’avviso non indichi workaround, insieme alla mancanza di indicazioni per ricostruire eventuali compromissioni precedenti, rende l’aggiornamento la misura concreta che pesa di più, soprattutto perché il gateway gestisce connessioni AI e credenziali di firma sensibili.