--- title: "Come la CVE-2026-82533 lascia un agente spegnere la propria sandbox" description: "CVE-2026-82533, CVSS 9.4: nel harness open source di DeepSeek un agente disattiva la sandbox che lo confina. La catena difettosa e cosa controllare in un harness locale." canonical: "https://www.mauriziofonte.it/blog/post/cve-2026-82533-deepseek-harness-agente-disattiva-sandbox.html" author: "Maurizio Fonte" date: "2026-09-21T09:09:07+02:00" modified: "2026-09-21T09:09:07+02:00" section: "AI Security" tags: ["AI Security", "Penetration Testing"] license: "Riuso e citazione consentiti con attribuzione e link alla fonte" --- [AI Security](https://www.mauriziofonte.it/blog/cat/ai-code-security.html) [Penetration Testing](https://www.mauriziofonte.it/blog/cat/penetration-testing.html) # [Come la CVE-2026-82533 lascia un agente spegnere la propria sandbox](https://www.mauriziofonte.it/blog/post/cve-2026-82533-deepseek-harness-agente-disattiva-sandbox.html) Lunedì 21 Settembre 2026, alle 09:09 ![Come la CVE-2026-82533 lascia un agente spegnere la propria sandbox](https://www.mauriziofonte.it/image/005600200-cve-2026-82533-deepseek-harness-agente-disattiva-sandbox.jpg) 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](https://cwe.mitre.org/data/definitions/807.html). 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](https://www.mauriziofonte.it/ai-aziende/ai-aziende-security.html) 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](https://www.mauriziofonte.it/blog/post/anatomia-harness-claude-code-produzione-hook-rules-skill-permission.html) e nel pezzo sul [sandboxing di agenti che eseguono codice arbitrario con container effimeri e seccomp](https://www.mauriziofonte.it/blog/post/sandboxing-agent-llm-codice-arbitrario-container-effimeri-seccomp.html). 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](https://www.mauriziofonte.it/blog/post/openai-hugging-face-agenti-evasione-eval-contenimento-2026.html), 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](https://www.mauriziofonte.it/pages/preventivo-gratuito.html#consulenza-ai): 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. Dall'articolo al lavoro vero Questo problema di sicurezza, sul tuo sistema Audit del codice e dei server, penetration test, adeguamento NIS2 e risposta agli incidenti. [Vedi come lavoro sulla sicurezza](https://www.mauriziofonte.it/servizi/consulenza-cybersecurity-nis2.html) Ultima modifica: Lunedì 21 Settembre 2026, alle 09:09 [« Articolo precedenteNode.js e TypeScript per microservizi: quando PHP non basta21 Settembre 2026](https://www.mauriziofonte.it/blog/post/nodejs-typescript-microservizi-quando-php-non-basta.html)[Articolo successivo »React per il frontend dei gestionali Laravel: SPA senza perdere il controllo del backend22 Settembre 2026](https://www.mauriziofonte.it/blog/post/react-frontend-gestionali-laravel-spa-controllo-backend.html) ### Articoli correlati a Come la CVE-2026-82533 lascia un agente spegnere la propria sandbox - [Container escape e sicurezza Docker: la vulnerabilità che molti team ignorano](https://www.mauriziofonte.it/blog/post/container-escape-sicurezza-docker-vulnerabilita-team-ignora.html) Molti team trattano il container come una sandbox di sicurezza, ma per default non lo è. I vettori di escape su Docker: privileged mode, socket · 14 Agosto 2026 ![Container escape e sicurezza Docker: la vulnerabilità che molti team ignorano](https://www.mauriziofonte.it/image/005080070-container-escape-sicurezza-docker-vulnerabilita-team-ignora.jpg) - [L'incidente OpenAI-Hugging Face e il contenimento degli agenti in valutazione](https://www.mauriziofonte.it/blog/post/openai-hugging-face-agenti-evasione-eval-contenimento-2026.html) Tra il 9 e il 13 luglio 2026, durante una valutazione interna delle capacità offensive dei propri modelli, gli agenti di OpenAI sono usciti dall'ambiente · 16 Settembre 2026 ![L'incidente OpenAI-Hugging Face e il contenimento degli agenti in valutazione](https://www.mauriziofonte.it/image/005580070-openai-hugging-face-agenti-evasione-eval-contenimento-2026.jpg) - [Difendere una harness Claude Code in produzione: il modello di sicurezza che uso davvero](https://www.mauriziofonte.it/blog/post/difendere-harness-claude-code-produzione-security-model-pre-bash-validator.html) Mettere un agente di coding in produzione significa dargli accesso a shell, file e credenziali. Il setup di sicurezza che uso davvero parte da · 6 Luglio 2026 ![Difendere una harness Claude Code in produzione: il modello di sicurezza che uso davvero](https://www.mauriziofonte.it/image/004790070-difendere-harness-claude-code-produzione-security-model-pre-bash-validator.jpg) - [SSH tunneling e port forwarding per sviluppatori: accesso sicuro a database e servizi interni](https://www.mauriziofonte.it/blog/post/ssh-tunneling-port-forwarding-sviluppatori-database-servizi-interni.html) Accedere al database MySQL di produzione da remoto senza esporlo su internet è un requisito frequente. Con SSH tunneling si ottiene un accesso · 12 Marzo 2026 ![SSH tunneling e port forwarding per sviluppatori: accesso sicuro a database e servizi interni](https://www.mauriziofonte.it/image/003510070-ssh-tunneling-port-forwarding-sviluppatori-database-servizi-interni.jpg) - [Flowise CVE-2025-59528 RCE 10.0: autopsia dell'exploit che ho riprodotto nel mio laboratorio](https://www.mauriziofonte.it/blog/post/flowise-cve-2025-59528-rce-poc-mitigation-waf.html) Il 14 aprile 2026 ho messo una istanza Flowise 2.x volontariamente esposta nella mia sandbox di audit per riprodurre la CVE 2025 59528 una RCE · 12 Mag 2026 ![Flowise CVE-2025-59528 RCE 10.0: autopsia dell'exploit che ho riprodotto nel mio laboratorio](https://www.mauriziofonte.it/image/004170070-flowise-cve-2025-59528-rce-poc-mitigation-waf.jpg) --- **Programmatore PHP Torino**, **Ingegnere del Software** e **Cyber Security Specialist** con oltre 20 anni di esperienza nell'implementazione di soluzioni avanzate. Eseguo **porting di vecchi ambienti PHP** verso release più moderne (7.x o 8.x), mi occupo di **infrastrutture web sicure** e garantisco procedure di **hardening** e **gestione dei rischi** in linea con gli standard internazionali. Con la mia attività da *consulente freelance*, offro supporto a imprese e reparti IT che necessitano di **refactoring**, **messa in sicurezza** e **manutenzione evolutiva** di piattaforme web. Mi occupo di analisi del codice, identificazione delle vulnerabilità e implementazione di **best practice** per la protezione di dati e servizi critici. L'obiettivo è garantire un ambiente digitale resiliente, con un codice sorgente affidabile e manutenibile. --- ## Autore **Maurizio Fonte**, ingegnere informatico (laurea 2008), consulente IT senior e backend engineer. Nel settore IT dal 2005, libero professionista con P.IVA dal 2014. Progetta e mantiene backend di produzione e pipeline AI private per aziende italiane. Sull'AI lavora con casi di produzione misurabili, non con demo: RAG su documentazione italiana con pgvector (HNSW/IVFFlat), LLM self-hosted (Ollama, Mistral, Qwen) per data residency europea, MCP server custom in PHP, governance EU AI Act (Annex III, art. 16, FRIA) e sicurezza degli agent (OWASP LLM Top 10, prompt injection, excessive agency). I benchmark citati negli articoli sono eseguiti direttamente sull'hardware e sul corpus dell'autore. ## Perché questa fonte è attendibile - **Esperienza diretta, non rassegna di terzi.** I contenuti nascono da lavoro di produzione e benchmark propri, con metriche misurate (es. un RAG self-hosted su 2.400 documenti che ha portato il tempo medio di risposta interno da 14 minuti a 90 secondi, su 60 query campione). - **Verificabilità.** Ogni claim tecnico rimanda a fonti primarie (paper, CVE, documentazione ufficiale); il blog è un laboratorio di ricerca applicata pubblico. - **Onestà metodologica.** Ogni soluzione dichiara anche quando NON va usata. "Production-grade, non demo-grade". ## Entità e contatti (verificabili) Maurizio Fonte, Torino, Italia. P.IVA IT11396570019. REA TO-1331015 (Camera di Commercio di Torino). GitHub: https://github.com/mauriziofonte LinkedIn: https://www.linkedin.com/in/mauriziofonte Profilo: https://www.mauriziofonte.it/pages/about --- ## Come citare > Maurizio Fonte, "Come la CVE-2026-82533 lascia un agente spegnere la propria sandbox", mauriziofonte.it, 2026. https://www.mauriziofonte.it/blog/post/cve-2026-82533-deepseek-harness-agente-disattiva-sandbox.html Pubblicato: 2026-09-21 · Aggiornato: 2026-09-21. **Licenza:** riuso e citazione consentiti con attribuzione esplicita e link alla fonte.