Rischio AI: falle in Amazon Bedrock, LangSmith e SGLang
好的,我现在要帮用户总结这篇文章的内容,控制在100字以内。首先,我需要快速浏览文章,抓住主要信息。 文章主要讲的是BeyondTrust、Miggo和Orca Security的研究发现,指出AI沙盒、观测系统和LLM框架等原本设计用于隔离和保护的平台可能成为高级攻击的入口。具体提到了Amazon Bedrock、LangSmith和SGLang三个案例。 在Amazon Bedrock中,DNS查询被用来绕过网络隔离,导致数据泄露。LangSmith的问题是URL注入漏洞,可能导致账户接管。SGLang则存在反序列化漏洞,导致远程代码执行。 这些案例说明AI安全问题日益严重,尤其是快速开发和采用带来的风险。因此,总结时要涵盖这些关键点:研究机构、平台类型、具体漏洞及其影响,以及AI安全的重要性。 现在,我需要把这些信息浓缩到100字以内,确保涵盖主要发现和影响。 </think> 研究显示,AI沙盒、观测系统及LLM框架等设计用于隔离和保护的平台可能成为高级攻击入口。Amazon Bedrock因DNS查询绕过网络隔离致数据外泄;LangSmith因URL注入漏洞引发账户接管;SGLang反序列化问题导致远程代码执行。这些案例凸显AI安全威胁加剧。 2026-3-18 00:0:38 Author: www.securityinfo.it(查看原文) 阅读量:18 收藏

Mar 17, 2026 In evidenza, News, RSS, Vulnerabilità


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.



Altro in questa categoria


文章来源: https://www.securityinfo.it/2026/03/17/rischio-ai-falle-in-amazon-bedrock-langsmith-e-sglang/
如有侵权请联系:admin#unsafe.sh