Proteggere il GitLab AI Gateway dall'esecuzione di codice remoto (RCE)

Le grandi imprese spendono milioni per isolare i propri carichi di lavoro AI dietro firewall privati e gateway self-hosted. Si aspettano un controllo totale sul flusso dei dati e un perimetro rafforzato contro le minacce esterne. L'effettiva sfruttabilità della versione 19.4 di GitLab AI Gateway dimostra che anche gli ambienti più isolati rimangono vulnerabili a semplici difetti di input. Un singolo utente loggato con accesso alla Duo Agent Platform può bypassare la sandbox che dovrebbe contenere i prompt dell'IA. Questa fuga porta direttamente all'esecuzione di comandi arbitrari sul server che gestisce la connessione dell'organizzazione ai modelli linguistici di grandi dimensioni.

Ho trascorso anni analizzando come gli sviluppatori considerino i motori di template come zone sicure. Esiste un malinteso comune secondo cui, se un utente è già autenticato, il rischio di una fuga dalla sandbox sia secondario. Questa mentalità è pericolosa. Nel caso di CVE-2026-90970, GitLab ha valutato la falla con un punteggio di 9.9 su 10 nella scala CVSS. Quel punteggio è un chiaro indicatore del fatto che la comunità della sicurezza considera questo come un fallimento critico per la missione. La falla non è una sottile corruzione di memoria o un complesso attacco di temporizzazione. È un errore nel template del prompt di un flusso personalizzato, una funzionalità progettata per automatizzare attività multi-fase.

Il rischio architettonico delle chiavi di firma sensibili

Il GitLab AI Gateway funge da caveau digitale infrangibile per la connessione tra un'istanza GitLab interna e i fornitori di IA esterni. Per progettazione, questo gateway conserva le chiavi di firma dei JSON Web Tokens (JWT). Queste chiavi sono credenziali sensibili che facilitano la comunicazione sicura. Se un aggressore esegue comandi sul gateway, non è più solo un utente all'interno di una sandbox. Possiede gli stessi permessi del servizio gateway stesso. Questo livello di accesso consente a un attore malintenzionato di intercettare richieste o potenzialmente manipolare le risposte dell'IA su cui altri sviluppatori dell'azienda fanno affidamento per la generazione di codice e la scansione di sicurezza.

Dal punto di vista del rischio, l'impatto è sistemico. Un gateway self-hosted viene spesso scelto specificamente per mantenere i dati all'interno di un ambiente controllato. Quando quel gateway viene compromesso, lo strumento stesso destinato a migliorare la privacy diventa una testa di ponte per un'intrusione più ampia. Il gateway si connette ai fornitori di modelli IA dell'organizzazione e all'istanza GitLab principale. Una compromissione qui è una compromissione del rapporto di fiducia tra l'ambiente di sviluppo e il livello di intelligenza che lo alimenta.

Decostruire la fuga dalla sandbox tramite prompt injection

La realtà tecnica di questa falla risiede nel CWE-1336, che riguarda la neutralizzazione impropria delle direttive nei template delle pagine web. GitLab consente agli utenti di creare flussi personalizzati sulla Duo Agent Platform. Questi flussi utilizzano template di prompt per strutturare il modo in cui l'IA elabora le informazioni. Un utente con accesso legittimo può creare una configurazione di flusso che inganna il motore di template spingendolo a eseguire codice al di fuori dei confini previsti. Questa è la classica fuga dalla sandbox. Il sistema tratta l'input dannoso dell'aggressore come un comando piuttosto che come dati.

Dietro le quinte, il gateway non riesce a convalidare correttamente la struttura del template del prompt. Ricordo un caso simile di cui ho discusso con un hacker white-hat tramite una connessione Signal l'anno scorso. Abbiamo esaminato un motore di template che permetteva agli utenti di chiamare funzioni di sistema se annidavano le parentesi in un modo specifico. È stata una semplice svista nel parser. La storia recente di GitLab suggerisce che questo sia un tema ricorrente. A febbraio, hanno patchato CVE-2026-1868, un'altra falla da 9.9 che coinvolgeva anch'essa definizioni di flusso create ad hoc. La ripetizione di questa classe di vulnerabilità indica che la sicurezza dei template rimane un ostacolo difficile per le piattaforme integrate con l'IA.

Valutazione della superficie di attacco per le istanze self-hosted

Solo le organizzazioni che ospitano il proprio AI Gateway devono agire. GitLab gestisce il gateway per i clienti su GitLab.com e GitLab Dedicated. Parlando in modo proattivo, quei clienti sono già protetti perché GitLab ha aggiornato la propria infrastruttura prima dell'avviso pubblico. L'onere della difesa ricade ora sulle spalle degli amministratori di sistema che gestiscono le proprie immagini Docker o i propri chart Helm.

A livello architettonico, il gateway è un servizio autonomo. Non si aggiorna automaticamente quando si aggiorna l'istanza principale di GitLab. Questa separazione è importante. Un errore comune è presumere che un'applicazione GitLab Rails patchata significhi un ambiente IA patchato. Il gateway è un'immagine Docker separata con il proprio versionamento e ciclo di vita. Se si esegue una versione compresa tra 18.1.6 e 19.2.4, o qualsiasi versione nelle linee 19.3 e 19.4 precedenti alle ultime release, si è vulnerabili.

Passaggi di aggiornamento manuale per Docker e Helm

Il patching è l'unica contromisura efficace perché GitLab non ha fornito una soluzione alternativa (workaround). Per mettere in sicurezza una distribuzione basata su Docker, è necessario arrestare il contenitore esistente e rimuoverlo. Quindi si scarica il tag dell'immagine aggiornata. Per la maggior parte degli utenti aziendali, questo sarà il tag self-hosted-v19.4.1-ee o il suo equivalente per le linee 19.2 e 19.3.

Per chi utilizza Kubernetes, il processo prevede l'aggiornamento dell'impostazione dell'immagine nel chart Helm. La tabella seguente riassume i percorsi di aggiornamento necessari per le versioni interessate:

La politica di manutenzione di GitLab copre generalmente la release minore corrente e le due precedenti. Di conseguenza, le correzioni sono disponibili per le linee 19.2, 19.3 e 19.4. Se si esegue una versione precedente, come la 19.1, non è elencata alcuna correzione ufficiale. Questa mancanza di supporto per le versioni più vecchie è un dettaglio granulare che gli amministratori non devono trascurare. Eseguire una versione non supportata del gateway significa effettivamente lasciare il caveau digitale aperto.

Limitazioni forensi e assenza di sfruttamento

Ad oggi, la Cybersecurity and Infrastructure Security Agency (CISA) degli Stati Uniti elenca lo sfruttamento di questa falla come nullo. Non esiste una prova di concetto pubblica e nessuna prova di sfruttamento attivo sul campo. Tuttavia, l'avviso non fornisce un metodo per verificare se un gateway sia stato attaccato prima dell'aggiornamento. Questa mancanza di visibilità forense è una lacuna significativa. Senza firme di log specifiche o indicatori di compromissione, gli amministratori restano a chiedersi se le loro chiavi di firma siano state accessibili durante la finestra di vulnerabilità.

In caso di violazione che coinvolga uno strumento come questo, l'obiettivo è spesso la persistenza furtiva. Un aggressore potrebbe non mandare in crash il gateway. Potrebbe invece esportare silenziosamente le chiavi di firma JWT per facilitare l'accesso non autorizzato ai modelli IA in un secondo momento. Ecco perché la rotazione immediata delle credenziali sensibili dopo una patch è una pratica standard del settore. Riparare il buco nello scafo della nave è il primo passo, ma bisogna anche controllare se del carico è stato gettato fuori bordo mentre il buco era aperto.

L'elemento umano nella sicurezza dell'IA

Spesso trattiamo l'IA come un livello futuristico che si trova sopra il nostro codice esistente. In realtà, i servizi IA come il GitLab Gateway sono solo altro software. Sono soggetti alle stesse vulnerabilità della vecchia scuola come la command injection e le fughe dai template. Il firewall umano rimane la prima linea di difesa. Gli utenti che hanno accesso alla Duo Agent Platform sono quelli che possono raggiungere questa falla. Limitare l'accesso a queste piattaforme solo a coloro che ne hanno strettamente bisogno segue il principio del minimo privilegio.

Lo Zero Trust è come un buttafuori di un club VIP ad ogni porta interna. Anche se un utente è all'interno dell'edificio, il buttafuori dovrebbe controllare le sue credenziali prima di lasciarlo avvicinare alla configurazione del motore di template. Se la vostra organizzazione consente a ogni sviluppatore di creare flussi IA personalizzati senza supervisione, state aumentando la vostra superficie di attacco. La complessità di queste integrazioni IA rende il controllo granulare degli accessi un requisito piuttosto che un suggerimento.

Punti chiave per una mitigazione immediata

Per affrontare questa falla critica, gli amministratori dovrebbero seguire una sequenza specifica di azioni. In primo luogo, identificare l'esatta versione dell'immagine dell'AI Gateway attualmente in esecuzione nell'ambiente. Non presumere che la versione corrisponda all'applicazione GitLab principale. In secondo luogo, applicare immediatamente la patch pertinente utilizzando le procedure Docker o Helm fornite da GitLab. In terzo luogo, considerare la rotazione delle chiavi di firma JWT se il gateway è stato esposto a utenti interni non fidati prima dell'applicazione della patch.

Infine, verificare l'elenco degli utenti che hanno il permesso di configurare flussi personalizzati sulla Duo Agent Platform. Se un utente non ha un motivo critico per modificare queste configurazioni, rimuovere il suo accesso. Ridurre il numero di persone che possono raggiungere la vulnerabilità è importante quanto correggere il codice stesso. La sicurezza è un processo continuo di perfezionamento, non un aggiornamento una tantum.

Fonti

• GitLab Security Advisory (CVE-2026-90970)
• CISA Known Exploited Vulnerabilities Catalog (Assessment Phase)
• CWE-1336: Improper Neutralization of Directives in Web Page Templates
• NIST Guide to Enterprise Patch Management Strategies

Dichiarazione di non responsabilità: Questo articolo è solo a scopo informativo ed educativo. Non sostituisce un audit professionale di cybersecurity o un servizio di risposta agli incidenti. Consultare sempre la documentazione ufficiale del fornitore prima di eseguire aggiornamenti di sistema.