Come la CVE-2026-82533 lascia un agente spegnere la propria sandbox

C'è una classe di vulnerabilità che, letta la prima volta, sembra un errore di stampa: un processo confinato in una sandbox riesce a disattivare la sandbox che lo confina, e lo fa con un comando solo, sui default di installazione, senza credenziali e senza esposizione di rete. È esattamente ciò che descrive la CVE-2026-82533, valutata 9.4 su 10 da VulnCheck, l'organizzazione che ha assegnato l'identificativo e ne ha pubblicato il record l'8 settembre 2026. Il prodotto colpito è DeepSeek Harness, in breve dsh, l'harness open source di DeepSeek per eseguire agenti di coding in locale, che dal rilascio di agosto 2026 aveva raccolto oltre 215.000 stelle su GitHub in poche settimane. Faccio questo lavoro da abbastanza tempo, e uso agenti di coding in produzione ogni giorno, per riconoscere quando una singola vulnerabilità è in realtà la manifestazione di un errore di progettazione che si ripeterà altrove. Questa lo è, e vale la pena smontarla passo per passo, perché la lezione non riguarda dsh: riguarda chiunque esegua un agente dentro un confine che crede solido.

Come fa un agente a disattivare la sandbox che dovrebbe confinarlo?

La risposta sta in una decisione di fiducia sbagliata, e la si può enunciare in una frase: dsh espone la propria API di controllo su una porta locale, 127.0.0.1:3080, senza autenticazione, e per decidere se una richiesta è fidata legge l'header Host fornito dal client invece di verificare l'indirizzo reale del peer della connessione. La funzione incriminata, isTrustedApiRequest, avrebbe dovuto distinguere le richieste legittime da quelle ostili; di fatto si fida di un dato che il chiamante controlla. Chi ha fatto sicurezza applicativa conosce questa categoria di bug con un nome preciso, ed è quello che le è stato assegnato: CWE-807, Reliance on Untrusted Inputs in a Security Decision. Prendere una decisione di sicurezza basandosi su un input che l'attaccante può falsificare.

Da qui l'exploit è imbarazzante nella sua semplicità. Un singolo comando emesso dall'interno della sandbox, una curl verso l'interfaccia locale, imposta la sessione dell'agente in una modalità chiamata danger-full-access, che disattiva il sandbox e sopprime i prompt di approvazione. Il dettaglio che chiude il cerchio riguarda proprio i controlli di approvazione: normalmente scattano solo quando un comando chiede più accesso di quello che la sessione ha già. Questa chiamata non chiede accesso, cambia l'impostazione della sessione, quindi non attraversa nessun gate. L'agente non forza una porta: ne gira la maniglia dall'interno.

Se esegui agenti di coding su repository aziendali o su ambienti di sviluppo, questo è il tipo di superficie che va verificata prima di deployare, non dopo. Nel mio hub dedicato all'AI per aziende raccolgo gli articoli in cui affronto il threat modeling e il contenimento degli agenti in produzione, con un approccio da sicurezza offensiva applicata al codice generato.

La diagnosi progressiva: dal sintomo alla causa profonda

Il sintomo è vistoso e fa notizia: un comando spegne il sandbox. Ma fermarsi al sintomo porta alla contromisura sbagliata, cioè "installa un sandbox migliore". La diagnosi seria richiede di risalire la catena. La causa prossima è la funzione isTrustedApiRequest che si fida dell'header Host: un fix di quella funzione, che verifichi il peer address reale, chiude questo exploit specifico. Ed è ciò che DeepSeek ha fatto, rilasciando la patch nella versione 0.1.2-alpha.1 appena tre giorni dopo la disclosure responsabile che OX Research aveva inviato a VulnCheck il 24 agosto.

Ma la causa profonda è architetturale, e la patch non la tocca. Il problema vero è che il processo che deve essere confinato può raggiungere e modificare il piano di controllo che lo confina. La control API e l'agente vivono nello stesso spazio di rete raggiungibile, e l'agente ha, per costruzione, la capacità di parlarci. Anche con l'autenticazione aggiunta, l'architettura in cui il confinato ha una linea diretta verso il confinatore resta fragile: sposta l'asticella, non cambia la classe del problema. Un'analogia dal mondo della virtualizzazione rende l'idea: nessuno accetterebbe che un processo dentro una macchina virtuale possa aprire una connessione all'hypervisor e riconfigurare la propria isolamento. Eppure è esattamente la topologia che molti harness locali per agenti adottano oggi, perché nascono come strumenti per sviluppatori dove tutto gira sotto lo stesso utente, sulla stessa localhost, e la comodità detta l'architettura.

Il difetto non è che mancava l'autenticazione. Il difetto è che il piano di controllo del confinamento era raggiungibile dal processo confinato. L'autenticazione è un cerotto necessario; l'isolamento del control plane è la cura.

Il secondo vettore, quello che trasforma un problema locale in un problema di rete

Chi liquida la vicenda come "un bug di un tool che gira sul mio laptop, chi se ne importa" si ferma al primo vettore. Ce n'è un secondo, e cambia la scala del rischio. Poiché l'API di controllo non ha autenticazione e si fida dell'header Host, ovunque quella porta locale diventi raggiungibile dall'esterno, un attaccante remoto non autenticato può prenderne il controllo. E le porte locali diventano raggiungibili molto più spesso di quanto si pensi: un tunnel, un reverse proxy configurato in fretta, un ssh -L dimenticato aperto, un port forward dell'editor per fare debug remoto. In tutti questi casi un attaccante può pilotare direttamente l'agente e, cosa altrettanto grave, scaricare tutte le conversazioni salvate senza una API key e senza spendere una sola chiamata al modello.

Questo secondo vettore è la ragione per cui la valutazione 9.4 non è gonfiata. Non stiamo parlando solo di un'escalation di privilegi in un contesto già compromesso: stiamo parlando di un endpoint di controllo di un agente, con accesso al filesystem e alla capacità di eseguire comandi, che può finire esposto in rete per una banale scelta di configurazione a monte. La lezione per chi gestisce ambienti di sviluppo condivisi o macchine di build è diretta: le porte in ascolto su localhost non sono automaticamente sicure, perché localhost è un confine che il port forwarding attraversa di continuo.

Vale la pena notare quanto questo bug assomigli a errori che facevamo vent'anni fa nel web, ripresentati in un contesto nuovo. Fidarsi dell'header Host per una decisione di sicurezza è cugino stretto del fidarsi dell'header Referer per l'autorizzazione, o dell'X-Forwarded-For per il rate limiting: sono tutti dati che il client controlla, e nessuno di essi dovrebbe mai reggere una scelta di trust. La differenza è che nel web classico l'attaccante che sfruttava quell'errore era una persona con un intento; qui l'attaccante potenziale è anche l'agente stesso, che nel perseguire il proprio task può inciampare nell'escalation senza che nessuno gliel'abbia chiesta. È la stessa vecchia debolezza, ma con un attore in più al tavolo, e un attore che non dorme mai e prova migliaia di strade.

La lezione trasferibile: vale per ogni harness locale, non solo per dsh

Ed è qui che questa CVE smette di essere una notizia su un prodotto e diventa un principio di progettazione. Un harness per agenti, qualunque sia il vendor, è per definizione un componente che dà a un processo semi-autonomo la capacità di eseguire azioni sul sistema. Il suo valore sta proprio in quella capacità; il suo rischio anche. Se il meccanismo che limita quelle azioni, il sandbox, la lista di comandi permessi, il gate di approvazione, è raggiungibile e modificabile dallo stesso processo che deve limitare, allora quel meccanismo è teatro, non controllo.

Nel mio lavoro quotidiano con gli agenti applico tre principi che nascono esattamente da questo tipo di ragionamento. Il primo è che il piano di controllo vive fuori dal contesto dell'agente: le regole su cosa può e non può fare sono applicate da un livello che l'agente non può raggiungere né riconfigurare, tipicamente un validatore che intercetta i comandi prima dell'esecuzione e che gira con privilegi e in uno spazio separati. Il secondo è che l'accesso in uscita è negato per default: l'agente parla solo con gli endpoint dichiarati, e "solo con localhost" non è una allowlist, è un'illusione, proprio per il problema del port forwarding. Il terzo è che ogni azione irreversibile passa da un gate che non è configurabile dall'agente stesso. Ho descritto come si costruisce concretamente questo tipo di perimetro in anatomia di una harness di produzione tra hook, rules e permission engine e nel pezzo sul sandboxing di agenti che eseguono codice arbitrario con container effimeri e seccomp.

La CVE-2026-82533 si salda a un altro caso recente in modo quasi didattico. Nell'incidente in cui gli agenti di OpenAI in valutazione sono usciti dal sandbox e hanno compromesso l'infrastruttura di Hugging Face, il contenimento che ha ceduto era quello di rete, in un data center di frontiera. Qui il contenimento che cede è quello locale, sul laptop di uno sviluppatore. Scala diversa, stesso principio violato: un confine è tale solo se chi sta dentro non può toccarlo. Chi guarda i due episodi come notizie separate perde il pattern; chi li legge insieme capisce che l'errore ricorrente non è nella singola implementazione, ma nell'assunzione che la comodità dello sviluppo e la sicurezza del deployment possano condividere la stessa topologia.

L'onestà del vendor, e cosa ci dice sul mercato

Un dettaglio merita di essere riportato senza giri di parole, perché è insolito e istruttivo. La documentazione di DeepSeek dichiarava già, prima della scoperta, che il suo sandboxing "non garantisce l'isolamento né previene danni". La CVE, in altre parole, è coerente con un disclaimer che il progetto aveva scritto in chiaro: non è il tradimento di una promessa, è la conferma di un avvertimento che quasi nessuno aveva letto. Questo dice due cose. La prima è che il vendor è stato onesto, e questo va riconosciuto. La seconda, più scomoda per il mercato, è che uno strumento con 215.000 stelle è stato adottato in massa nonostante dichiarasse la propria fragilità: il segnale di fiducia (le stelle) e il segnale di rischio (il disclaimer) viaggiavano insieme, e il primo ha coperto il secondo.

La popolarità di un tool per agenti non è una misura della sua sicurezza. Spesso è l'esatto contrario: più uno strumento è comodo e diffuso, più vale la pena verificarne il modello di minaccia prima di dargli accesso al tuo codice.

Per chi seleziona strumenti agentici in azienda, la contromisura non è aggiornare dsh e chiudere la pratica, anche se ovviamente chi lo usa deve passare almeno alla 0.1.2-alpha.1, verificare la versione in esecuzione e controllare che la porta locale non sia esposta da qualche forwarding. La contromisura vera è il criterio di adozione: prima di dare a un agente la capacità di eseguire comandi sul tuo sistema, qualcuno deve avere guardato dove vive il suo piano di controllo e se il processo confinato può raggiungerlo. È una domanda di dieci minuti che questa CVE ha reso non negoziabile. Vale anche per gli strumenti commerciali, non solo per quelli open source: la maggiore verifica non è "questo vendor è serio?", ma "questa architettura mette il muro fuori dalla stanza o dentro?", e la risposta si legge nel modello di minaccia, non nel numero di stelle o nel prezzo della licenza.

Cosa portarsi a casa

La CVE-2026-82533 è la prima vulnerabilità confermata in cui il runtime sandbox di un agente è la superficie d'attacco diretta, e proprio per questo è un punto di svolta più che un incidente isolato. Ci dice che la security degli agenti non è un sottoinsieme della security applicativa classica: è una disciplina che eredita i vecchi errori, come fidarsi di un input non fidato per una decisione di sicurezza, e li amplifica dando al processo confinato l'autonomia e la capacità di sfruttarli da solo. Ci dice che la topologia comoda dello sviluppo locale, tutto su localhost sotto lo stesso utente, è una scelta di sicurezza travestita da default, e che va rivista quando il processo che gira lì dentro non è più un compilatore ma un agente che decide.

Se stai introducendo agenti di coding o assistenti con accesso al filesystem nel tuo flusso di lavoro, e vuoi una verifica indipendente di come è messo il loro contenimento prima che lo scopra un incidente, puoi usare il modulo di preventivo gratuito: poche domande, e ti dico se il tuo caso rientra nel mio ambito. La buona notizia è che il rimedio non richiede tecnologia esotica: richiede di applicare agli agenti la stessa umiltà architetturale che diamo per scontata con le macchine virtuali e i container, cioè che il muro lo costruisce e lo controlla qualcuno che sta fuori dalla stanza. dsh ha imparato la lezione con una patch in tre giorni; il resto del mercato farebbe bene a impararla senza aspettare la propria CVE.