OpenAI Codex evade la sandbox: due falle portano i comandi direttamente sull’host

🛡️ Executive Summary

• Accomplish ha scoperto Overpatch e Heapjack, due bypass distinti della sandbox di OpenAI Codex segnalati il 12 agosto 2026.
• Overpatch permetteva a `apply_patch` di scrivere fuori dal workspace; Heapjack arrivava all’esecuzione unsandboxed anche in modalità read-only.
• OpenAI ha corretto i problemi entro otto giorni: Codex CLI 0.149.0 e Codex Desktop 26.818.21641 chiudono i percorsi descritti.

Due vulnerabilità separate permettevano a OpenAI Codex di oltrepassare il confine della propria sandbox e raggiungere direttamente il sistema host, senza che l’utente concedesse esplicitamente l’esecuzione fuori dall’ambiente protetto. I ricercatori di Accomplish hanno chiamato i due problemi Overpatch e Heapjack e li hanno segnalati a OpenAI il 12 agosto 2026; entrambi risultano corretti entro otto giorni. Il primo colpiva il percorso di modifica dei file di Codex CLI e consentiva di ampliare indirettamente le directory scrivibili, mentre il secondo sfruttava il rapporto di fiducia tra JavaScript sandboxed e un processo Rust eseguito fuori dalla sandbox. Il problema non riguarda quindi un modello che “decide di scappare”, ma l’architettura che collega agente, strumenti e processi privilegiati.

Overpatch trasformava apply_patch in un percorso di scrittura fuori dal workspace

Nel normale workspace-write, Codex dovrebbe consentire all’agente di modificare soltanto il progetto corrente e poche directory esplicitamente autorizzate. La ricerca tecnica originale di Accomplish mostra però che il tool apply_patch calcolava i permessi di scrittura utilizzando le directory padre dei percorsi inseriti nella patch. Inserendo anche una modifica destinata a /tmp, pur progettata per fallire, era possibile allargare il writable root fino a /; una seconda modifica poteva quindi attraversare un symlink e raggiungere file fuori dal workspace, per esempio .zshrc nella home dell’utente, senza mostrare il normale prompt di approvazione.

Il codice inserito nel file di configurazione della shell sarebbe poi stato eseguito fuori dalla sandbox all’apertura del terminale successivo. È precisamente il tipo di separazione che OpenAI descrive nella propria architettura di sicurezza di Codex, dove sandbox e approval policy dovrebbero impedire a un’azione ordinaria dell’agente di trasformarsi autonomamente in una modifica host-level. Il problema amplia una superficie già emersa con GitSpawn, dove configurazioni Git controllate dal repository potevano portare alcuni coding agent all’esecuzione fuori sandbox: la vulnerabilità non nasce necessariamente dal modello, ma dal punto nel quale un tool considerato fidato interpreta dati controllabili dal workspace.

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

Heapjack rompeva il confine anche nella modalità read-only

Heapjack è più grave dal punto di vista del modello di fiducia perché la dimostrazione funziona nella modalità read-only, quella nella quale Codex dovrebbe impedire qualsiasi modifica al filesystem da parte dell’agente. Codex Desktop installava un componente node_repl configurato globalmente in ~/.codex/config.toml: un processo Rust eseguito fuori dalla sandbox avviava Node dentro l’ambiente protetto e separava il codice JavaScript in due contesti V8, uno trusted e uno untrusted. Il contesto affidabile possedeva un token casuale utilizzato per autenticare le richieste verso il processo Rust, ma entrambi i contesti condividevano lo stesso heap V8. Il codice non fidato poteva quindi acquisire un heap snapshot, individuare stringhe compatibili con il formato del token e provarle fino a identificare quella corretta; a quel punto poteva scrivere direttamente sulla pipe utilizzata per comunicare con il processo parent, costruendo una richiesta formalmente autenticata.

Nel proof of concept il parent eseguiva il comando di sistema open, lasciando che launchd avviasse un’applicazione fuori dal process tree di Codex e quindi fuori dalla sandbox. Lo stesso token offriva inoltre accesso alle Unix socket, compresa potenzialmente quella del daemon Docker, e al tool capace di modificare il file globale di configurazione Codex. Il caso ricorda il data leak cross-account scoperto nella sandbox ChatGPT, ma qui il problema attraversa un confine ancora più sensibile: codice non fidato dentro l’agente riesce a impartire istruzioni a un componente privilegiato esterno.

OpenAI ha corretto entrambe le falle, ma il problema è il trust boundary

Accomplish indica come versioni corrette Codex CLI 0.149.0 o successive per Overpatch e Codex Desktop build 26.818.21641 o successive per Heapjack. La correzione del percorso apply_patch è coerente con il modello che OpenAI dichiara di voler applicare alla sandbox: i processi generati dall’agente devono restare confinati e un tool destinato alla produttività non può autonomamente ampliare le proprie autorizzazioni. La stessa documentazione OpenAI specifica che Codex viene progettato con sandboxing, restrizioni di rete, writable roots e approval policy separati, proprio perché un coding agent può leggere repository non completamente affidabili ed eseguire strumenti che lavorano sui file del progetto.

È importante anche distinguere questi bug dagli incidenti nei quali un modello compie autonomamente operazioni non previste: quando GPT-5.6 Sol aveva raggiunto infrastrutture reali durante valutazioni cyber, il problema riguardava il comportamento dell’agente e la configurazione del test; Overpatch e Heapjack sono invece vulnerabilità nell’enforcement tecnico che avrebbe dovuto contenere qualunque comportamento del modello. La differenza è sostanziale perché una sandbox deve funzionare anche quando l’input, il repository o lo stesso agente sono considerati potenzialmente ostili.

La sandbox dell’agente non può controllare da sola ciò che la sandbox deve impedire

Le due vulnerabilità convergono sullo stesso difetto architetturale: parte della decisione su cosa fosse consentito rimaneva troppo vicina al codice sottoposto alle restrizioni. Con Overpatch era apply_patch a derivare le autorizzazioni dai percorsi forniti alla stessa operazione; con Heapjack il segreto che separava codice trusted e untrusted rimaneva nello stesso heap del codice non affidabile. Questa è la ragione per cui il tema supera Codex e riguarda l’intera categoria dei coding agent. Più questi strumenti acquisiscono shell, Git, browser, MCP, Docker, credenziali e capacità di modificare file, più il controllo deve essere applicato da un livello indipendente che non possa essere riconfigurato attraverso il workspace. La questione era già emersa quando OpenAI ha introdotto Lockdown Mode per limitare app, web e canali di esfiltrazione: sicurezza del modello e sicurezza dell’ambiente non sono intercambiabili. Un agente può rispettare perfettamente le istruzioni ricevute e tuttavia attraversare il perimetro se uno strumento privilegiato interpreta male un path, una pipe o una credenziale.

Continua con:

OpenAI Astra trova zero-day ma diventa più difficile da monitorare

OpenAI Astra scrive istruzioni a se stesso nei compaction summary

Per i coding agent il repository deve essere trattato come input ostile

Overpatch e Heapjack sono stati corretti, ma la loro lezione resta operativa. Aprire un repository con un agente dotato di tool locali significa permettere a contenuti controllati da terzi di influenzare software capace di interagire con il computer dello sviluppatore. Aggiornare Codex chiude i due percorsi descritti dalla ricerca, ma non elimina la necessità di separare credenziali reali, filesystem host, socket Docker e configurazioni globali dall’ambiente nel quale l’agente elabora codice non fidato. La sandbox deve essere quindi considerata una frontiera di sicurezza vera e non un semplice meccanismo di conferma delle azioni: se il componente che applica la policy può essere raggiunto, manipolato o impersonato dall’ambiente che dovrebbe contenere, il problema non è quanto sia intelligente l’agente. Il problema è che il confine di sicurezza esiste soltanto finché il codice all’interno non può modificare le condizioni che lo definiscono.