GitLab: falla critica 9.9 nell'AI Gateway self-hosted

Il fatto: CVSS 9,9 sul gateway che parla con i modelli

CVE-2026-90970 porta un punteggio CVSS di 9,9 su 10 e colpisce l'AI Gateway di GitLab. L'azienda l'ha divulgata il 2 ottobre 2026, con un advisory che la classifica come critica.

Il gateway è il servizio che collega un'istanza GitLab ai modelli AI. Secondo l'advisory ripreso da The Hacker News^[1], un utente già autenticato con accesso alla Duo Agent Platform può eseguire comandi sul gateway, in presenza di alcune condizioni.

Le versioni corrette sono tre: 19.2.4, 19.3.2 e 19.4.1. GitLab ha già aggiornato i gateway che gestisce in proprio. L'allarme riguarda chi ospita il gateway dentro la propria infrastruttura, e BleepingComputer^[2] lo ha ripreso come vulnerabilità critica di esecuzione remota di codice.

La compagnia ha avvisato quei clienti in forma diretta, prima di pubblicare il testo pubblico. La raccomandazione è aggiornare subito.

Chi deve agire, e chi risulta già coperto

L'elenco di chi può restare fermo è chiaro. GitLab.com, GitLab Dedicated e le istanze self-managed che usano un gateway ospitato da GitLab risultano già a posto, per dichiarazione dell'azienda.

Resta scoperto chi ha scelto l'altra strada. GitLab offre ai clienti self-managed la possibilità di ospitare il gateway in casa, così che richieste e risposte verso i modelli restino dentro il perimetro aziendale. Quella scelta nasce per ragioni di riservatezza dei dati.

Qui il conto si rovescia. Chi ha deciso di trattenere i dati AI dentro casa ora possiede anche il componente vulnerabile, il ciclo di patch e il rischio operativo. Il gateway arriva come immagine Docker o come chart Helm, con un percorso di aggiornamento separato da quello di GitLab.

Due team e due calendari convergono su un unico punto di esposizione.

Cosa bastava all'attaccante

La gravità di una falla si misura anche dall'elenco di ciò che manca fra i requisiti. Qui l'elenco è corto.

All'attaccante serve un account valido sull'istanza e l'accesso alla Duo Agent Platform. Serve inoltre che si verifichino certe condizioni, che l'advisory lascia volutamente generiche.

Fuori dall'elenco restano i privilegi di amministratore, una catena di exploit di terze parti e un intervento della vittima. Un punteggio 9,9 su una superficie raggiungibile da un utente interno autenticato descrive proprio questo: il salto dal piano applicativo al piano di esecuzione del gateway.

Il meccanismo tecnico esatto resta riservato, e la scelta è corretta. Conta la classe di problema: un componente nato per intermediare prompt e risposte apre una via verso l'esecuzione di comandi. Chi ha letto gli advisory del 2026 sui framework agentici riconosce il motivo ricorrente.

Le versioni corrette, e il vuoto sotto la 19.2.4

La tabella delle versioni merita lettura lenta, perché dice più della descrizione tecnica.

Chi usa un gateway dalla 18.1.6 in avanti, fino alla 19.2.4, deve salire alla 19.2.4. La linea 19.3 si chiude con la 19.3.2, la linea 19.4 con la 19.4.1. Per un deploy Docker la procedura passa dallo stop del container, dalla rimozione e dal pull della nuova immagine, per esempio self-hosted-v19.4.1-ee. Helm vuole il nuovo tag nell'impostazione image del chart.

Sotto la 19.2.4 la tabella si ferma. Tutte le release dalla 18.1.6 alla linea 19.1 cadono dentro l'intervallo colpito, e per quelle linee manca una versione corretta.

La guida d'installazione chiede di usare l'immagine del gateway che corrisponde alla minor version di GitLab. L'advisory tace su un punto pratico: la compatibilità fra un gateway 19.2.4 e un GitLab 19.1 o precedente. Al 2 ottobre la maintenance policy elenca 19.4, 19.3 e 19.2 come linee che ricevono fix di sicurezza, le stesse tre che hanno ottenuto la patch del gateway.

La condizione di fondo: il perimetro scelto diventa il bersaglio

Il confine costruito per proteggere i dati diventa il confine da difendere. Vale per il self-hosting del gateway come valeva per i proxy di uscita e per i vault on-premise.

La security posture dei sistemi AI viaggia con due o tre anni di ritardo rispetto alla maturità dell'infrastruttura che li ospita: resta una delle posizioni di questo desk, e il caso la rinforza. Un gateway AI è un componente di rete privilegiato, con credenziali verso i modelli e visibilità sui prompt. Merita il trattamento di un bastion host.

La pratica corrente lo colloca spesso altrove, dentro il backlog del team piattaforma.

Qui entra anche l'identità dell'agente, il piano di controllo del 2026. Una Duo Agent Platform raggiungibile da un utente autenticato eredita la fiducia di quell'utente e la porta su un servizio che esegue. Il confine fra chi chiede e chi esegue va reso esplicito a livello di autorizzazione.

Quello che l'advisory tace

Due silenzi pesano più della descrizione tecnica.

Il primo: manca un workaround per i gateway che restano in attesa di aggiornamento. Chi ha finestre di change management lunghe si trova davanti a una scelta secca fra spegnere il servizio e accettare il rischio.

Il secondo: l'advisory tace su come verificare un abuso avvenuto prima della patch. Zero indicatori di compromissione e zero riferimenti a log da controllare. Zero firme. Un amministratore che aggiorna oggi chiude la porta e resta cieco sul passato.

Sul fronte sfruttamento, l'agenzia americana CISA ha aggiunto una valutazione al record CVE il 2 ottobre, e vi indica lo sfruttamento come assente. Gli altri due valori previsti coprono la presenza di un proof of concept pubblico e lo sfruttamento attivo. La fotografia vale per quella data, e va riletta a ogni aggiornamento del record.

Tre domande per il team AI aziendale

Il ciclo di patch di questo componente va staccato dal ciclo di GitLab, nel registro degli asset come nel calendario operativo. Un'immagine Docker separata è un asset separato, con un proprietario che risponde del suo stato.

1. Quale versione gira sul gateway AI in produzione oggi, e chi la aggiorna?
2. Il gateway ricade nella finestra 18.1.6-19.1, priva di una versione corretta?
3. Quali log del gateway vengono conservati, e per quanti giorni?

Chi risponde con un numero di versione preciso a tutte e tre chiude la giornata. Chi risponde «dipende dal team» ha trovato il rilievo vero, e riguarda la governance interna prima della patch.

La terza domanda è quella che costa di più. In assenza di log conservati, la verifica postuma resta impossibile, e la stessa lacuna tornerà al prossimo advisory sulla stessa classe di componenti.

Decisioni per il prossimo ciclo di pianificazione

Per il CTO la questione è di inventario, prima che di sicurezza. L'elenco dei componenti AI self-hosted con credenziali verso i modelli va reso esplicito, con proprietario e versione accanto a ogni riga.

Per il capo dell'ingegneria la leva è il tempo di aggiornamento. Un'immagine Docker sostituibile in un'ora cambia il profilo di rischio di una falla 9,9; una sostituibile in tre settimane lo moltiplica.

Per il CFO la voce di spesa è il debito tecnico del self-hosting. Tenere i dati AI in casa ha un costo ricorrente di manutenzione, e quel costo va messo a bilancio accanto al beneficio di riservatezza.

Per il comitato acquisti il punto contrattuale è la notifica. GitLab ha avvisato i clienti con gateway self-hosted prima della pubblicazione: un impegno di questo tipo merita di comparire nel contratto, con tempi definiti e canale dichiarato.

La previsione falsificabile è questa: entro dodici mesi almeno un altro gateway AI self-hosted di un grande vendor riceverà un advisory critico con la stessa forma, ossia un utente autenticato che arriva all'esecuzione. Il modello architetturale lo rende probabile.