Il sandbox non basta più: come Cursor, Codex, Gemini CLI e Antigravity sono stati bypassati

Per mesi il messaggio rassicurante degli editor e delle CLI potenziate da AI è stato semplice: l’agente lavora dentro un sandbox, quindi anche se un prompt injection lo convince a fare qualcosa di malevolo, il danno resta confinato al workspace. Il team di ricerca di Pillar Security ha appena dimostrato, in una serie di sette advisory pubblicate come “The Week of Sandbox Escapes”, che questa assunzione è sbagliata per almeno quattro strumenti molto usati da sviluppatori e sistemisti: Cursor, OpenAI Codex CLI, Google Gemini CLI e Antigravity.

La cosa interessante, e preoccupante, è che in nessuno dei casi l’agente ha attaccato direttamente il confine del sandbox. Ha semplicemente scritto un file che uno strumento fidato, esterno al sandbox, ha poi eseguito, caricato o scansionato per conto proprio.

Il vero confine non è il processo dell’agente

Il modello mentale comune è: “dentro il workspace l’agente può fare quello che vuole, fuori è protetto”. Pillar mostra che questo confine ha in realtà tre livelli distinti:

• Esecuzione diretta: cosa può lanciare il processo dell’agente
• Scrittura nel workspace: quali file l’agente può creare o modificare
• Fiducia dell’host: cosa fanno i componenti non sandboxati con quei file

È il terzo livello a rompersi sistematicamente. Editor e CLI moderni sono pieni di automazioni che girano fuori dal sandbox: estensioni Python che scoprono interpreti, integrazioni Git che scansionano repository, VS Code che carica task file, hook engine che eseguono comandi al lifecycle, Docker Desktop che espone un socket locale privilegiato. Un agente sandboxato può rispettare ogni singola regola che gli è stata imposta e comunque condizionare l’input che questi componenti consumeranno.

Le quattro classi di vulnerabilità

I ricercatori raggruppano i sette bug in quattro pattern ricorrenti:

1. Sandbox a denylist che non tengono il passo del sistema operativo

Il caso più chiaro è la sandbox Seatbelt di Antigravity su macOS: un profilo “allow by default” deve ricordarsi di bloccare ogni singola funzionalità pericolosa del sistema operativo. Come scrive Pillar, “non è un sandbox, è una lista di cose che qualcuno si è ricordato di bloccare, sempre corta di una voce”.

2. Configurazioni di progetto che sono a tutti gli effetti codice eseguibile

Diversi bug non sono breakout classici: l’agente ha scritto file che era autorizzato a scrivere. Il problema è nato dopo, quando l’host ha trattato quei file come configurazione fidata. È il caso dell’hook .claude in Cursor, diventato esecuzione di comandi non sandboxata (ora CVE-2026-48124, corretto nella 3.0.0), o del task config .vscode che Antigravity ha usato per aggirare la sua Secure Mode.

3. Allowlist di comandi “sicuri” per nome, non per invocazione

In Codex CLI, un comando come git show era considerato sicuro perché il nome suggerisce sola lettura. Ma Git ha decine di flag che cambiano completamente il comportamento: possono scrivere file, caricare configurazioni, invocare hook. La domanda giusta, scrivono i ricercatori, non è “git show è sicuro?” ma “quale invocazione esatta viene eseguita, con quali argomenti, in quale directory, contro quale configurazione?”. OpenAI ha corretto il bug nella v0.95.0 e pagato una bounty per severità alta.

4. Demoni locali privilegiati fuori dal sandbox

Il bug più trasversale riguarda il socket Docker: un demone locale privilegiato raggiungibile da Codex, Cursor e Gemini CLI contemporaneamente, che diventava un ambiente di esecuzione non sandboxato. Sandboxare il processo dell’agente non serve a nulla se lascia aperto un demone con accesso pieno all’host: il confine si sposta semplicemente sull’API del demone.

Come si arriva all’exploit: il ruolo del prompt injection

In tutti i casi il vettore d’ingresso è un’istruzione malevola nascosta in un README, in una issue, in una dipendenza o in un diff, che l’agente legge come input “normale” durante il suo lavoro. Da lì, l’istruzione si trasforma in un’azione locale sulla macchina dello sviluppatore, senza che l’utente abbia mai approvato esplicitamente nulla di sospetto: dal punto di vista dell’agente, ha semplicemente scritto un file di configurazione plausibile in un progetto.

Google ha classificato le due vulnerabilità di Antigravity come “Other valid security vulnerabilities”, applicando un downgrade perché richiedono ingegneria sociale o che l’utente si fidi di un repository con prompt injection indiretto — pur riconoscendo, nelle parole dei ricercatori, che uno dei report era “di qualità eccezionale”.

Cosa chiedere ai vendor (e cosa verificare in azienda)

Per chi gestisce endpoint di sviluppo con strumenti agentici, Pillar suggerisce di andare oltre la domanda “ha un sandbox?” e porsi domande più operative:

• Cosa può scrivere l’agente, esattamente?
• Quali componenti dell’host si fidano di quei file?
• Quali demoni locali privilegiati sono raggiungibili dall’agente?
• Quali comandi saltano l’approvazione, e perché?
• La policy valuta il nome del comando o l’invocazione e i suoi effetti reali?
• Il prodotto distingue file creati dall’utente da file creati dall’agente?
• Che telemetria esiste quando un componente fidato esegue qualcosa scritto dall’agente?

Sul piano pratico, per chi amministra postazioni di sviluppo con Cursor, Codex CLI, Gemini CLI o Antigravity: aggiornate immediatamente alle versioni patchate (Cursor 3.0.0+, Codex CLI 0.95.0+), verificate che l’accesso al socket Docker dagli strumenti AI sia effettivamente ristretto quando non necessario, e trattate le configurazioni di progetto generate o modificabili da un agente (hook, task VS Code, config Git non standard) come superficie di attacco da rivedere in code review, non come dettagli innocui.

Conclusione

Il punto centrale della ricerca di Pillar non è la lista dei singoli bug, quasi tutti già corretti, ma il pattern che li accomuna: gli agenti di coding sono diventati attori endpoint a tutti gli effetti, con accesso a codice sorgente, chiavi SSH, token cloud e sessioni browser, e processano di routine input non fidato (README, issue, dipendenze, diff). Un sandbox che protegge solo il processo dell’agente, ignorando cosa scrive e chi si fida di quello che scrive, non è un confine di sicurezza reale. Per chi introduce questi strumenti in azienda, la domanda da porsi non è più “abbiamo attivato il sandbox”, ma “sappiamo tracciare ogni volta che un componente fidato dell’host esegue qualcosa che l’agente ha scritto”.

Fonte: Pillar Security, “The Week of Sandbox Escapes” e BleepingComputer.