L'AI Gateway di GitLab ha permesso a una configurazione di flusso appositamente creata di uscire dalla sandbox dei prompt

Il 2 ottobre 2026, GitLab ha pubblicato un rilascio di patch critico per il suo AI Gateway — il middleware che trasporta le richieste tra un'istanza GitLab e i modelli linguistici chiamati dalle sue funzionalità Duo — assegnando il nome CVE-2026-90970 e valutandolo 9,9 su 10. La vulnerabilità, secondo le stesse parole di GitLab, avrebbe potuto consentire "a un utente autenticato con accesso a Duo Agent Platform di eludere la sandbox dei template di prompt tramite una configurazione di flusso appositamente predisposta, comportando l'esecuzione arbitraria di comandi sull'AI Gateway". Solo le organizzazioni che eseguono un AI Gateway self-hosted dovevano intervenire: GitLab aveva già corretto i gateway che gestisce per GitLab.com, GitLab Dedicated e i clienti self-managed che utilizzano un gateway ospitato da GitLab, e lo aveva dichiarato nell'avviso. L'avviso di GitLab non afferma che la vulnerabilità sia mai stata sfruttata, e la valutazione allegata al record CVE dalla US Cybersecurity and Infrastructure Security Agency lo stesso giorno indica lo sfruttamento come «none». Il merito della scoperta è stato attribuito al ricercatore di HackerOne noto come invisiblemeerkat. L'avviso di GitLab, il record NVD e i resoconti che ne sono seguiti concordano tra loro su quale fosse la vulnerabilità e quali versioni la contenessero; concordano altrettanto su ciò che non è noto, ovvero se qualcuno l'abbia mai usata. Questo record si colloca accanto alle altre vulnerabilità documentate dell'infrastruttura degli agenti in l'archivio degli incidenti di IA, dove ogni voce porta con sé le proprie fonti, gravità, grado di affidabilità e flag di contestazione.

Cosa dice davvero l'avviso, e cosa omette

L'avviso è breve. Pubblicato sul sito della documentazione di GitLab con il titolo "Rilascio della patch critica di GitLab AI Gateway: 19.2.4, 19.3.2 e 19.4.1", elenca una correzione di sicurezza, intitolata "Problema di neutralizzazione impropria nel modello di prompt del flusso personalizzato influisce su AI Gateway" e contrassegnata come Critica. Indica il vettore CVSS 3.1 come AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H — raggiungibile via rete, bassa complessità di attacco, privilegi bassi richiesti, nessuna interazione utente, scope modificato e impatto elevato su riservatezza, integrità e disponibilità. Vale la pena leggere quel vettore perché è preciso riguardo all'attaccante: privilegi bassi, ma pur sempre privilegi. L'avviso dice "un utente autenticato con accesso a Duo Agent Platform" e si ferma lì. Non indica il ruolo, l'autorizzazione o le condizioni a cui fa riferimento la sua stessa frase "in determinate condizioni".

Non pubblica una proof of concept, non descrive la configurazione di flusso appositamente costruita e non offre una soluzione alternativa per i gateway che non possono essere aggiornati immediatamente. The Hacker News, nel suo rapporto del 2 ottobre, rileva le stesse assenze e ne aggiunge una che conta sul piano operativo: l’avviso non fornisce alcun modo per verificare se un gateway sia stato attaccato prima che vi fosse applicata la patch. Security Affairs, scrivendo il giorno successivo, registra le stesse lacune.

La voce della Common Weakness Enumeration associata alla CVE è CWE-1336, neutralizzazione impropria di elementi speciali utilizzati in un motore di template. L'avviso di GitLab non usa mai la parola Jinja. La documentazione del repository dell'AI Gateway invece sì: il suo documento sul registro dei prompt descrive file di configurazione dei prompt che «supportano espressioni Jinja per più ruoli, come utente e sistema», e descrive una classe Prompt che «usa Jinja per interpolare i template dei prompt con gli argomenti di input». La lacuna descritta dalla CVE è quella per cui quella classe di motori è famosa: testo fornito dall'utente che raggiunge un template che viene valutato anziché stampato.

Perché un comando su questo particolare host vale 9,9

L'AI Gateway non è un sidecar. Secondo la documentazione self-hosted di GitLab, riceve le richieste da GitLab, assembla i prompt e comunica con il backend del modello — un server vLLM, Amazon Bedrock, Azure OpenAI o un provider esterno — e in una distribuzione completamente self-hosted è il componente che mantiene prompt e risposte all'interno della rete dell'organizzazione. La guida all'installazione dell'AI Gateway di GitLab indica inoltre agli amministratori di generare una coppia di chiavi di firma e di passare le due metà al servizio come variabili d'ambiente, come AIGW_SELF_SIGNED_JWT__SIGNING_KEY e AIGW_SELF_SIGNED_JWT__VALIDATION_KEY (con equivalenti per Duo Workflow). Security Affairs rende esplicita la conseguenza: l'esecuzione di comandi sul gateway porta un attaccante su un host che contiene materiale per la firma JWT e si trova sul percorso tra l'istanza GitLab e l'infrastruttura dei modelli.

Questa è la differenza tra un'evasione dalla sandbox in un giocattolo e una in produzione. L'evasione non deve raggiungere un modello; deve raggiungere il processo che detiene le chiavi con cui vengono firmate le chiamate al modello.

La documentazione di prodotto di GitLab, separatamente dall'avviso, afferma che creare o modificare un flusso personalizzato richiede il ruolo di Maintainer o Owner nel progetto di gestione, e che eseguirne uno richiede Developer o un ruolo superiore. L'avviso non conferma questa corrispondenza, e The Hacker News osserva che nessun ruolo viene nominato al di là dell'"accesso a Duo Agent Platform". Un lettore che valuta la propria esposizione dovrebbe considerare la documentazione come il modello di autorizzazione del prodotto e il silenzio dell'avviso esattamente per quello che è: silenzio, non una contraddizione.

Stabilito, e non stabilito

I {{1}}campi del record stesso{{/1}} sono coerenti con tutto quanto sopra e non aggiungono nulla che non sia nell'avviso. Quello che segue è la {{2}}suddivisione{{/2}} che un lettore non può ottenere da un riassunto di una riga.

• Stabilito: una vulnerabilità di gravità critica in GitLab AI Gateway, divulgata il 2 ottobre 2026, CVSS 9.9, CWE-1336, raggiungibile da un utente autenticato di Duo Agent Platform tramite una configurazione di flusso appositamente predisposta, con conseguente esecuzione di comandi sull'host del gateway.

• Stabilito: l'intervallo interessato — tutte le versioni di AI Gateway dalla 18.1.6 fino a prima della 19.2.4, la 19.3 fino a prima della 19.3.2 e la 19.4 fino a prima della 19.4.1 — e le versioni corrette, 19.2.4, 19.3.2 e 19.4.1.

• Confermato: I gateway ospitati da GitLab sono stati corretti prima della pubblicazione e i relativi clienti non devono intraprendere alcuna azione; gli operatori self-hosted sono stati contattati direttamente prima del post di rilascio, come GitLab afferma nell’avviso stesso.

• Accertato: il riconoscimento al segnalatore, a invisiblemeerkat, e l'assenza di qualsiasi dichiarazione di sfruttamento nel mondo reale.

• Non stabilito:se qualcuno l'abbia sfruttata. Una valutazione CISA SSVC datata 2 ottobre 2026 e visibile nel record NVD indica lo sfruttamento come "none", l'automatizzabilità come "no" e l'impatto tecnico come "total"; il catalogo CISA Known Exploited Vulnerabilities non elencava CVE-2026-90970 nella sua revisione del 20 ottobre 2026, che ho verificato direttamente. Il modello EPSS di FIRST ha stimato la probabilità di sfruttamento nei successivi 30 giorni allo 0,94 per cento il 21 ottobre 2026 — bassa, e non zero.

• Non stabilito: quante istanze gateway self-hosted esistano, quante siano state esposte, o se qualcuna sia stata attaccata prima della correzione. Nessuna fonte in questo record fornisce un conteggio, e l'avviso di GitLab non indica alcun metodo di rilevamento.

L'intervallo interessato e le versioni per cui non è indicata alcuna correzione

L'aritmetica delle versioni è meno ordinata di quanto suggeriscano le tre release corrette. L'intervallo interessato inizia dalla 18.1.6 e nessuna release corretta è pubblicata su alcuna linea inferiore alla 19.2.4. Ogni gateway dalla 18.1.6 fino alla serie 19.1 rientra quindi nell'intervallo interessato dichiarato, senza che sia indicata una versione con patch per esso. The Hacker News segnala la stessa conseguenza e le domande che ne seguono: la documentazione di installazione di GitLab dice agli amministratori di eseguire l'immagine del gateway la cui versione corrisponde alla loro versione minor di GitLab, e l'avviso non specifica se un gateway 19.2.4 funzioni con GitLab 19.1 o versioni precedenti, né se siano previste correzioni per le linee più vecchie. La policy delle versioni supportate di GitLab, come nota The Hacker News, elenca attualmente 19.4, 19.3 e 19.2 — le stesse tre linee che hanno ricevuto correzioni.

La remediation consiste in una sostituzione del container anziché in una patch: il gateway viene distribuito come immagine Docker o chart Helm a sé stanti. La guida all'installazione di GitLab descrive come arrestare e rimuovere il container in esecuzione, scaricare la nuova immagine con un tag self-hosted-vX.Y.Z-ee e avviarlo di nuovo mantenendo intatte le variabili d'ambiente; le distribuzioni Helm impostano il tag nel campo image del chart. Né l'advisory né la guida all'installazione forniscono una firma o un indicatore che consenta di distinguere un gateway attaccato da uno pulito.

La stessa categoria di bug, otto mesi prima

Non è la prima volta che GitLab rilascia un 9.9 per l'iniezione di template nell'AI Gateway. Il 6 febbraio 2026 ha rilasciato AI Gateway 18.6.2, 18.7.1 e 18.8.1 per CVE-2026-1868, descritto in quell'avviso come un «problema di espansione di template non sicura» in cui il componente Duo Workflow Service era «vulnerabile all'espansione non sicura di template di dati forniti dall'utente tramite definizioni Flow di Duo Agent Platform appositamente costruite», sfruttabile per denial of service o esecuzione di codice sul gateway. Il vettore CVSS è identico a quello di ottobre, carattere per carattere, e lo stesso vale per il CWE. Il segnalatore era diverso: quello era stato trovato internamente, dal membro del team GitLab Joern Schneeweisz.

L'avviso di ottobre non menziona quello di febbraio, e The Hacker News lo afferma esplicitamente. Se i due condividano una causa radice, una correzione che non ha retto o semplicemente un linguaggio e un modello di minaccia, non è una domanda a cui risponda nessuno dei due documenti pubblici. Ciò che è agli atti è che un motore di template in un componente middleware per l'IA ha ormai prodotto due avvisi critici di esecuzione di comandi con lo stesso punteggio nello stesso anno, e che il secondo ha richiesto che fosse un ricercatore esterno a trovarlo.

Cosa è cambiato e cosa resta agli operatori da decidere

La modifica concreta consiste in tre tag delle immagini e in una tornata di contatti diretti. GitLab afferma di aver contattato i clienti con gateway self-hosted prima della pubblicazione, e l'avviso è stato diffuso insieme alle immagini corrette lo stesso giorno. Per tutti gli altri — GitLab.com, GitLab Dedicated e le istanze self-managed puntate su un gateway ospitato da GitLab — la correzione era già stata applicata lato server e, secondo GitLab, non era richiesto nulla.

Per un operatore self-hosted, la decisione è più ristretta e meno confortevole di un normale ciclo di patch. Non esiste alcuna soluzione alternativa per un gateway che non può essere spostato immediatamente. Non esiste un metodo pubblicato per stabilire se l'host fosse stato compromesso in precedenza, il che significa che l'unica opzione retrospettiva è quella ordinaria: trattare il container come un sistema la cui integrità non è dimostrata e cercare segni di esecuzione al di fuori del suo normale comportamento. E per i gateway su 18.x o 19.1, l'avviso non indica alcuna versione di destinazione — un'omissione che The Hacker News riporta e che l'avviso di GitLab non affronta.

La classificazione dell'archivio è deliberatamente più ristretta di quella del fornitore. Registra questa voce come una vulnerabilità, con confidenza A e fonti concordi, non contestata, senza alcun danno reale registrato, e con un campo di severità «high» a fronte di «critical» di GitLab e NVD. Quelle sono risposte a domande diverse: il punteggio descrive ciò che la falla consentirebbe, mentre il grado dell'archivio descrive ciò che è noto essere accaduto. Nel registro pubblico, non è accaduto nulla: nessuno sfruttamento, nessuna vittima, nessun rapporto sull'incidente. Il valore della voce è che documenta, con un numero CVE e una versione corretta, esattamente come un template di prompt è diventato una riga di comando nel middleware da cui dipendono le funzionalità AI aziendali.