Rischio AI: falle in Amazon Bedrock, LangSmith e SGLang

Mar 17, 2026 Giancarlo Calzetta In evidenza, News, RSS, Vulnerabilità 0

Le più recenti ricerche di BeyondTrust, Miggo e Orca Security dimostrano che anche piattaforme progettate per garantire isolamento e protezione – come sandbox AI, sistemi di osservabilità e framework LLM – possono trasformarsi in vettori di attacco avanzati.

Le vulnerabilità individuate in Amazon Bedrock, LangSmith e SGLang evidenziano un punto critico che in molti si aspettavano: l’adozione accelerata degli agenti AI sta ampliando la superficie di attacco ben oltre i modelli tradizionali, introducendo nuove modalità di compromissione che sfruttano meccanismi apparentemente innocui come DNS, URL o serializzazione dei dati. Come al solito, la velocità (di sviluppo, adozione e implementazioe) è nemica della sicurezza, soprattutto in caso di scenari complessi come quelli che si aprono con l’adozione dell’AI e dei suoi agenti.

DNS: come aggirare l’isolamento di Amazon Bedrock

Il caso più emblematico riguarda Amazon Bedrock AgentCore Code Interpreter. Il servizio è stato progettato per consentire agli agenti AI di eseguire codice in ambienti sandbox isolati, teoricamente senza accesso alla rete. Tuttavia, la ricerca di BeyondTrust dimostra che la possibilità di effettuare query DNS in uscita compromette di fatto questo isolamento.

Il punto critico è che anche in modalità “no network access”, il sistema consente la risoluzione DNS, aprendo la strada a un canale di comunicazione nascosto. Attraverso questo meccanismo, un attaccante può costruire un’infrastruttura di comando e controllo basata su DNS, utilizzando richieste e risposte per scambiare dati e istruzioni.

In uno scenario di attacco realistico, l’agente AI può essere trasformato in un terminale remoto controllato dall’esterno, capace di eseguire comandi, ricevere payload e restituire risultati. Il meccanismo può arrivare fino alla creazione di una reverse shell interattiva, sfruttando record DNS per trasmettere comandi e ricevere output.

Ancora più critico è il tema delle autorizzazioni. Il Code Interpreter opera con un ruolo IAM che può accedere a risorse AWS come bucket S3. Se questo ruolo è sovra-privilegiato, l’attaccante può utilizzare il canale DNS per esfiltrare dati sensibili direttamente da risorse cloud aziendali, bypassando completamente i controlli di isolamento previsti.

Il rischio, quindi, non è solo teorico. La combinazione tra accesso ai dati, capacità di esecuzione e comunicazione “covert” rende questi ambienti assimilabili a dipendenti compromessi con impatti potenziali su disponibilità dei sistemi, integrità dei dati e riservatezza delle informazioni.

Amazon ha classificato questo comportamento come funzionalità prevista, raccomandando l’utilizzo della modalità VPC per un isolamento completo e l’adozione di DNS firewall. Questo implica un cambiamento importante di prospettiva: la sicurezza degli agenti AI non può più essere delegata al modello di default, ma richiede configurazioni esplicite e governance rigorosa.

LangSmith e il rischio account takeover: quando l’osservabilità diventa un punto debole

Se il caso Bedrock evidenzia problemi infrastrutturali, la vulnerabilità scoperta in LangSmith mostra come anche le piattaforme di osservabilità AI possano diventare vettori critici di compromissione.

La falla, identificata come CVE-2026-25750 con un punteggio CVSS di 8.5, deriva da una mancata validazione del parametro baseUrl, che consente un attacco di tipo URL injection. In pratica, un attaccante può costruire un link malevolo che induce la piattaforma a inviare dati sensibili verso un server controllato.

Il meccanismo è particolarmente insidioso perché richiede solo l’interazione dell’utente. È sufficiente che un utente autenticato clicchi su un link appositamente costruito per esporre token di accesso, identificativi utente e informazioni sul workspace.

Una volta ottenuto l’accesso, l’attaccante può entrare nel cuore delle operazioni AI. LangSmith gestisce infatti chiamate agli strumenti e flussi applicativi. Questo significa che l’attaccante può accedere a query SQL interne, dati CRM, log operativi e persino codice proprietario trasformando una vulnerabilità apparentemente semplice in un attacco ad alto impatto informativo.

La vulnerabilità è stata corretta nella versione 0.12.71 rilasciata a dicembre 2025, ma il caso evidenzia un tema strutturale: le piattaforme di AI observability stanno diventando infrastrutture critiche e, come tali, devono essere trattate con lo stesso livello di sicurezza dei sistemi core aziendali.

SGLang e la deserializzazione pericolosa: RCE senza autenticazione

Il terzo fronte riguarda SGLang, framework open source per l’esecuzione di modelli AI, dove sono state individuate vulnerabilità ancora più critiche, con punteggi CVSS fino a 9.8.

Il problema principale è legato alla gestione della deserializzazione tramite pickle, una funzione Python potente ma intrinsecamente pericolosa. In diversi componenti del framework, dati non fidati vengono deserializzati senza controlli adeguati, aprendo la strada a esecuzione di codice remoto.

Le vulnerabilità più gravi consentono remote code execution senza autenticazione attraverso il broker ZeroMQ, a condizione che l’attaccante possa raggiungere la porta di servizio. In questi scenari, è sufficiente inviare un payload malevolo per ottenere l’esecuzione di codice sul sistema target.

Un ulteriore problema riguarda strumenti di replay dei dump di crash, dove la deserializzazione non sicura può essere sfruttata per eseguire codice arbitrario. Anche se questo caso richiede un livello di accesso più elevato, contribuisce ad ampliare la superficie di attacco.

A differenza di LangSmith, queste vulnerabilità risultano non ancora patchate al momento della disclosure, aumentando il livello di rischio per le organizzazioni che utilizzano SGLang in ambienti esposti o non segmentati.

Condividi l'articolo