GitLab patcha RCE critica nell'AI Gateway: a rischio i deployment self-hosted

GitLab ha rilasciato il 2 ottobre 2026 patch critiche per il proprio AI Gateway, il servizio che media le richieste tra le istanze self-hosted e i modelli di intelligenza artificiale. La vulnerabilità, tracciata come CVE-2026-90970 con punteggio CVSS 9.9, permette a utenti autenticati con accesso alla piattaforma Duo Agent di eseguire comandi arbitrari sul server attraverso un escape dalla sandbox dei prompt template. La posta in gioco è significativa: mentre le istanze cloud di GitLab sono già state protette, i clienti che gestiscono autonomamente l'AI Gateway devono aggiornare immediatamente.

Il meccanismo: come il template engine diventa vettore di esecuzione

Il problema risiede nel motore di template dei prompt del GitLab AI Gateway. Secondo l'advisory ufficiale, un utente autenticato con accesso Duo Agent Platform può costruire una "specially crafted flow configuration" che sfugge alla sandbox dei prompt template. L'escape consente l'esecuzione arbitraria di comandi direttamente sul server AI Gateway.

La classificazione CWE-1336 (improper neutralization) indica che il sistema non sanifica adeguatamente input che possono alterare la logica di parsing del template. Nel contesto dei servizi AI, dove i prompt template sono strutturati dinamicamente per orchestrare chiamate a modelli linguistici, questa superficie di attacco è particolarmente insidiosa: l'input apparentemente "semantico" (una configurazione di flusso) diviene veicolo di esecuzione codice.

Il vettore CVSS conferma la gravità: AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H. Accesso di rete, bassa complessità, privilegi limitati, nessuna interazione utente richiesta, scope changed. Quest'ultimo parametro è critico: suggerisce che l'impatto può estendersi oltre il componente compromesso, tipico di scenari dove l'AI Gateway — posizionato tra l'istanza GitLab e i provider di modelli — funge da punto di transito con visibilità su traffico e potenzialmente su credenziali di servizio.

"GitLab has remediated an issue in the GitLab AI Gateway that, under certain conditions, could have allowed an authenticated user with Duo Agent Platform access to escape the prompt template sandbox via a specially crafted flow configuration, leading to arbitrary command execution on the AI Gateway" — Advisory GitLab ufficiale

Versioni colpite e patch: la frammentazione dei release channel

Le versioni affette coprono un arco significativo del ciclo di rilascio dell'AI Gateway: tutte le build dalla 18.1.6 fino alle 19.2.4 esclusa, la serie 19.3 prima della 19.3.2, e la 19.4 prima della 19.4.1. Secondo il record NVD, questi sono i range semantici precisi. GitLab ha distribuito contemporaneamente tre versioni patchate: 19.2.4, 19.3.2 e 19.4.1.

La frammentazione è rilevante per la gestione operativa: le organizzazioni che tracciano diverse linee di release devono verificare quale branch stanno mantenendo. Non è sufficiente aggiornare alla major più recente se si opera su una LTS intermedia. L'advisory di GitLab è esplicito: "These versions contain a critical security fix for GitLab Self-Hosted AI Gateway, and we strongly recommend that all GitLab Self-Managed customers with GitLab Self-Hosted AI Gateway installations update to one of these versions immediately".

Un dato di contesto architetturale: l'AI Gateway self-hosted è un componente Docker separato dall'istanza GitLab principale, tipicamente deployato su infrastruttura proprietaria del cliente per governare la connessione a modelli AI on-premise o per requisiti di sovranità dei dati. Questa separazione fisica è ciò che rende la vulnerabilità circoscritta al perimetro self-hosted, ma è anche ciò che impedisce a GitLab di patchare centralmente.

Cosa fare adesso

Le azioni operative derivano direttamente dal dossier:

• Verificare la presenza dell'AI Gateway self-hosted: il componente è opzionale; non tutte le installazioni Self-Managed lo includono. Se non è deployato, la vulnerabilità non è applicabile.
• Aggiornare alla patch corrispondente al proprio branch: 19.2.4 per la linea 19.2, 19.3.2 per la 19.3, 19.4.1 per la 19.4. Saltare release intermedie non mitigate il rischio.
• Confermare che GitLab.com o GitLab Dedicated non siano coinvolti: i clienti hosted sono già protetti; non è richiesta alcuna azione su questi ambienti.
• Rivendicare l'eventuale outreach ricevuto: GitLab ha contattato direttamente i clienti self-hosted prima della pubblicazione. Verificare le comunicazioni ricevute nelle ultime settimane per eventuali istruzioni supplementari.

L'angolo cieco dell'AI infrastructure: quando il middleware AI diventa target

C'è una lettura più ampia che emerge dalla cronaca. L'AI Gateway di GitLab non è l'applicazione core: è un middleware specializzato, spesso gestito da team diversi da quelli della sicurezza applicativa tradizionale. L'hype sull'AI-assisted development ha accelerato l'adozione di queste infrastrutture senza che i controlli di sicurezza si adeguassero allo stesso ritmo.

La vulnerabilità documentata esemplifica un pattern che rischiamo di vedere ripetersi: il template prompt, conceptually un "semplice" formato di testo strutturato, diventa vettore di esecuzione codice quando il parser non neutralizza input malevoli. La sandbox che dovrebbe isolare il motore di rendering dai privilegi di sistema viene aggirata non con una complessa catena di exploit, ma con una configurazione di flusso malformata.

Il dossier non conferma sfruttamento in-the-wild per CVE-2026-90970, né fornisce un proof-of-concept pubblico. Tuttavia, la combinazione di autenticazione con privilegi relativamente accessibili (Duo Agent Platform access, non amministratore) e assenza di interazione utente richiesta abbassa la barriera all'exploit teorica. Il fatto che GitLab abbia condotto outreach preventivo suggerisce una valutazione interna di rischio elevato per la popolazione self-hosted.

Domande frequenti

La mia istanza GitLab Self-Managed è vulnerabile anche senza AI Gateway?
No. La vulnerabilità è specifica del servizio AI Gateway self-hosted. L'istanza GitLab EE/CE core non è interessata.

Che differenza c'è tra AI Gateway self-hosted e le funzionalità AI su GitLab.com?
Su GitLab.com e GitLab Dedicated l'AI Gateway è gestito da GitLab stesso ed è già stato patchato. I clienti non devono agire. L'AI Gateway self-hosted è invece deployato su infrastruttura del cliente per casi d'uso che richiedono controllo locale dei dati o modelli proprietari.

Perché il CVSS 9.9 con PR:L (privilegi bassi) è considerato così grave?
Perché i parametri UI:N (nessuna interazione utente) e S:C (scope changed) amplificano l'impatto. Un attaccante con credenziali valide può automatizzare l'exploit senza ingegneria sociale, e l'escape dalla sandbox può propagarsi oltre il componente iniziale.

Fonti

• https://www.bleepingcomputer.com/news/security/gitlab-warns-of-critical-rce-vulnerability-in-ai-gateway-service/
• https://nvd.nist.gov/vuln/detail/cve-2026-90970
• https://www.cisa.gov/news-events/alerts/2026/09/11/cisa-adds-one-known-exploited-vulnerability-catalog
• https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2026-85706
• http://docs.gitlab.com/releases/patches/other-patches/patch-release-gitlab-ai-gateway-19-4-1-released/
• https://docs.gitlab.com/install/install_ai_gateway/#upgrade-the-ai-gateway-docker-image

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti