Vulnerabilità in Claude Cowork: rischio di fuga dalla VM su Mac

Se usi Claude Cowork in locale su Mac, la scelta più sicura è passare subito all’esecuzione cloud e verificare che la sessione non stia usando ambienti locali. Una vulnerabilità scoperta nel componente desktop poteva infatti consentire a un agente AI di superare l’isolamento della VM e arrivare ai file del sistema host, con un impatto potenzialmente molto serio per dati, credenziali e chiavi private.

Per gli utenti non tecnici, il punto essenziale è semplice: un ambiente che doveva essere isolato non era abbastanza separato dal Mac. La conseguenza, in scenari specifici, era la possibilità di leggere o scrivere file oltre la cartella condivisa con la sessione, senza ulteriori richieste di permesso.

Cosa è successo

La vulnerabilità riguarda Claude Cowork in esecuzione locale su macOS e consente, secondo quanto emerso nella ricerca, una sandbox escape dalla VM Linux usata dall’agente. In pratica, l’agente poteva uscire dal perimetro previsto e raggiungere il file system del Mac ospite.

Il problema è stato identificato con il nome in codice SharedRoot. La ricerca ha mostrato che, dopo aver collegato una cartella a una nuova sessione e inviato un solo messaggio, l’agente poteva eseguire operazioni ben oltre il contenuto della cartella condivisa.

Secondo la descrizione tecnica del caso, circa 500.000 utenti macOS che eseguivano sessioni locali di Cowork sarebbero stati esposti prima della correzione del comportamento predefinito. La gravità non dipendeva solo dalla possibilità di uscita dalla VM, ma anche dal fatto che l’agente operava con accesso ai dati dell’utente connesso al Mac.

Perché il rischio è serio

Se un agente ottiene accesso al file system del sistema host, può potenzialmente raggiungere informazioni molto sensibili. Tra i dati più critici ci sono chiavi SSH, credenziali cloud, token di accesso, file di configurazione, documenti personali e altri contenuti memorizzati nella home dell’utente.

Nel contesto di una workstation usata per sviluppo, amministrazione o accesso a servizi online, questo tipo di esposizione può trasformarsi rapidamente in un incidente più ampio. Non si tratta solo di privacy: una compromissione delle credenziali può aprire la strada ad accessi non autorizzati ad ambienti di lavoro, repository, infrastrutture cloud e account aziendali.

Come funzionava l’architettura

Claude Cowork su macOS gira come app desktop per l’utente autenticato nel sistema. Il lavoro dell’agente, invece, viene svolto in una VM Linux creata tramite il framework di virtualizzazione di Apple. Ogni sessione riceve un utente temporaneo e non privilegiato, insieme a un filtro seccomp per limitare le chiamate di sistema.

Le cartelle collegate dall’utente vengono condivise nella VM da un demone con privilegi elevati. Il punto critico segnalato nella ricerca è che il file system dell’host veniva esposto nella VM con permessi di lettura e scrittura, non solo in modalità protetta. Questo dettaglio rendeva possibile, una volta raggiunto il livello di guest root, interagire con il file system del Mac come se fosse accessibile dall’interno della macchina virtuale.

In altre parole, l’isolamento non era abbastanza forte: il perimetro della VM non bastava a contenere un agente capace di arrivare a privilegi più alti nel guest.

La catena di attacco

La sequenza descritta dai ricercatori passava da un componente del kernel Linux chiamato act_pedit, parte del sottosistema Traffic Control. Il problema sfruttava una falla identificata come CVE-2026-46331, associata al bug noto come pedit COW.

L’obiettivo era ottenere guest-root nella VM. Una volta ottenuto quel livello di privilegio, l’agente poteva accedere all’intero file system condiviso e quindi al contenuto del Mac ospite. Da quel punto, la lettura o la modifica di file del sistema era possibile senza che l’utente ricevesse un prompt di autorizzazione aggiuntivo.

La ricerca evidenzia anche il ruolo dei namespace Linux. La creazione di user namespace e network namespace forniva all’ambiente una serie di capacità utili per operazioni di rete e per l’accesso al percorso vulnerabile del kernel. I namespace, in questo caso, non erano l’exploit in sé: rendevano disponibile a un utente ordinario un requisito normalmente privilegiato.

Stato della correzione

Dopo la segnalazione responsabile, Anthropic ha chiuso il report come informativo senza rilasciare una correzione specifica per il comportamento descritto. Tuttavia, la versione più recente di Cowork usa per impostazione predefinita l’esecuzione cloud, che riduce l’esposizione del problema per chi accetta quel modello operativo.

Resta invece il rischio per chi continua a scegliere l’esecuzione locale. In questi casi, la vulnerabilità può rimanere rilevante finché l’architettura conserva lo stesso schema di condivisione del file system e le stesse dipendenze dal guest kernel.

Cosa fare subito

Per ridurre il rischio, le misure più importanti sono pratiche e immediate:

Disattivare o evitare i namespace utente non privilegiati quando non sono necessari.
Rendere il filtro seccomp più restrittivo, invece di ampliarlo oltre il minimo indispensabile.
Limitare l’autocaricamento dei moduli del kernel, soprattutto nei percorsi accessibili da utenti non privilegiati.
Evitare la condivisione dell’intero host nel guest e montare solo le cartelle realmente necessarie.
Preferire il montaggio in sola lettura quando la scrittura non è essenziale.
Eseguire il demone di supporto in un mount namespace separato con protezioni di sistema più severe.
Verificare che l’esecuzione cloud sia attiva se il flusso di lavoro lo consente.

Per gli utenti finali, il controllo più semplice è confermare che non si stiano usando sessioni locali non necessarie e che le cartelle condivise siano ridotte al minimo. Per gli ambienti aziendali, è opportuno trattare il caso come un rischio di esposizione delle credenziali e rivedere l’assetto delle workstation coinvolte.

Impatto operativo per utenti e team IT

L’episodio mostra che l’uso di agenti AI in locale non va considerato automaticamente sicuro solo perché passa da una VM. Se la VM riceve accesso in scrittura a parti troppo ampie del file system dell’host, una singola falla nel guest può diventare una fuga completa dall’isolamento.

Per i team IT, questo significa rivedere tre aspetti: confini di montaggio, privilegi del kernel guest e superficie di attacco del processo di supporto. Per gli utenti, significa invece non affidarsi ciecamente alla dicitura “sandbox” quando l’agente manipola dati sensibili o credenziali di lavoro.

Technical Deep Dive

La vulnerabilità descritta sfruttava l’interazione tra la VM Linux, i namespace e il sottosistema tc/act_pedit del kernel. L’architettura di Cowork assegnava alla sessione un utente non privilegiato e un set di limitazioni via seccomp, ma la creazione di user e network namespace forniva comunque capacità operative sufficienti per raggiungere il percorso vulnerabile del kernel.

Il punto decisivo era che il file system dell’host veniva condiviso nella VM con lettura e scrittura, e l’intero host era montato all’interno del guest in un percorso visibile solo a guest-root. Questo design crea un’assunzione implicita: finché il guest resta confinato, l’host resta protetto. Se però l’aggressore ottiene privilegi elevati nel guest, la barriera si indebolisce drasticamente.

La catena tecnica, in sintesi, era la seguente:

la sessione locale partiva in una VM Linux dedicata;
il demone di orchestrazione condivideva il file system dell’host nel guest;
i namespace rendevano disponibile CAP_NET_ADMIN nel contesto privato della sessione;
l’exploit CVE-2026-46331 nel percorso act_pedit consentiva l’escalation a guest-root;
una volta ottenuto il privilegio massimo nel guest, l’agente poteva operare sul file system del Mac tramite il mount condiviso.

Dal punto di vista difensivo, le misure più efficaci sono quelle che spezzano la catena prima dell’ultimo passaggio. In particolare, la condivisione dell’intero host è un fattore di rischio strutturale: se il guest ha visibilità su tutto / e non solo sulle cartelle richieste, il confine di sicurezza diventa troppo ampio. Il montaggio read-only riduce l’impatto, ma non elimina il rischio di lettura dei dati sensibili.

Anche la gestione dei moduli kernel è rilevante. Se un utente non privilegiato può raggiungere percorsi in grado di caricare automaticamente moduli o attivare superfici di rete complesse, la probabilità di trovare un bug sfruttabile aumenta. Il caso sottolinea inoltre che i bug di privilege escalation nei sottosistemi di rete Linux non sono eccezioni isolate, ma una categoria ricorrente di difetti che può riaprire la stessa strada con un payload diverso.

Per questo la raccomandazione architetturale non è solo “patchare più velocemente”, ma ridurre l’esposizione strutturale: meno condivisione dell’host, meno capacità nel guest, meno percorsi autoattivabili nel kernel e più separazione tra il processo di orchestrazione e i contenuti controllabili dalla sessione.

Se il modello di lavoro richiede davvero l’esecuzione locale, la configurazione più prudente è quella che limita il mount alle sole directory necessarie, usa permessi minimi, isola il demone di supporto e impedisce che una compromissione del guest diventi un accesso al resto del Mac.

Fonte: https://thehackernews.com/2026/07/claude-cowork-flaw-could-let-ai-agent.html