La vulnerabilità di GitLab AI Gateway aggira la sandbox e consente l'esecuzione di comandi

GitLab ha corretto una vulnerabilità di GitLab AI Gateway valutata 9,9 su 10, dopo che i ricercatori hanno individuato un percorso verso l'esecuzione arbitraria di comandi. Il difetto interessa i gateway self-hosted e richiede un utente autenticato con accesso alla GitLab Duo Agent Platform. Un custom flow appositamente predisposto può evadere la sandbox dei template di prompt ed eseguire comandi con i privilegi del processo del gateway.

L'incidente ha una portata più limitata rispetto a una falla sfruttabile da remoto che colpisca ogni deployment GitLab. I gateway ospitati da GitLab sono stati corretti dall'azienda e i clienti che usano tali servizi non devono aggiornare autonomamente il gateway. Le organizzazioni che gestiscono un AI Gateway self-hosted hanno invece una responsabilità immediata.

Questa distinzione crea la tensione centrale. L'hosting autonomo offre a un'organizzazione maggiore controllo sull'elaborazione AI, sull'infrastruttura e sui percorsi dei dati. Trasferisce però al cliente anche le responsabilità di patching, monitoraggio e contenimento. In questo caso, il componente collocato nell'ambiente fidato è diventato un bersaglio per l'esecuzione di comandi.

La vulnerabilità è tracciata come CVE-2026-90970. GitLab ha rilasciato le versioni 19.2.4, 19.3.2 e 19.4.1 di AI Gateway il 2 ottobre 2026. L'azienda ha invitato gli operatori interessati ad aggiornare immediatamente, ma il suo avviso pubblico non identifica una soluzione alternativa né fornisce indicazioni dettagliate per rilevare eventuali compromissioni.

La vulnerabilità di GitLab AI Gateway richiede un aggiornamento immediato

Il fatto urgente è semplice: i gateway self-hosted interessati necessitano di una versione corretta di AI Gateway, non soltanto di un'applicazione GitLab aggiornata.

L'avviso di patch critica di GitLab identifica tre versioni corrette: 19.2.4, 19.3.2 e 19.4.1. Il numero di versione pertinente appartiene al componente AI Gateway. Non va confuso con la versione di un'istanza GitLab collegata.

L'intervallo interessato inizia con AI Gateway 18.1.6. Include le versioni precedenti alla 19.2.4, la versione 19.3 precedente alla 19.3.2 e la versione 19.4 precedente alla 19.4.1. Le organizzazioni che eseguono un ramo supportato più vecchio devono selezionare la release corretta appropriata.

Anche la formulazione è importante per le installazioni sulle linee 18.x e 19.1. GitLab non ha elencato una release gateway corretta precedente alla 19.2.4 nell'avviso di ottobre. Gli operatori su queste linee non dovrebbero presumere che rimanere su un ramo più vecchio offra protezione.

Un AI Gateway self-hosted viene eseguito come servizio separato, tipicamente tramite un container o un deployment Helm. L'aggiornamento dell'applicazione GitLab principale non dimostra automaticamente che l'immagine del gateway sia stata sostituita. Gli amministratori devono ispezionare il deployment del gateway stesso e confermare il tag dell'immagine in esecuzione.

GitLab ha dichiarato di aver contattato i clienti dei gateway self-hosted prima di pubblicare l'avviso. Ha inoltre affermato che una correzione aveva già raggiunto i gateway ospitati da GitLab. Questo protegge GitLab.com, GitLab Dedicated e le istanze self-managed collegate a un gateway ospitato da GitLab.

Questo perimetro rende l'identificazione degli asset la prima sfida operativa. Un team di sicurezza potrebbe sapere che la propria organizzazione usa GitLab Duo senza sapere quale modello di gateway lo supporti. Il servizio può essere gestito da GitLab oppure distribuito nell'ambiente del cliente.

I team dovrebbero verificare questa distinzione tramite record di deployment, inventari dei container, release Helm e configurazione di GitLab Duo. Dovrebbero evitare di dedurre la proprietà del gateway dal solo nome del prodotto GitLab. Un'istanza GitLab self-managed può comunque utilizzare un gateway ospitato da GitLab.

Il record CVE assegna alla vulnerabilità gli impatti massimi su riservatezza, integrità e disponibilità nel suo vettore CVSS 3.1. Il punteggio è 9,9 anziché 10 perché lo sfruttamento richiede privilegi minimi. Non richiede interazione dell'utente e il servizio vulnerabile è raggiungibile tramite rete.

Privilegi minimi non significano accesso anonimo. GitLab afferma che un attaccante deve essere autenticato e avere accesso alla Duo Agent Platform. Questo requisito restringe la popolazione iniziale di attaccanti, ma include account compromessi e potenziali insider malevoli.

Dopo questo accesso iniziale, il difetto attraversa un confine di sicurezza. Un utente autorizzato a lavorare con i flussi AI non dovrebbe ereditare il permesso di eseguire comandi del sistema operativo sul gateway. La vulnerabilità trasforma l'accesso a livello applicativo in controllo su un ambiente di esecuzione più sensibile.

Gli operatori dovrebbero trattare l'aggiornamento come una modifica indipendente, con prove indipendenti. Un ticket di modifica completato per GitLab non dimostra che AI Gateway sia sicuro. La prova corretta è la versione del gateway in esecuzione e un rollout verificato su ogni replica.

Questa verifica dovrebbe includere ambienti di sviluppo, staging, disaster recovery e ambienti temporaneamente ridimensionati. Le istanze gateway dimenticate restano rilevanti se mantengono connettività di rete o credenziali. Un'interfaccia inattiva non garantisce un servizio irraggiungibile.

Un custom flow ha trasformato i dati del template in comportamento eseguibile

Il problema centrale non era che un modello AI avesse scritto un comando pericoloso. Era che un confine del template consentiva a dati predisposti di raggiungere un comportamento applicativo eseguibile.

GitLab descrive il problema come una neutralizzazione impropria in un template di prompt di un custom flow. Un custom flow è un workflow AI configurabile e multi-step all'interno della Duo Agent Platform. Può combinare prompt, componenti, decisioni di instradamento e strumenti in una definizione YAML.

La documentazione sui custom flow dell'azienda mostra perché queste definizioni siano più di un normale testo di prompt. I flow possono essere creati, testati, pubblicati, abilitati per i progetti e attivati tramite l'attività di GitLab. Operano come configurazione dell'applicazione attorno a un agente.

Il percorso vulnerabile coinvolgeva una sandbox per template di prompt. Una sandbox è un ambiente di esecuzione ristretto, progettato per impedire che un template raggiunga attributi o funzioni non sicuri. CVE-2026-90970 consentiva a una configurazione di flow appositamente predisposta di evadere tali restrizioni.

Un ticket di disclosure pubblico di GitLab attribuisce il problema all'accesso non sicuro ai metodi durante il rendering dei template Jinja2. Jinja2 è un motore di template Python che combina testo con variabili ed espressioni.

Secondo il ticket, la cronologia della conversazione conteneva un oggetto HumanMessage di LangChain. Il template poteva richiamare un metodo pubblico di deserializzazione su quell'oggetto. Un payload serializzato non sicuro causava quindi l'esecuzione di comandi del sistema operativo da parte di Python durante la deserializzazione.

La deserializzazione riconverte dati archiviati o trasmessi in un oggetto del programma. Diventa pericolosa quando il formato selezionato può invocare codice durante la ricostruzione di quell'oggetto. I dati Python pickle sono un esempio noto, poiché il caricamento di contenuti pickle non attendibili non è sicuro.

La proof of concept segnalata utilizzava un flow in due passaggi. La prima interazione con il modello popolava la cronologia della conversazione. Una successiva valutazione del template accedeva a quell'oggetto della cronologia e attivava il pericoloso percorso di deserializzazione.

Questa sequenza rende il problema diverso da un normale bug di shell injection. Il valore malevolo non doveva comparire come parametro di comando diretto passato a una shell. Piuttosto, diverse funzionalità singolarmente significative formavano la catena di esecuzione.

Il flow accettava contenuti di prompt configurabili. Il motore di template riceveva oggetti applicativi. Un oggetto esponeva un metodo di deserializzazione. Il formato di serializzazione accettato poteva invocare codice. Insieme, queste condizioni aggiravano la sandbox prevista.

Il modello stesso non costituiva il confine di sicurezza fidato. Ha contribuito a far avanzare il flow tra stati, ma il comando è stato eseguito tramite un comportamento applicativo deterministico. Filtrare il solo output del modello non avrebbe risolto la relazione vulnerabile tra oggetto e template.

Questa distinzione conta quando le organizzazioni classificano i fallimenti della sicurezza AI. Il prompt injection descrive tentativi di manipolare un modello tramite istruzioni. CVE-2026-90970 è una vulnerabilità software nel sistema che circonda il modello, anche se un template di prompt fornisce il punto d'ingresso.

Le pratiche tradizionali di sicurezza applicativa restano quindi essenziali. Gli input dei template necessitano di una validazione rigorosa, gli oggetti esposti devono avere interfacce minime e i formati di deserializzazione pericolosi non dovrebbero elaborare dati controllati da un attaccante. Anche le sandbox devono essere testate rispetto agli oggetti esatti resi disponibili al loro interno.

I comandi segnalati venivano eseguiti con i privilegi del processo Duo Workflow Service. Questo limita l'autorità immediata sul sistema operativo ai permessi dell'account di servizio. Tuttavia, l'esecuzione a livello di servizio resta seria perché il gateway gestisce connessioni sensibili e si trova all'interno di infrastrutture fidate.

L'impatto pratico dipende dall'architettura del deployment. Un container con privilegi minimi e rete limitata presenta meno percorsi successivi rispetto a un servizio connesso in modo esteso. Nessuna delle due configurazioni elimina la necessità di applicare la patch, perché un attaccante otterrebbe comunque esecuzione di codice non intenzionale.

Questo meccanismo spiega la gravità prossima al massimo. L'attaccante inizia con un'identità autenticata abilitata per Duo, ma l'esecuzione risultante attraversa il contesto di sicurezza del gateway. Questo cambiamento di ambito è centrale per il punteggio di 9,9.

L'hosting autonomo trasferisce insieme controllo e responsabilità di sicurezza

L'incidente evidenzia il compromesso dell'infrastruttura AI self-hosted: mantenere l'elaborazione vicina colloca anche il gateway all'interno del confine di fiducia operativo del cliente.

GitLab descrive AI Gateway come un servizio autonomo che collega le funzionalità GitLab Duo ai modelli AI. I clienti possono utilizzare il gateway gestito da GitLab oppure gestire il proprio gateway con GitLab Duo Self-Hosted.

Le organizzazioni scelgono spesso l'hosting autonomo per controllare il movimento dei dati, l'accesso ai modelli, i percorsi di rete e le policy infrastrutturali. Questi vantaggi possono essere importanti in ambienti regolamentati o deployment con rigidi controlli interni. Creano però anche un ulteriore servizio di produzione che i clienti devono inventariare e mantenere.

La vulnerabilità di GitLab AI Gateway trasforma questo dettaglio operativo nel principale problema di sicurezza. GitLab ha potuto distribuire direttamente una correzione ai gateway che gestisce. I clienti self-hosted devono pianificare, eseguire e verificare i propri aggiornamenti.

Questo schema è noto per database, servizi di identità e runner CI. La differenza è che i gateway AI si uniscono a sistemi un tempo più chiaramente separati. Si collocano tra utenti, repository di codice sorgente, workflow degli agenti, provider di modelli e talvolta strumenti di esecuzione.

Un gateway compromesso merita quindi maggiore attenzione rispetto a un'interfaccia chatbot isolata. A seconda della configurazione, può entrare in contatto con contenuti dei prompt, stato dei workflow, credenziali di servizio, connessioni ai provider o metadati relativi alle attività di sviluppo interne.

Ciò non dimostra che CVE-2026-90970 abbia esposto ogni segreto collegato. L'avviso di GitLab non riporta furti di dati confermati né un percorso completo di post-sfruttamento. La conclusione corretta è che l'esecuzione arbitraria di comandi crea una via credibile verso ulteriori accessi.

I team dovrebbero valutare il gateway come un servizio di integrazione privilegiato. La sua identità di processo, i file montati, le variabili d'ambiente, i percorsi di rete e gli account di servizio collegati determinano il raggio d'impatto. Questi controlli diventano importanti quando si ricostruisce l'esposizione prima dell'applicazione della patch.

La containerizzazione aiuta solo quando i suoi confini sono configurati deliberatamente. Un container può comunque raggiungere servizi di rete, leggere segreti montati o inviare dati all'esterno. La sua sicurezza effettiva dipende dai permessi di runtime e dalle policy circostanti.

La guida all'installazione di GitLab raccomanda di limitare l'accesso alla rete in uscita per il container AI Gateway. Il controllo dell'egress limita le destinazioni che un processo compromesso può contattare. Può ridurre l'utilità dell'esecuzione di comandi, anche se non elimina l'impatto locale.

La segmentazione di rete fornisce un ulteriore livello di contenimento. Un gateway necessita dell'accesso a endpoint GitLab e dei modelli ben definiti, ma raramente ha bisogno di raggiungere senza restrizioni un'intera rete interna. Allowlist ristrette rendono più difficile il movimento laterale imprevisto.

Anche la progettazione delle credenziali è importante. Segreti a lunga durata archiviati direttamente nell'ambiente creano obiettivi allettanti dopo una compromissione. Credenziali di breve durata, account di servizio isolati e permessi strettamente circoscritti possono ridurre i danni dopo la compromissione di un servizio.

I team di sicurezza dovrebbero inoltre esaminare chi può creare o modificare flussi personalizzati. La documentazione di GitLab assegna azioni di gestione dei flussi a ruoli quali Maintainer o Owner in diversi workflow. L'esposizione esatta dipende comunque dalla configurazione del prodotto e dall'implementazione interessata.

L'advisory usa l'espressione più ampia “Duo Agent Platform access” anziché indicare un unico ruolo di progetto universalmente richiesto. Gli amministratori non dovrebbero trasformare gli esempi della documentazione in un prerequisito definitivo per lo sfruttamento. Dovrebbero verificare le autorizzazioni effettive e le modifiche storiche ai flussi.

L'hosting autonomo rimane una scelta architetturale valida. La lezione non è che un servizio gestito sia sempre più sicuro. La lezione è che il controllo dei dati, il controllo del software e la responsabilità degli incidenti arrivano insieme.

Un gateway gestito concentra la fiducia nelle operazioni del fornitore. Un gateway self-hosted concentra la fiducia nelle attività di patching, isolamento e monitoraggio del cliente. CVE-2026-90970 rende visibile questo scambio perché il confine della correzione segue esattamente il confine dell'hosting.

Per gli acquirenti enterprise, la revisione della sicurezza dovrebbe coprire sia le funzionalità del prodotto sia la titolarità del deployment. Le domande su dove transitano i dati dovrebbero essere accompagnate da domande su chi applica le patch a ciascun componente. Un diagramma architetturale senza titolarità operativa resta incompleto.

Una Patch Corregge il Difetto, ma Restano Domande sul Rilevamento

L'aggiornamento blocca il percorso vulnerabile noto, ma l'advisory pubblico non dice agli operatori come dimostrare che uno sfruttamento precedente non sia mai avvenuto.

Al 4 ottobre, GitLab non aveva dichiarato pubblicamente che CVE-2026-90970 fosse sfruttata attivamente. Questa assenza è rassicurante, ma non dimostra che ogni deployment interessato sia rimasto intatto.

I dettagli tecnici pubblici aumentano l'importanza di applicare rapidamente le patch. Il ticket di disclosure descrive la relazione tra gli oggetti vulnerabili e riporta una riuscita esecuzione di comandi in un ambiente di staging. Difensori e attaccanti possono entrambi studiare quel materiale.

GitLab ha attribuito la segnalazione responsabile al ricercatore HackerOne noto come invisiblemeerkat. La divulgazione responsabile ha dato a GitLab il tempo di preparare le correzioni e contattare i clienti interessati. Non ha eliminato la finestra di esposizione per i deployment rimasti senza patch dopo la pubblicazione.

Il requisito di autenticazione dovrebbe orientare la threat hunting. I team di sicurezza dovrebbero iniziare dalle identità Duo Agent Platform, dagli eventi di gestione dei flussi e dalle modifiche alle definizioni dei flussi personalizzati. Dovrebbero correlare tali record con l'attività del gateway nel periodo vulnerabile.

Le configurazioni di flusso insolite meritano una revisione, soprattutto i template che accedono a oggetti di cronologia delle conversazioni o invocano metodi. Creazione, modifica, pubblicazione o esecuzione inattese di flussi possono offrire ulteriore contesto. Nomi di flussi apparentemente normali non dovrebbero prevalere su comportamenti sospetti dei template.

Anche l'attività dei processi del gateway è rilevante. Processi figli, invocazioni della shell, binari inattesi, accessi insoliti ai file e connessioni in uscita possono indicare l'esecuzione di comandi. I dati utili dipendono dalla telemetria del container, dell'host e del cloud già abilitata.

I riavvii dei container possono cancellare le prove locali. Log centralizzati e telemetria di sicurezza del runtime sono quindi più utili della sola ispezione di un container attualmente in esecuzione. Se sospettano una compromissione, i team dovrebbero preservare i log disponibili prima di sostituire l'infrastruttura.

Gli operatori dovrebbero esaminare i segreti accessibili al processo del gateway. Le decisioni sulla rotazione dovrebbero basarsi su evidenze ed esposizione, non sul panico. Se i log indicano l'esecuzione di comandi, occorre presumere che le credenziali leggibili possano essere state consultate.

Le connessioni del gateway con GitLab e i provider di modelli meritano attenzione separata. Un attaccante che avesse ottenuto l'esecuzione di comandi potrebbe tentare di riutilizzare token, ispezionare configurazioni o raggiungere servizi connessi. Il registro pubblico non conferma che tali attività siano avvenute.

La patch non dovrebbe segnare la fine dell'indagine quando esistono prove sospette. L'aggiornamento rimuove il percorso di codice noto, ma non revoca credenziali rubate né annulla modifiche apportate altrove. Le procedure di risposta agli incidenti restano necessarie.

Esiste anche una ragione storica per la cautela. La reportistica di sicurezza ha identificato un precedente problema AI Gateway del 2026, CVE-2026-1868, con lo stesso punteggio di 9,9 e la stessa categoria di debolezza CWE-1336. Anche quel difetto riguardava contenuti di flusso manipolati e una possibile esecuzione di codice.

Due problemi ad alta gravità nel motore di template non dimostrano che ogni flusso personalizzato sia insicuro. Giustificano però un esame più attento del modo in cui template, oggetti applicativi e serializzazione si incontrano nei sistemi agentici.

La ricorrenza suggerisce che i test di sicurezza debbano coprire le composizioni, non soltanto componenti isolati. Una sandbox può comportarsi correttamente con le stringhe e fallire quando oggetti complessi del framework entrano nel suo contesto. Un metodo sicuro in un livello può diventare pericoloso quando i template possono invocarlo.

Le piattaforme agentiche intensificano questo problema perché uniscono molti meccanismi flessibili. Prompt, strumenti, cronologie, logica di routing, risposte dei modelli e API applicative interagiscono attraverso passaggi ripetuti. Uno stato introdotto in un passaggio può diventare input eseguibile in seguito.

Le organizzazioni dovrebbero aggiungere flussi personalizzati avversariali ai test pre-deployment. I test dovrebbero includere accesso ai metodi, attraversamento degli oggetti, confini di serializzazione e cambiamenti di stato in più passaggi. Una scansione del prompt in un solo passaggio non rappresenterebbe la catena di sfruttamento riportata.

Dovrebbero inoltre trattare i template come artefatti adiacenti al codice. Revisione, titolarità, cronologia delle modifiche e controlli di deployment dovrebbero corrispondere al loro potenziale impatto. Definire un file “configurazione” non riduce la sua capacità di alterare il comportamento in runtime.

GitLab non ha dettagliato pubblicamente ogni condizione necessaria per lo sfruttamento. Questo limita una valutazione affidabile dell'esposizione. I team dovrebbero usare i prerequisiti divulgati come condizioni minime, senza presumere che condizioni non specificate garantiscano la sicurezza.

Tre Segnali Indicheranno se la Risposta Sta Funzionando

La fase successiva dipende dall'adozione delle patch, dalle prove di sfruttamento nel mondo reale e da un trattamento più approfondito da parte di GitLab dell'isolamento dei flussi personalizzati.

Il primo segnale è la percentuale di gateway self-hosted che eseguono la versione 19.2.4, 19.3.2, 19.4.1 o una versione successiva corretta. Le singole organizzazioni dovrebbero misurarla in ogni ambiente e replica. I numeri a livello di settore potrebbero restare indisponibili perché questi deployment risiedono nelle reti dei clienti.

Un'adozione rapida restringerebbe la superficie d'attacco raggiungibile dopo la divulgazione pubblica. Un'adozione lenta prolungherebbe il rischio, soprattutto dove i servizi AI non rientrano negli inventari consolidati di gestione delle vulnerabilità. La titolarità del gateway dovrebbe diventare visibile nelle dashboard delle patch.

Il secondo segnale è qualsiasi cambiamento nello stato dello sfruttamento. GitLab, CISA, aziende di incident response e clienti interessati potrebbero pubblicare indicatori o casi confermati. Una segnalazione di sfruttamento attivo sposterebbe la priorità dalla patch preventiva a una risposta agli incidenti più ampia.

I difensori dovrebbero distinguere una proof of concept pubblica da attacchi osservati. La riproduzione tecnica dimostra che il difetto funziona nelle condizioni documentate. Non stabilisce che gli attaccanti abbiano compromesso clienti in produzione.

Il terzo segnale è un cambiamento strutturale nella sicurezza dell'AI Gateway. Una patch circoscritta può bloccare la chiamata al metodo divulgata. Una risposta più ampia potrebbe ridurre quali oggetti raggiungono i template, vietare serializzazioni pericolose o rafforzare l'isolamento intorno ai flussi personalizzati.

Questa risposta progettuale è importante perché la catena riportata è emersa dalla composizione di funzionalità. Impedire un payload è utile, ma eliminare il confine di capacità non sicuro offre una protezione più forte contro le varianti.

Le future note di rilascio e le modifiche al codice di GitLab dovrebbero chiarire quale livello ha ricevuto la correzione. Gli amministratori dovrebbero prestare attenzione a nuove indicazioni su convalida dei flussi, eventi di audit, query di rilevamento e percorsi di aggiornamento supportati per i rami gateway meno recenti.

I clienti enterprise possono usare l'incidente per testare ora il proprio modello operativo. La domanda importante non è semplicemente se GitLab compare nell'inventario software. È se l'AI Gateway esiste come servizio separatamente gestito, aggiornato, registrato nei log e isolato.

Anche gli sviluppatori che creano flussi dovrebbero riconsiderare la fiducia attribuita alla configurazione. Un flusso personalizzato può coordinare strumenti e dati applicativi attraverso più passaggi. Dovrebbe ricevere lo stesso scetticismo applicato agli script di automazione e alle definizioni CI.

I revisori della sicurezza dovrebbero mappare quattro confini: chi può creare flussi, a quali oggetti possono accedere i template, quali strumenti possono invocare i flussi e quali privilegi possiede il processo del gateway. Debolezze in più confini possono trasformare un accesso limitato nel controllo dell'infrastruttura.

I knowledge worker che usano GitLab Duo non devono abbandonare il lavoro ordinario a causa di questo advisory. La maggior parte non può determinare autonomamente la titolarità del gateway. Dovrebbero seguire le indicazioni dell'organizzazione e segnalare comportamenti inattesi dei flussi anziché tentare test indipendenti.

Gli amministratori devono compiere un'azione più chiara. Identificare il modello di hosting, confermare la versione del gateway in esecuzione, distribuire la patch corretta e preservare le prove quando compare attività sospetta. Rivedere le modifiche ai flussi e la telemetria del gateway durante il periodo vulnerabile.

Dopo l'applicazione della patch, documentare il risultato in un record operativo duraturo. Registrare la versione precedente, l'orario di deployment, gli ambienti interessati, il metodo di verifica e qualsiasi risultato della threat hunting. Queste prove supportano audit futuri e la ricostruzione degli incidenti.

La vulnerabilità GitLab AI Gateway è in definitiva un avvertimento su dove la logica delle applicazioni AI diventa software eseguibile convenzionale. Il fallimento è iniziato in un template di prompt, è passato attraverso un oggetto del framework ed è terminato con comandi del sistema operativo.

Questo percorso merita più attenzione della sola etichetta “AI”. I modelli possono influenzare i workflow, ma i normali confini software decidono ancora se un input non attendibile diventa codice. Le organizzazioni hanno bisogno di controlli attorno a entrambi i livelli.

Se la vostra organizzazione utilizza GitLab Duo, ponete oggi una domanda concreta: chi possiede il gateway che elabora queste richieste? Se la risposta è il vostro team, verificate la sua versione rispetto alle release corrette di GitLab. Quindi testate se il vostro monitoraggio rileverebbe comandi inattesi, flussi alterati o connessioni in uscita. La patch chiude la vulnerabilità GitLab AI Gateway divulgata, ma una sicurezza duratura dipende da inventario, isolamento e prove che resistano al prossimo advisory.