Codex sandbox escape: Heapjack e Overpatch bucano la sicurezza dell’agente OpenAI

Un ricercatore di sicurezza ha bucato due volte la Codex sandbox, l’agente di coding di OpenAI, e in un caso e’ arrivato all’esecuzione di comandi arbitrari sul PC dello sviluppatore partendo dalla modalita’ piu’ restrittiva dell’agente: read-only. Il Codex sandbox escape, disclosed il 15 settembre 2026 da Oren Yomtov di Accomplish AI, colpisce sia la CLI open source sia l’app desktop, e trasforma un gesto banale come aprire una repo altrui e farci una domanda in una compromissione completa della macchina. OpenAI ha rilasciato le patch entro otto giorni dalla segnalazione, avvenuta il 12 agosto 2026.

Indice

1. Cos’e’ la Codex sandbox e perche’ serve
2. Heapjack: RCE dalla modalita’ read-only
3. Overpatch: scrittura ovunque sul disco
4. Lo stesso difetto strutturale in entrambi i bug
5. Cosa fare subito: versioni patchate e mitigazioni
6. FAQ

Cos’e’ la Codex sandbox e perche’ serve

Codex e’ l’agente di coding di OpenAI, distribuito come CLI open source e come app desktop, che legge repository, modifica file ed esegue comandi sulla macchina dello sviluppatore. Per contenere il rischio, ogni azione del modello passa dentro una sandbox a livello di sistema operativo – Seatbelt su macOS, Landlock e seccomp su Linux – che limita scritture e accesso di rete. La modalita’ piu’ restrittiva si chiama read-only: l’agente puo’ leggere ma non scrivere nulla.

Codex e’ uno dei principali strumenti dell’ecosistema ChatGPT Work, e proprio per questo l’affidabilita’ della sua sandbox e’ un problema che tocca centinaia di migliaia di sviluppatori. Le due vulnerabilita’ scoperte da Yomtov mostrano che quella promessa non e’ stata mantenuta. Entrambe sono state segnalate il 12 agosto 2026 e patchate entro otto giorni.

Heapjack: RCE dalla modalita’ read-only

Heapjack e’ il bug piu’ grave e colpisce Codex Desktop. Al momento dell’installazione, l’app scrive un blocco [mcp_servers.node_repl] nel file globale ~/.codex/config.toml. Non c’e’ opt-in, non esiste un’impostazione per disattivarlo – e siccome la configurazione e’ condivisa, anche chi usa solo Codex CLI eredita il tool senza saperlo.

node_repl e’ un programma Rust nativo, quindi unsandboxed, che avvia un processo Node.js dentro la sandbox di Codex. Dentro quel singolo processo Node convivono due contesti V8 vm:

• il contesto trusted, che contiene il codice OpenAI e detiene un token di autorizzazione UUID generato a ogni run;
• il contesto untrusted, in cui gira il codice dell’agente.

Il difetto strutturale: un solo processo Node, un solo V8 isolate, un solo heap in memoria condiviso da entrambi i contesti. Il token trusted e’ una stringa che vive in quello stesso heap.

L’exploit fa esattamente quello che ci si aspetta:

1. Chiama v8.getHeapSnapshot() dal contesto untrusted.
2. Cerca ogni stringa in formato UUID.
3. La prova come token: risposta not authorized significa sbagliato; risposta con errore di validazione reale significa giusto.
4. Con il token in mano, scrive richieste JSON sulla stessa pipe (fd 1) che il contesto trusted usa per parlare col parent Rust unsandboxed.
5. Il parent verifica il token, lo trova valido, esegue il comando.

Nel proof-of-concept di Accomplish il parent lancia il comando di sistema open, cosi’ launchd avvia l’applicazione fuori dal process tree di Codex, senza alcun sandboxing. Lo stesso token consente di parlare con qualsiasi socket Unix – un socket Docker in primis – e di riscrivere il file config.toml globale.

Tutto questo, ripetiamolo, gira in modalita’ read-only. Aprire una repo clonata da un attaccante, fare una domanda a Codex sul codice, e chi ha scritto quella repo ottiene RCE sulla tua macchina. Zero prompt di conferma, nulla a schermo.

Overpatch: scrittura ovunque sul disco

Overpatch colpisce il Codex CLI open source. In modalita’ workspace-write l’agente puo’ scrivere solo dentro la cartella del workspace, e un comando shell che punta a $HOME viene rifiutato. Yomtov ha trovato il modo di aggirare il limite usando lo strumento apply_patch che Codex offre all’agente per modificare file.

Il bug: apply_patch concede permessi di scrittura sulla cartella padre di ogni path nominato nel patch. Se il patch include /tmp, il permesso viene esteso a / – cioe’ alla radice del filesystem.

Il patch dell’exploit contiene due modifiche:

• una nomina /tmp e non fa nulla di utile (fallisce perche’ non puoi sovrascrivere una directory con un file), ma serve a espandere il grant;
• l’altra appende una riga a .zshrc attraverso un symlink piazzato dentro il workspace che punta a $HOME.

Togli la prima modifica e la scrittura viene rifiutata. Con la prima al suo posto, la riga finisce in .zshrc e al prossimo terminale che apri viene eseguita unsandboxed.

Lo stesso difetto strutturale in entrambi i bug

Yomtov riassume la causa comune in una frase: The thing doing the enforcement was sitting inside the thing being enforced – chi imponeva il vincolo stava seduto dentro l’ambiente che avrebbe dovuto limitare.

• In Overpatch, apply_patch decideva i propri permessi a partire da input che l’attaccante controllava.
• In Heapjack, il segreto che separa codice trusted da untrusted viveva nella stessa memoria accessibile dal codice untrusted.

Non e’ un problema esclusivo di OpenAI. A luglio 2026 Pillar Security aveva gia’ dimostrato sandbox escape simili su Cursor, Codex, Gemini CLI e Google Antigravity, sempre con la stessa logica: l’agente resta dentro la sandbox ma scrive file che tool trusted esterni poi eseguono. Anche gli agenti concorrenti, come il Claude Code di Anthropic, sono soggetti alla stessa classe di problemi architetturali quando affidano l’enforcement a codice che gira dentro l’ambiente controllato. Il tema piu’ ampio della ricerca di vulnerabilita’ negli agenti AI conferma che separare fisicamente l’enforcement dall’ambiente controllato – ad esempio dentro una VM – resta la lezione architetturale ricorrente.

Cosa fare subito

Le due versioni patchate, secondo Accomplish AI:

Il changelog del Codex CLI 0.149.0 elenca tre commit rilevanti: Prevent apply_patch from widening write permissions (#39614), Harden unsandboxed patch filesystem access (#39659) e Prevent Node REPL auth tokens from reaching child processes (#39301).

OpenAI a BleepingComputer ha ringraziato i ricercatori e dichiarato di aver risolto entrambe le issue ad agosto, con aggiornamenti in corso per rafforzare i limiti su dove gli agenti possono scrivere file e ampliare i test su tutte le piattaforme.

Al di la’ della patch, il consiglio operativo e’ duplice: non aprire repo di terzi in Codex Desktop se non hai aggiornato e, se lavori con codice non fidato, valuta di eseguire l’agente dentro una VM o un container davvero isolati dal tuo sistema host, con credenziali placeholder al posto di quelle reali. Fonte tecnica completa: writeup di Accomplish AI.

FAQ

Cos’e’ un Codex sandbox escape?

Un Codex sandbox escape e’ una tecnica che permette a codice controllato dall’attaccante di uscire dai limiti della sandbox di Codex ed eseguire azioni sul sistema host. Nel caso di Heapjack e Overpatch, l’escape avviene senza prompt di conferma e senza notifica visibile, sfruttando il modo in cui l’agente gestisce token e permessi.

Come faccio a sapere se sono vulnerabile?

Sei vulnerabile se usi Codex Desktop con build precedente a 26.818.21641 o Codex CLI con versione precedente a 0.149.0. Il rischio si concretizza quando apri o analizzi una repository di terzi. L’installazione di Codex Desktop configura globalmente node_repl in ~/.codex/config.toml, quindi anche gli utenti solo-CLI risultavano esposti a Heapjack se avevano installato l’app.

Heapjack e Overpatch sono gia’ stati sfruttati?

Secondo Accomplish AI, entrambe le vulnerabilita’ sono state segnalate in disclosure responsabile a OpenAI il 12 agosto 2026 e patchate entro otto giorni. Non risultano casi noti di sfruttamento in the wild, ma i proof-of-concept sono pubblici, quindi aggiornare non e’ opzionale.

Perche’ la modalita’ read-only non ha protetto?

Perche’ l’attacco Heapjack non passa dai file: sfrutta il fatto che il token che distingue codice trusted da untrusted vive nella stessa memoria heap del contesto V8 dell’agente. Leggere quella memoria e’ un’azione permessa, e il token e’ la sola cosa che separa la scrittura sul pipe di controllo dall’esecuzione unsandboxed nel parent nativo.

Questi problemi esistono anche in Claude Code e Cursor?

Il singolo bug Heapjack e’ specifico dell’implementazione node_repl di Codex, ma la classe di vulnerabilita’ e’ comune: a luglio 2026 Pillar Security ha documentato sandbox escape su Cursor, Codex, Gemini CLI e Google Antigravity. Ogni coding agent che affida l’enforcement a codice che gira dentro l’ambiente controllato eredita lo stesso rischio strutturale.

Conclusione

Heapjack e Overpatch non sono bug esotici, sono esempi da manuale di security by promise: la sandbox esisteva, ma il meccanismo che la faceva rispettare era raggiungibile da chi doveva restare fuori. La lezione per chi usa coding agent e’ duplice – aggiornare subito, e trattare qualsiasi repo di terzi come untrusted anche quando la modalita’ in uso si dice read-only. Quanto ti fidi davvero della sandbox del tuo agente di coding preferito? Fammelo sapere nei commenti.

#tuttelevitediunmaker