Cosa ha raggiunto un solo messaggio
Il 23 luglio la società di sicurezza Accomplish ha reso nota una falla che ha chiamato SharedRoot. Il suo ricercatore principale, Oren Yomtov, ha descritto la prova con sobrietà: hanno collegato una cartella a una sessione nuova di Claude Cowork, inviato un breve messaggio e visto l'agente uscire dalla sandbox.
Claude Cowork esegue il suo agente dentro una macchina virtuale Linux sul Mac, costruita sul framework di virtualizzazione di Apple. Ogni sessione riceve un utente senza privilegi e un filtro sulle chiamate di sistema, ciò che dà peso alla parola sandbox. Il problema non era la scatola. Era ciò che la scatola poteva vedere.
L'intero file system dell'host era montato in quella macchina con accesso in lettura e scrittura. Dall'interno, l'agente ha raggiunto chiavi SSH, credenziali cloud, chiavi API, repository di codice e tutto il resto che l'account collegato poteva toccare. Secondo il conteggio della società, circa 500.000 persone avevano eseguito Cowork in locale prima che l'esposizione fosse risolta.
Perché non è arrivata una patch
Anthropic ha ricevuto il rapporto e lo ha chiuso come informativo. Nel linguaggio dei programmi di ricompensa per le falle, è un riconoscimento senza una patch dedicata, e l'azienda lo ha collocato nella finestra di trenta giorni che il suo programma riserva a questi casi.
La sua risposta è stata architetturale, non correttiva. La versione attuale di Cowork esegue l'agente per impostazione predefinita nel cloud di Anthropic, e i ricercatori concordano che questa via di fuga locale non sembra applicarsi là. L'impostazione predefinita ha spostato il rischio lontano dalla macchina del cliente, per chi la accetta.
Resta così una linea netta nel mezzo. Se i vostri sviluppatori usano l'agente nella modalità cloud predefinita, questa fuga non è un loro problema. Se scelgono l'esecuzione locale, per riservatezza, per lavoro offline o per abitudine, portano l'intera esposizione, e nessun aggiornamento la eliminerà per loro.
Il confine era un montaggio, non un muro
Il dettaglio istruttivo è quanto fosse comune la debolezza. Il file system dell'host era condiviso con la macchina virtuale in modo che solo l'utente root nel guest dovesse vederlo. La fuga è semplicemente diventata root dentro il guest, tramite una falla nota del kernel Linux identificata come CVE-2026-46331, e il montaggio ha fatto il resto.
La lezione per chi difende non è l'errore di un singolo fornitore, ma la sua forma. Una sandbox che condivide l'intero host è forte quanto l'assunto che nulla al suo interno diventerà mai root. Con un agente che legge contenuti non verificati e agisce di conseguenza, è proprio l'assunto che non dovreste fare.
Cosa mettere in sicurezza prima di usarlo in locale
Trattate ogni macchina che esegue un agente locale come se l'agente potesse leggere la cartella personale, perché in questo caso poteva. Tenete le chiavi SSH e le credenziali cloud fuori dai portatili di sviluppo che eseguono agenti con contenuti non verificati, oppure limitate quegli agenti in modo che la condivisione del file system dell'host sia ristretta alle cartelle collegate e in sola lettura.
Dove la piattaforma lo consente, i ricercatori raccomandano di disattivare i namespace utente senza privilegi, irrigidire il filtro sulle chiamate di sistema e impedire il caricamento su richiesta dei moduli del kernel inutilizzati - i passi che avrebbero bloccato questa catena. Sono controlli di configurazione, e quindi spettano a voi, non al fornitore.
Anche l'obbligo di notifica spetta a voi. Con NIS2 nell'Unione Europea, e con DORA per le imprese finanziarie, una credenziale di sviluppatore trapelata che raggiunge la produzione è il vostro incidente, da dichiarare nei tempi previsti - in Italia all'ACN. La sandbox è stata venduta come sicurezza; la responsabilità è sempre stata vostra.
Da leggere ora: La porta rimasta aperta era il registro dei pacchetti | Un'IA ha condotto da sola un intero attacco ransomware
