DeepSeek Harness CVE-2026-82533: un agente in sandbox disabilita la propria sandbox con un solo comando

VulnCheck ha pubblicato CVE-2026-82533 l'8 settembre 2026: un bypass critico dell'autenticazione che consentiva a un agente di codifica AI di disattivare la propria sandbox con un solo comando shell. Il software è DeepSeek Harness, il runtime locale open source di DeepSeek per gli agenti di codifica, che secondo la Cloud Security Alliance ha ottenuto circa 215.000 stelle GitHub in poche settimane; sono interessate tutte le versioni precedenti alla 0.1.2-alpha.1. Determinava se un chiamante fosse locale in base all'header Host fornito dal chiamante stesso, quindi una richiesta poteva dichiarare di provenire dal loopback. Poiché la sua sandbox limitava le scritture sui file ma non le comunicazioni di rete loopback, un agente confinato poteva chiamare l'API di controllo non autenticata dell'harness sulla porta 3080 e impostare la propria sessione su danger-full-access con le approvazioni disattivate. VulnCheck assegna un punteggio di 9,4, critico; non viene dichiarato alcuno sfruttamento in the wild. Il record è una voce in un dataset pubblico di incidenti AI, e l'Orca AI Incident Archive contiene l'insieme completo dei record, con date, livelli di gravità e fonti per ciascuna voce.

Il controllo che ha chiesto a una richiesta che cosa fosse

Il componente vulnerabile è l'API locale di controllo dell'agente dell'harness, il piccolo servizio HTTP che l'interfaccia web e la riga di comando usano per pilotare una sessione in esecuzione. Secondo la nota di ricerca della Cloud Security Alliance del 10 settembre 2026, che si basa sul resoconto di OX Security, l'azienda che ha scoperto la vulnerabilità, quel servizio era in ascolto per impostazione predefinita su 127.0.0.1 porta 3080 e prendeva la sua decisione di fiducia in una funzione che la nota chiama isTrustedApiRequest. La funzione leggeva l'header HTTP Host e concedeva l'accesso quando il valore corrispondeva a un nome di loopback come localhost o 127.0.0.1. Un header Host è un metadato scritto dal client; non dice nulla su da dove provenga la connessione TCP. The Hacker News, citando il sorgente interessato il 9 settembre 2026, riporta che il controllo non ha mai esaminato l'origine della connessione e che un commento nello stesso file afferma che il controllo "non è un livello di autenticazione".

Questo è l'intero CWE-807, l'affidamento su input non attendibili in una decisione di sicurezza, ed è ciò che descrive il record pubblicato da VulnCheck: un header Host di loopback fornito dal client accettato al posto della validazione dell'effettiva origine della connessione TCP.

Ciò che ha trasformato un controllo difettoso in una via di fuga è stato il fatto che l'harness consegnasse all'agente le proprie chiavi. The Hacker News riporta che l'harness passa alla shell dell'agente l'indirizzo dell'interfaccia di controllo e l'identificatore della sessione corrente, così un comando non deve scoprire né l'uno né l'altro. La sandbox, nel frattempo, copriva un canale e non l'altro: il riferimento da riga di comando per la versione interessata afferma che, con l'impostazione predefinita, le scritture restano all'interno dello spazio di lavoro e delle cartelle temporanee, mentre le letture e l'accesso alla rete non sono confinati.

Perché i prompt di approvazione non lo hanno fermato

L'harness aveva effettivamente dei prompt di approvazione, e più che essere aggirati erano inapplicabili. The Hacker News riporta che nella release interessata l'approvazione veniva richiesta solo quando un comando cercava un accesso più ampio di quello già detenuto dalla sessione. La chiamata di escalation non richiedeva nulla del genere; modificava l'impostazione della sessione. Un agente che l'ha eseguita è passato a una modalità che OX Security chiama danger-full-access, con i prompt di approvazione impostati su never, e ha continuato a essere eseguito come l'utente che aveva avviato l'harness, completamente al di fuori della sandbox.

Le prove di OX Security relative al confine consistevano in una coppia controllata. The Hacker News riporta che l'azienda ha eseguito due sessioni con impostazioni predefinite identiche e ha assegnato a entrambe lo stesso comando: la sessione che ha effettuato la chiamata ha scritto in una cartella al di fuori del proprio workspace, mentre l'altra è stata bloccata.

Il secondo percorso, e la precondizione di cui necessitava

La stessa verifica mancante ha esposto l'harness a soggetti chiamanti che non si trovavano affatto all'interno di una sandbox, ma solo in presenza di una condizione che la configurazione predefinita non creava. L'interfaccia a riga di comando rifiutava di associare l'API a tutte le interfacce di rete, quindi la porta era raggiungibile dall'esterno solo se un utente ne aveva già configurato l'inoltro — tramite un tunnel, un reverse proxy, un forward SSH o la funzionalità di port forwarding di un editor, secondo The Hacker News; la nota della Cloud Security Alliance elenca lo stesso insieme. Nei casi in cui tale precondizione era soddisfatta, afferma l'avviso di VulnCheck, un chiamante senza credenziali poteva creare sessioni, eseguire comandi arbitrari ed esfiltrare trascrizioni di conversazioni memorizzate. The Hacker News aggiunge che la stessa interfaccia gestiva una richiesta che scarica l'intero log di una sessione.

Il percorso sandbox richiede una precondizione diversa: testo che l'agente leggerà e su cui agirà. La nota della Cloud Security Alliance descrive un agente confinato che gestisce un prompt fornito dall'attaccante incorporato in un commento al codice, in un file README o nel testo di una issue. Nessuno dei due percorsi richiede una chiave rubata, e la nota osserva che il percorso remoto non necessita di alcuna interazione con il modello una volta che la porta è esposta.

La popolazione esposta è quindi chiunque abbia eseguito l'harness alla versione 0.1.1-rc.2 o precedente con le impostazioni predefinite, un insieme a cui il conteggio delle stelle accenna soltanto. The Hacker News ha contato più di 216.000 stelle il 9 settembre 2026 e ha avvertito che una stella è un segnalibro, non un'installazione.

Che cosa è stabilito e che cosa non lo è

Stabilito, dal record CVE stesso: VulnCheck è l'autorità di numerazione, ha riservato l'identificatore il 29 agosto 2026 e pubblicato il record l'8 settembre alle 16:59 UTC; la debolezza è CWE-807; l'intervallo interessato è ogni versione precedente a 0.1.2-alpha.1; e il credito va a Nir Zadok e Moshe Siman Tov Bustan. I due punteggi riportati dal record, 9.4 secondo CVSS 4.0 e 9.6 secondo CVSS 3.1, provengono da VulnCheck anziché da un secondo valutatore indipendente — NVD elenca entrambe le metriche con VulnCheck come fonte — quindi sono una sola valutazione espressa in due framework, non due valutazioni concordanti.

Stabilito dal repository: il commit di correzione 3e24087, intitolato "fix(web): authenticate the browser Host API", è datato 24 agosto 2026 e, secondo l'API di GitHub, aggiunge un modulo di autenticazione del browser insieme a 210 righe di test end-to-end per il nuovo flusso. La release con tag dsh-v0.1.2-alpha.1 è seguita il 27 agosto alle 17:06 UTC.

Non stabilito: utilizzo. Né il record CVE, né l'avviso di VulnCheck, né le note di rilascio di DeepSeek descrivono uno sfruttamento in the wild, e NVD registra la maturità dell'exploit come non definita. Il modello EPSS di FIRST ha assegnato alla vulnerabilità una probabilità di sfruttamento dell'1,24% nei successivi 30 giorni, al 68,9° percentile, nel feed datato 27 ottobre 2026. L'archivio non registra danni nel mondo reale per questa voce e la classifica con confidenza A, ben documentata, con fonti primarie concordi.

Le date, inclusi due rapporti che sono arrivati per primi

Due sviluppatori sono giunti alla stessa conclusione prima che ci fosse una CVE da indicare. The Hacker News riporta un post sulla bacheca di discussione del progetto stesso, il 13 agosto 2026, che mostra un processo ancora confinato dalla sandbox raggiungere l'interfaccia locale e passare la sessione a danger-full-access, con l'output dei test, e un secondo post il 14 agosto che elenca le richieste che quell'interfaccia ha accettato senza credenziali. Il secondo post osservava anche che il progetto non aveva alcun file di politica di sicurezza né un canale privato per segnalare una vulnerabilità; The Hacker News ha verificato il 9 settembre e ha scoperto che il file di politica di sicurezza era ancora assente.

La cronologia di OX Security colloca la sua segnalazione a VulnCheck il 24 agosto 2026, la stessa data che GitHub registra per il commit della correzione. Il messaggio del commit non dice nulla riguardo alla segnalazione, e il resoconto pubblico di OX Security, così come lo descrive The Hacker News, non menziona i post precedenti della community. Se i due eventi del 24 agosto fossero collegati è una cosa che il resoconto pubblico non afferma, e questo articolo non lo dà per scontato.

Il divario tra correzione e divulgazione non è insolito. La nota della Cloud Security Alliance registra che OX Security ha confermato la correzione il 30 agosto, nove giorni prima che VulnCheck pubblicasse il CVE.

Dove la correzione è stata applicata e dove no

Il tag GitHub e il registro dei pacchetti non si sono mossi insieme, ed è questa la parte che vale la pena conoscere se hai installato l'harness nel modo suggerito dalle sue istruzioni. Il pacchetto da riga di comando @deepseek-ai/dsh ha pubblicato la 0.1.1-rc.2 il 21 agosto 2026 e poi nulla fino alla 0.1.2-alpha.2 del 30 agosto. La versione 0.1.2-alpha.1, quella che il CVE indica come correzione, è del tutto assente dal registro, quindi la prima release corretta installabile è arrivata tre giorni dopo la correzione. I metadati del registro npm sono stati letti per questo articolo il 28 ottobre 2026; The Hacker News ha segnalato la stessa lacuna il 9 settembre.

Le note di rilascio non lo presentavano come un rilascio di sicurezza. Tra le modifiche di routine, elencano che l'interfaccia web ora richiede l'autenticazione tramite token monouso per l'accesso di rete, senza alcun riferimento CVE e senza alcun avviso di sicurezza, e The Hacker News non ha trovato alcun advisory di sicurezza nell'elenco degli advisory del repository il 9 settembre. Il meccanismo, come lo descrive la Cloud Security Alliance: l'harness stampa un token monouso all'avvio, il browser scambia quel token con un cookie firmato, e ogni chiamata successiva deve presentare il cookie — una fiducia vincolata a un segreto emesso all'avvio del processo anziché a un'origine di rete dichiarata.

Le build di terze parti sono il punto debole. I wrapper desktop distribuiscono una propria copia dell'harness, quindi la versione in uso a un utente è una scelta del manutentore del wrapper; The Hacker News ha trovato una build Windows bloccata alla 0.1.1-rc.2 a fine agosto, passata il 6 settembre alla 0.1.3-alpha.1, che contiene la correzione.

La sandbox stessa è invariata. Leggendo il riferimento della riga di comando di 0.1.2-rc.1, The Hacker News ha trovato la stessa affermazione secondo cui le operazioni di lettura e l'accesso alla rete non sono confinati, e ha scoperto che la shell dell'agente riceve ancora l'indirizzo dell'interfaccia. Nessuna fonte in quel resoconto afferma se un agente che lavora all'interno del proprio workspace possa ancora ottenere una sessione valida con il nuovo schema, una questione che la documentazione stessa della patch lascia aperta.

Cosa raccomandano le fonti del record

• Considera interessata qualsiasi installazione alla versione 0.1.1-rc.2 o precedente, indipendentemente da come è stata pacchettizzata, inclusa una copia incorporata in un wrapper desktop.

• Installa la versione 0.1.2-alpha.2 o successiva da npm; la versione più recente nel registry al 27 ottobre 2026 era 0.2.2-alpha.2.

• Se non puoi eseguire l'aggiornamento, arresta l'interfaccia web quando non è in uso e rimuovi qualsiasi tunnel, proxy o port forward che raggiunga la porta 3080.

Verifica se la porta 3080 è raggiungibile da qualsiasi altro punto oltre al loopback, inclusi port forwarding dei container, reverse proxy e tunnel SSH.

• Registra a livello di harness le escalation dei privilegi e le modifiche alla modalità di approvazione, perché l'attacco ha funzionato facendo sembrare un'escalation non autorizzata un'attività di routine.

Tutti e cinque provengono dalla nota della Cloud Security Alliance e dal resoconto di The Hacker News; il record CVE stesso non contiene indicazioni di remediation oltre alla versione corretta.

Perché la Cloud Security Alliance lo interpreta come un pattern

La nota della Cloud Security Alliance colloca questa CVE accanto ad altri due fallimenti di contenimento di agenti di coding che ha documentato nel 2026: GuardFall del 1° luglio, in cui dieci degli undici popolari agenti di coding open source poterono essere indotti a eseguire comandi shell che i loro guardrail erano progettati per bloccare, e le conclusioni sul passaggio di fiducia del 22 luglio, in cui un agente confinato scrisse un file che un componente fidato esterno alla sandbox eseguì successivamente. La nota è esplicita nel dire che tutti e tre derivano da una ricerca propria anziché da un'indagine esaustiva del mercato, e che non è stabilito se lo schema si generalizzi oltre gli agenti esaminati. Ciò che invece sostiene è che i fallimenti si collocano a livelli diversi — i guardrail dei comandi, la fiducia a valle e ora l'autenticazione del piano di controllo — ed è per questo che raccomanda di trattare l'architettura della sandbox come una questione di approvvigionamento anziché come un requisito soddisfatto.

La documentazione di sicurezza di DeepSeek non contraddice questa interpretazione. Il file SAFETY.md del repository afferma che il software «non è stato sottoposto a un audit di sicurezza e non deve essere considerato sicuro o pronto per la produzione» e che sandbox, richieste di approvazione e controlli dei permessi «non garantiscono l'isolamento né impediscono danni». La lacuna di autenticazione che consentiva a un agente di fuoriuscire tramite l'API di controllo è chiusa nelle build attuali. L'asimmetria che rendeva breve la fuga — un confine attorno alle scritture e nulla attorno alla rete — resta una limitazione dichiarata della sandbox anziché un difetto che la patch intendeva correggere.