GitLab e AWS, l’AI diventa un control plane: RCE e credenziali a rischio

🛡️ Executive Summary

• GitLab corregge CVE-2026-90970: utenti autenticati con accesso a Duo Agent Platform possono arrivare all’esecuzione di comandi sull’AI Gateway self-hosted.
• AWS chiude tre falle in Loom che coinvolgono autenticazione, token OAuth2, connessioni MCP/A2A e accesso alle credenziali del container.
• SageMaker Unified Studio mostra lo stesso problema architetturale: una connessione manipolata può trasformarsi in codice eseguito nello Space di un altro utente.

Il rischio degli agenti AI sta uscendo dal perimetro del modello per concentrarsi sull’infrastruttura che collega prompt, tool, identità e credenziali. GitLab ha corretto una vulnerabilità critica nel proprio Self-Hosted AI Gateway, mentre AWS ha pubblicato due bollettini che riguardano Loom for AWS e SageMaker Unified Studio. Presi separatamente sono problemi diversi; osservati insieme mostrano però la stessa trasformazione: il software che orchestra l’intelligenza artificiale sta accumulando privilegi tipici di un control plane, con la possibilità di raggiungere shell, secret, token e ruoli cloud. È lo stesso salto operativo già visibile quando AWS ha portato AgentCore e SageMaker nei workload aziendali reali: maggiore autonomia significa anche maggiore valore dell’infrastruttura che decide cosa l’agente può fare.

GitLab AI Gateway: dal flow alla command execution

GitLab ha corretto CVE-2026-90970, valutata CVSS 9,9, nelle versioni 19.2.4, 19.3.2 e 19.4.1 dell’AI Gateway. Secondo la critical patch release pubblicata direttamente da GitLab, un utente autenticato con accesso a Duo Agent Platform può utilizzare una configurazione flow appositamente costruita per uscire dalla sandbox dei prompt template e arrivare all’esecuzione arbitraria di comandi sull’AI Gateway. Sono interessate le installazioni Self-Hosted a partire dalla 18.1.6 nei rami indicati dal vendor, mentre i gateway ospitati da GitLab sono già stati corretti. Non esistono nelle informazioni pubblicate elementi che consentano di parlare di exploitation attiva: qui il livello di prova resta quello di una vulnerabilità critica corretta dal vendor. Il precedente recente di GitLab inserita nel KEV insieme ad Artifactory e ScreenConnect mostra però quanto rapidamente un problema DevSecOps possa passare da patch disponibile a rischio operativo quando l’accesso raggiunge componenti centrali della catena di sviluppo.

Leggi anche: TeamCity, WordPress, GitLab ed Elsevier: quattro attacchi colpiscono la fiducia digitale

Loom mette insieme agenti, MCP, OAuth e IAM

Il dossier più significativo arriva da AWS. Loom è una piattaforma open source di AWS Labs dedicata all’orchestrazione degli agenti e la security advisory 2026-124 di AWS corregge tre vulnerabilità che toccano direttamente il confine tra agenti e infrastruttura. CVE-2026-103956 consente, nelle versioni precedenti alla 1.6.1 e nelle installazioni prive di identity provider configurato, a un client di rete di ottenere piena autorità amministrativa sul control plane: registrazione dei tool server, lettura delle credenziali delle integrazioni e modifica delle policy IAM associate ai ruoli gestiti. CVE-2026-103957 riguarda invece la discovery OAuth2 e consente a un utente autenticato con scope mcp:write o a2a:write di provocare l’invio di client secret o access token verso un endpoint controllato. CVE-2026-103958 permette agli stessi profili di indirizzare connessioni MCP e A2A verso risorse interne, compreso l’endpoint che distribuisce le credenziali al container. Il problema, quindi, non è MCP in astratto ma l’autorità assegnata al software che lo implementa, un confine già emerso quando OpenAI ha sospeso i tool di Astra dopo problemi legati al perimetro degli agenti.

Le credenziali diventano l’obiettivo naturale dell’orchestratore

AWS ha corretto le tre vulnerabilità in Loom 1.7.0, mentre CVE-2026-103956 era già stata chiusa nella 1.6.1. Il vendor non si limita però all’upgrade: chiede di ruotare i client secret OAuth2 utilizzati dalle integrazioni MCP/A2A, revocare e riemettere gli access token attivi nel periodo interessato e, se le credenziali del container role possono essere state raggiunte, rinnovare le session credential e analizzare CloudTrail. È un passaggio importante perché fotografa il vero valore dell’orchestratore: non soltanto la capacità di parlare con un modello, ma quella di custodire e delegare autorità. La stessa dinamica è visibile nel caso PixelLeak, dove agenti AI hanno pubblicato screenshot interni su GitHub: quando il sistema dispone di strumenti e accessi operativi, un errore nel livello di controllo può produrre conseguenze che non dipendono dall’intelligenza del modello.

Continua con:
AWS trasforma Bedrock in una fabbrica di agenti tra GPT-6, Claude e CloudWatch Omni
FortiMail sotto attacco, AWS corregge tre falle tra MCP, Lambda e Ion

SageMaker mostra che il problema attraversa anche le identità

La security advisory AWS 2026-125 chiude il cerchio con CVE-2026-104019 in Amazon SageMaker Unified Studio. Durante l’avvio di uno Space, lo startup script verifica le connessioni SageMaker disponibili nel progetto; una sanitizzazione insufficiente dei connection details può consentire a un utente con privilegi contributor o superiori di provocare l’esecuzione arbitraria di codice nello Space di un altro membro. Dove è abilitata Trusted Identity Propagation, l’attacco può estendersi alle credenziali temporanee dell’execution role della vittima e alle chiamate verso servizi AWS compatibili. AWS ha distribuito globalmente le correzioni nelle minor release supportate e richiede il riavvio degli Space per acquisire l’immagine corretta; i rami fuori supporto non ricevono fix. Anche qui non risultano, nel bollettino, indicazioni di sfruttamento attivo. Il punto è architetturale: AI Gateway, orchestratori e ambienti di sviluppo stanno concentrando funzioni che un tempo appartenevano a livelli distinti della sicurezza. Quando una configurazione manipolata può diventare command execution, un URL OAuth può diventare furto di token e una connessione di progetto può diventare accesso alle credenziali di un altro utente, il control plane dell’AI entra definitivamente nel perimetro critico dell’infrastruttura enterprise.