Bypass della sandbox di DeepSeek Harness consente all'agente di evadere
Un bug di sicurezza in DeepSeek Harness, lo strumento open source per eseguire agenti di codifica AI sulla macchina di uno sviluppatore, ha permesso a un agente in sandbox di disattivare la propria sandbox dei file con un singolo comando. Lo strumento normalmente esegue i comandi di un agente all'interno di una sandbox del sistema operativo, un confine protettivo pensato per impedire a un agente che lavora su file non attendibili di scrivere al di fuori dell'area di lavoro assegnata. Su un'installazione predefinita, tuttavia, quell'agente poteva chiamare l'interfaccia web locale dello strumento sulla stessa macchina, cambiare la sua sessione in una modalità chiamata danger-full-access e quindi eseguire comandi al di fuori della sandbox senza alcuna richiesta di approvazione. Questo funzionava fino a quando DeepSeek ha corretto lo strumento il 27 agosto, e richiedeva testo fornito dall'attaccante che l'agente leggeva per indurlo a effettuare la chiamata. La falla è tracciata come CVE-2026-82533. VulnCheck, che ha assegnato l'identificatore, ha pubblicato il record l'8 settembre e ha valutato la falla 9.4 su 10.
OX Research, la società di sicurezza che ha segnalato la falla, ha affermato che un solo comando shell è stato sufficiente. Il comando invocava l'interfaccia locale dello strumento e impostava la sessione dell'agente su danger-full-access, che disattiva la sandbox e interrompe le richieste di approvazione. I comandi ordinari non necessitavano di approvazione fin dall'inizio. L'approvazione veniva applicata solo quando un comando richiedeva un accesso più ampio di quello che la sessione già possedeva, e questa chiamata non richiedeva un accesso più ampio; cambiava invece l'impostazione della sessione. OX ha detto di aver verificato che la sandbox funzionava prima dell'evasione. Ha eseguito due sessioni dalle stesse impostazioni predefinite e ha dato a entrambe lo stesso comando. La sessione che aveva effettuato la chiamata ha scritto in una cartella al di fuori della sua area di lavoro, e l'altra sessione è stata bloccata.
La sandbox copre solo i file. Il riferimento della riga di comando per la versione interessata afferma che con l'impostazione predefinita, le scritture rimangono all'interno dell'area di lavoro e delle cartelle temporanee, mentre 'letture e accesso alla rete non sono confinati'. Ciò ha lasciato l'interfaccia dello strumento raggiungibile dall'interno della sandbox. Lo strumento fornisce anche alla shell dell'agente l'indirizzo di quell'interfaccia e l'identificatore della sessione corrente, quindi l'agente non deve cercarli. L'interfaccia non aveva autenticazione. Nella versione interessata, il controllo che determinava se una richiesta poteva raggiungerla leggeva l'header Host della richiesta e non guardava mai da dove proveniva la connessione. Un commento in quel file dice che il controllo 'non è un livello di autenticazione'. Quel controllo è ciò che descrive il record CVE. Poiché si fidava di un header fornito dal client, una macchina esterna poteva dichiararsi locale e guidare l'agente. La riga di comando dello strumento rifiutava di ascoltare su tutte le interfacce di rete, quindi raggiungerla dall'esterno richiedeva che l'utente avesse inoltrato o proxyato la porta attraverso un tunnel, un forward SSH o un editor. La stessa interfaccia serviva una richiesta per scaricare l'intero log di una sessione. L'avviso di VulnCheck afferma che un chiamante che raggiunge l'interfaccia potrebbe recuperare tutte le conversazioni memorizzate senza una chiave.
Le versioni 0.1.1-rc.2 e precedenti sono interessate. Il record indica 0.1.2-alpha.1 come versione corretta, ma quella versione non è mai stata pubblicata sul registro npm, il catalogo online dei pacchetti dove le istruzioni del progetto stesso indirizzano gli utenti. La prima versione corretta su npm è stata 0.1.2-alpha.2, pubblicata il 30 agosto. La versione attuale su npm, 0.1.2-rc.1, contiene la correzione ed è stata pubblicata il 3 settembre. The Hacker News ha controllato il registro il 9 settembre e ha scoperto che la prima versione pubblicata con la modifica di autenticazione è 0.1.2-alpha.2, tre giorni dopo che la correzione è stata inviata su GitHub. Gli utenti dovrebbero installare 0.1.2-alpha.2 o versioni successive. Se hanno installato l'harness tramite un'app desktop di terze parti, dovrebbero controllare quale versione dell'harness include. Se non possono aggiornare, dovrebbero fermare l'interfaccia web quando non la usano e rimuovere qualsiasi tunnel, proxy o port forward che la raggiunge. Nessuna fonte esaminata per questo articolo offre un modo per fermare l'evasione dall'interno della sandbox su un'installazione locale predefinita mentre lo strumento è in esecuzione. Il rapporto del 13 agosto afferma che limitare l'indirizzo su cui lo strumento ascolta non aiuta, perché l'agente è già sulla stessa macchina.
La correzione fornisce all'interfaccia un controllo di identità. Lo strumento ora stampa un token monouso al suo indirizzo di avvio; il browser scambia quel token con un cookie firmato, e ogni chiamata all'interfaccia richiede il cookie. Ciò che la correzione non cambia è la sandbox. In 0.1.2-rc.1, lo stesso riferimento afferma ancora che letture e accesso alla rete non sono confinati, e la shell dell'agente riceve ancora l'indirizzo dell'interfaccia. Nessuna fonte affronta se un agente in esecuzione all'interno della sua area di lavoro possa ancora ottenere una sessione valida con il nuovo schema. Le build desktop di terze parti includono la propria copia dell'harness, e quale copia includono è scelta del manutentore del wrapper. Una build Windows aveva bloccato 0.1.1-rc.2 a fine agosto ed è passata a 0.1.3-alpha.1, che contiene la correzione, il 6 settembre. Chiunque abbia installato l'harness tramite un wrapper dovrebbe controllare quale versione include.
Un harness per agenti di codifica vale la pena di essere attaccato perché detiene una shell. DeepSeek Harness esegue i comandi di un agente sotto l'account che lo ha avviato. L'avviso di sicurezza del progetto stesso afferma che il software non ha subito un audit di sicurezza e che sandbox e richieste di approvazione 'non garantiscono l'isolamento o prevengono danni'. Dice agli utenti di non fare affidamento sullo strumento come unico controllo di sicurezza per lavori non attendibili. Il repository aveva più di 216.000 stelle il 9 settembre, un conteggio di account che lo hanno aggiunto ai segnalibri piuttosto che installazioni. I ricercatori hanno ripetutamente scoperto agenti di codifica che evadono le loro sandbox quest'anno, inclusa una serie di falle in cui la configurazione stessa di un repository faceva sì che gli agenti eseguissero codice dell'attaccante al di fuori delle loro sandbox.
Rapporti della comunità hanno descritto la stessa evasione in agosto sul forum di discussione di DeepSeek stesso. Il 13 agosto, uno sviluppatore ha pubblicato un rapporto che mostrava un processo ancora trattenuto dalla sandbox che raggiungeva l'interfaccia locale e poi cambiava la sessione in danger-full-access, con l'output del test. Il 14 agosto, un altro sviluppatore ha pubblicato un rapporto che elencava le richieste che l'interfaccia accettava senza alcuna credenziale. Quel secondo rapporto notava anche che il progetto non aveva alcun file di policy di sicurezza e nessun modo privato per segnalare una falla. Il progetto non ha ancora alcun file di policy di sicurezza. OX Research ha segnalato la falla a VulnCheck il 24 agosto, secondo la propria cronologia, e VulnCheck accredita Nir Zadok e Moshe Siman Tov Bustan. Il post di OX non menziona i rapporti precedenti. The Hacker News ha controllato l'elenco degli avvisi del repository il 9 settembre e non ha trovato alcun avviso di sicurezza pubblicato. La versione che conteneva la correzione la elenca tra le modifiche di routine, come la rimozione di un vecchio trasporto e la richiesta di 'autenticazione con token monouso per l'accesso alla rete', senza alcun avviso di sicurezza e senza menzione del CVE.
Per i team che eseguono agenti di codifica o ospitano applicazioni in produzione, AEU-I offre IT, infrastruttura e consulenza orientati alla sicurezza, un punto di partenza utile quando si rivede come strumenti come DeepSeek Harness vengono distribuiti e rafforzati. La protezione più immediata per i singoli utenti è aggiornare a una versione corretta, verificare le build dei wrapper e rimuovere qualsiasi percorso che espone l'interfaccia locale mentre lo strumento è in esecuzione.