DeepSeek evade la sandbox, token AI bypassano MFA e 36.000 Plex restano esposti

🛡️ Executive Summary

• DeepSeek Harness corregge CVE-2026-82533, falla CVSS 9.4 che permetteva a un agente AI di disattivare la propria sandbox.
• Log infostealer espongono migliaia di token ancora validi per servizi AI e cloud, riutilizzabili anche dopo autenticazione MFA.
• Alby Hub chiude una falla di takeover sui wallet esposti, mentre oltre 36.000 Plex Media Server risultano ancora senza aggiornamento.

Agenti AI capaci di rimuovere autonomamente la propria sandbox, token di sessione rubati dagli infostealer che restano riutilizzabili dopo l’MFA, wallet Bitcoin self-hosted esposti a takeover e oltre 36.000 server Plex ancora senza patch. Le nuove disclosure del 9 settembre mostrano quattro declinazioni dello stesso problema: il confine di sicurezza non coincide più necessariamente con password e autenticazione. Nei nuovi stack, una sessione già autorizzata, un’API locale, una console amministrativa o un server dimenticato su Internet possono diventare il punto di ingresso. Il caso più critico riguarda DeepSeek Harness, dove una singola istruzione indotta attraverso contenuto non fidato poteva consentire all’agente di disabilitare il controllo progettato proprio per contenerlo.

DeepSeek Harness permetteva all’agente di disattivare la propria sandbox

CVE-2026-82533, valutata CVSS 9.4, colpisce DeepSeek Harness, il framework open source utilizzato per eseguire agenti AI di coding sulla macchina dello sviluppatore. Secondo l’analisi tecnica di OX Research, l’interfaccia HTTP locale che controllava l’agente non richiedeva autenticazione e decideva se fidarsi di una richiesta attraverso l’header Host, fornito dallo stesso client. La sandbox impediva le scritture fuori dal workspace ma lasciava disponibile il networking loopback: un agente indotto da testo controllato dall’attaccante poteva quindi richiamare la stessa API di Harness, modificare la sessione in danger-full-access e impostare la policy di approvazione su never. I comandi successivi venivano eseguiti fuori dalla sandbox senza ulteriori conferme dell’utente. Le versioni 0.1.1-rc.2 e precedenti sono vulnerabili; la correzione è stata introdotta nel codice con 0.1.2-alpha.1, mentre la prima release corretta pubblicata su npm è stata 0.1.2-alpha.2.

Il problema è particolarmente rilevante perché un coding agent opera con l’autorità ambientale della workstation dello sviluppatore: repository, chiavi SSH, credenziali cloud e servizi raggiungibili dalla macchina possono trovarsi a una sola escalation di distanza. La dinamica si inserisce direttamente nel filone degli agenti AI che riescono a trasformare repository e configurazioni locali in percorsi verso l’esecuzione di codice, mentre il recente caso OpenAI sulle tecniche documentate per uscire dalle sandbox mostra quanto il problema del contenimento sia diventato strutturale quando un modello dispone direttamente di una shell.

Leggi anche: Agenti AI fuori controllo colpiscono sistemi reali e workflow GitHub

Gli infostealer trasformano i token AI in chiavi riutilizzabili

Sul fronte dell’identità, una ricerca di Okta Threat Intelligence mostra come i normali log degli infostealer stiano diventando archivi di accesso agli account AI. L’analisi condotta su 5.871 macchine infette distribuite in 162 Paesi ha individuato 9.829 token Google, dei quali 9.213 ancora validi alla data di pubblicazione del dataset, oltre a 2.491 token Microsoft, 561 Anthropic e credenziali di sessione per Amazon, Cursor, Notion, Poe e altri servizi. Il punto non è il furto della password: un token di autenticazione ancora valido può permettere all’attaccante di riprodurre la sessione già autenticata, rendendo inefficace l’MFA perché il secondo fattore è stato superato nel momento in cui il token originale è stato emesso.

La tecnica amplia un problema già visibile nelle campagne che abusano OAuth, Device Code e token legittimi invece di attaccare direttamente la password. Google Threat Intelligence Group osserva inoltre che gli operatori di LummaC2, StealC, Vidar e ACRStealer stanno cercando esplicitamente configurazioni degli strumenti AI per sviluppatori, compresi file che possono contenere API key in chiaro e endpoint personalizzati dei modelli. Il nuovo AI Threat Tracker di Google descrive quindi un passaggio dal semplice furto di cookie browser alla ricerca mirata di identità AI e segreti infrastrutturali. È una naturale estensione di quanto già visto con RedC2, che combina AI, furto di credenziali e pivoting dalle workstation Linux.

Alby Hub esponeva al takeover i wallet pubblicati su Internet

Un rischio molto più diretto riguarda Alby Hub, wallet self-hosted per Bitcoin e Lightning Network. Il vendor ha avvertito che una vulnerabilità critica interessa le versioni comprese tra 1.7.0 e 1.18.5 quando la console del wallet è raggiungibile da Internet. In questa configurazione un attaccante poteva arrivare al takeover del wallet e autorizzare pagamenti, con almeno un utente risultato coinvolto secondo la società. Alby non ha ancora pubblicato i dettagli tecnici completi per evitare di facilitare lo sfruttamento delle installazioni non aggiornate, ma indica che 1.19.0 e successive non sono vulnerabili e raccomanda comunque l’upgrade alla release corrente 1.24.0. Chi ha esposto un’installazione vulnerabile dovrebbe prima rimuovere l’accesso pubblico alla management interface, aggiornare e successivamente modificare la password di sblocco

.Il caso è particolarmente delicato perché Alby Hub è self-custodial: secondo la documentazione del progetto, il seed viene cifrato attraverso la password di unlock ma deve essere decifrato in memoria quando il nodo Lightning è operativo. La vulnerabilità riporta quindi l’attenzione sulla differenza tra sovranità della custodia e sicurezza dell’hosting: controllare personalmente le chiavi elimina il custodian centrale, ma trasferisce sull’utente la responsabilità di rete, aggiornamenti, firewall ed esposizione della console amministrativa.

Oltre 36.000 Plex Media Server restano senza aggiornamento

Il quarto problema è più tradizionale ma numericamente molto più esteso. Plex aveva chiesto il 1° settembre agli utenti di aggiornare immediatamente Plex Media Server 1.43.2 e precedenti e Plex Desktop, senza ancora pubblicare dettagli tecnici sulle vulnerabilità corrette. L’avviso ufficiale di Plex indica come versioni sicure Plex Media Server 1.43.3 o successive e Plex Desktop 1.115.0 o successive, raccomandando agli utenti NAS di installare manualmente il pacchetto quando il repository del produttore non offre ancora la nuova build.

A distanza di alcuni giorni, le scansioni di Shadowserver individuano però oltre 36.000 istanze Plex esposte su Internet ancora non aggiornate. Le vulnerabilità non hanno ancora un identificativo CVE pubblico, circostanza che rende più difficile il monitoraggio centralizzato e riduce la visibilità nei normali strumenti di vulnerability management. Il precedente è tutt’altro che teorico: Plex ha già avuto vulnerabilità sfruttate per ottenere accesso remoto e un vecchio bug del Media Server è stato collegato alla catena che consentì agli aggressori di compromettere un ingegnere LastPass. La situazione attuale era già stata anticipata dal primo avviso urgente con cui Plex aveva chiesto di aggiornare Media Server e Desktop anche sui NAS.

Continua con:

• Chrome zero-day, WordPress sotto exploit e Plex: l’esposizione dei servizi Internet resta il nodo centrale
• Gitea entra nel KEV e gli agenti AI aprono nuove vie all’esecuzione di codice

La nuova superficie critica è ciò che resta già autenticato

I quattro casi condividono una caratteristica più importante delle singole CVE. DeepSeek Harness si fidava della propria interfaccia locale, gli account AI si fidano di token già emessi, Alby Hub diventa pericoloso quando una console amministrativa privata viene esposta e Plex mostra quanto una patch serva poco finché migliaia di server restano indietro. In ognuno di questi scenari la barriera iniziale esiste, ma viene aggirata sfruttando qualcosa che il sistema considera già affidabile. Per i team di sicurezza la risposta deve quindi estendersi oltre password e patch: revoca delle sessioni dopo infezioni da infostealer, rotazione delle API key, sandbox realmente isolate dalla superficie di controllo, console amministrative non pubblicate direttamente su Internet e inventario delle versioni esposte. Gli agenti AI rendono questa impostazione ancora più urgente perché dispongono di strumenti, rete e capacità di eseguire comandi con una velocità incompatibile con controlli basati esclusivamente sulla conferma umana. La nuova superficie d’attacco non è soltanto ciò che un aggressore riesce ad aprire. Sempre più spesso è ciò che trova già aperto e autorizzato.