Le falle nella sandbox di OpenAI Codex trasformano l’analisi dei repository in esecuzione di comandi sul sistema host

Due vulnerabilità in OpenAI Codex permettevano a operazioni controllate dall’agente di oltrepassare i limiti di sicurezza previsti e di agire sul sistema host dello sviluppatore. Una funzionava persino con la policy di sola lettura più restrittiva, mentre l’altra aggirava le restrizioni che consentivano di scrivere esclusivamente nell’area di lavoro.

I ricercatori hanno denominato le falle Heapjack e Overpatch. Heapjack interessa Codex Desktop e può portare all’esecuzione di comandi al di fuori della sandbox, senza richiesta di approvazione né avvisi visibili. Overpatch interessa il Codex CLI open source e può modificare file esterni alla directory di progetto autorizzata, incluso il file .zshrc dell’utente.

Entrambe le vulnerabilità sono state segnalate a OpenAI il 12 agosto 2026. OpenAI le ha risolte entro otto giorni, rilasciando la build 26.818.21641 di Codex Desktop per Heapjack e la versione 0.149.0 di Codex CLI per Overpatch.

Non sono stati divulgati identificativi CVE né punteggi CVSS ufficiali. Inoltre, non risultano prove che una delle due vulnerabilità sia stata sfruttata in attacchi reali.

Heapjack infrange il confine di sicurezza della sola lettura

Heapjack è la più grave delle due vulnerabilità, perché può consentire di passare dall’analisi del codice nella sandbox ad attività sul sistema host. Lo sviluppatore potrebbe innescare l’attacco aprendo in Codex il repository di un’altra persona e chiedendo all’agente informazioni sul suo contenuto.

L’exploit rimane efficace quando Codex è configurato in modalità di sola lettura. In base a questa policy, gli utenti si aspetterebbero normalmente che l’agente possa ispezionare i file senza modificare il sistema né eseguire operazioni sul sistema host al di fuori della sandbox.

Heapjack prende invece di mira il componente node_repl installato da Codex Desktop. Durante l’installazione, Codex Desktop aggiunge questo componente al file di configurazione globale:

~/.codex/config.toml

Il componente è abilitato per impostazione predefinita. Non richiede un’attivazione separata e non è stata resa nota alcuna opzione dedicata per disabilitarlo. Poiché la configurazione è globale, anche gli utenti di Codex CLI possono ereditare lo strumento senza ricevere un’ulteriore richiesta di autorizzazione.

La funzionalità vulnerabile, quindi, non è confinata a un singolo repository o a una sessione approvata esplicitamente. Entra a far parte dell’ambiente Codex condiviso dell’utente.

Un token segreto memorizzato accanto a JavaScript non attendibile

La progettazione vulnerabile di node_repl utilizza un processo Node.js contenente due contesti JavaScript separati. Uno è attendibile ed esegue codice OpenAI. L’altro non è attendibile ed esegue codice controllato dall’agente.

Il contesto attendibile comunica con un processo padre nativo in esecuzione al di fuori della sandbox. Ogni richiesta viene autenticata mediante un token generato casualmente e creato per quella specifica esecuzione.

La separazione dei contesti JavaScript, tuttavia, non separa la memoria sottostante. Entrambi i contesti utilizzano lo stesso heap Node.js, lasciando il token di autenticazione alla portata del codice eseguito nel contesto non attendibile.

La prova di concetto di Heapjack richiama:

v8.getHeapSnapshot()

Esamina quindi lo snapshot dell’heap V8 risultante alla ricerca di stringhe che corrispondano alla struttura prevista, simile a quella di un UUID, del token. Individuare i potenziali valori è solo il primo passaggio. L’exploit deve anche stabilire quale candidato sia quello valido.

I ricercatori ci sono riusciti osservando la risposta del processo padre a richieste diverse. Un token errato provocava un errore di autorizzazione. Un token corretto, inviato con un argomento non valido, produceva un errore di validazione differente. Questa distinzione fungeva da oracolo di autenticazione e confermava il recupero del token autentico.

Il contesto non attendibile poteva quindi scrivere una richiesta contraffatta nello stesso canale di comunicazione utilizzato dal componente attendibile. Poiché il messaggio conteneva il token valido, il processo padre al di fuori della sandbox lo accettava ed eseguiva l’operazione richiesta.

Nell’attacco dimostrato, il processo padre invocava il comando di sistema open per avviare un’applicazione al di fuori dell’albero dei processi di Codex. L’operazione non generava alcuna richiesta di approvazione né indicazione visibile sullo schermo all’interno di Codex.

I risultati tecnici riportati hanno inoltre individuato nei socket Unix un potenziale obiettivo di particolare interesse. Un socket raggiungibile del demone Docker potrebbe avere conseguenze rilevanti, perché può esporre funzionalità ben più ampie della normale analisi di un repository. I ricercatori hanno inoltre rilevato l’accesso a uno strumento in grado di modificare la configurazione globale di Codex.

Overpatch amplia l’accesso in scrittura oltre l’area di lavoro

Overpatch prende di mira un controllo diverso del Codex CLI open source. Interessa la modalità workspace-write, progettata per consentire all’agente di modificare i file del progetto impedendogli di scrivere altrove.

In base a questa policy, i tentativi diretti dalla shell di scrivere nella directory home dello sviluppatore vengono rifiutati. L’aggiramento sfrutta invece lo strumento apply_patch integrato in Codex.

Il problema risiede nel modo in cui apply_patch determina l’ambito di scrittura autorizzato. Lo strumento calcola i permessi a partire dalle directory padre dei percorsi inclusi in una patch. Tali percorsi possono essere forniti all’interno di contenuti della patch controllati dall’agente.

L’exploit funzionante include due modifiche. La prima fa riferimento a /tmp, non perché l’attaccante debba necessariamente modificare un file al suo interno, ma perché quel percorso induce lo strumento ad ampliare l’ambito dei permessi fino alla radice del filesystem.

La seconda modifica segue un symlink e aggiunge un comando controllato dall’attaccante al file .zshrc dello sviluppatore. Quando la voce /tmp è presente, la scrittura esterna va a buon fine. Se la si rimuove, la stessa operazione viene negata.

Il comando iniettato non viene eseguito immediatamente. Viene eseguito al di fuori della sandbox di Codex quando, in un secondo momento, lo sviluppatore apre un terminale che elabora .zshrc.

Overpatch crea quindi un percorso di esecuzione ritardata e persistenza. L’agente sembra operare all’interno del progetto, ma la sua patch modifica il comportamento di avvio della shell nella directory home dell’utente.

Entrambe le falle collocano l’applicazione dei controlli nel posto sbagliato

Heapjack e Overpatch utilizzano tecniche diverse, ma alla base presentano un problema di progettazione simile: al componente soggetto a restrizioni è consentito partecipare all’applicazione delle proprie restrizioni.

Nel caso di Heapjack, un segreto di autenticazione privilegiato viene memorizzato in una porzione di memoria condivisa con JavaScript ostile. Il modello di sicurezza si affida a un token che l’ambiente di esecuzione non attendibile può recuperare e riutilizzare.

Nel caso di Overpatch, il componente di applicazione delle patch ricava la propria autorità dai percorsi forniti dall’agente che dovrebbe limitare. Una patch ostile può quindi influenzare il calcolo utilizzato per determinare dove sia consentito scrivere.

Si tratta di problemi di fiducia mal riposta, non di semplici bug di parsing. L’agente non deve necessariamente infrangere direttamente una sandbox del kernel se riesce a convincere un meccanismo esterno attendibile a eseguire l’azione sensibile.

A luglio 2026 sono stati segnalati problemi analoghi nei confini di fiducia degli agenti che coinvolgevano Cursor, Codex, Gemini CLI e Antigravity di Google. In quei casi, l’agente poteva rimanere tecnicamente all’interno della sandbox mentre faceva eseguire a uno strumento più attendibile un file creato dall’agente stesso.

La lezione ricorrente è circoscritta ma importante: isolare il processo dell’agente nella sandbox non basta quando gli strumenti ausiliari, la memoria condivisa, i gestori della configurazione o gli esecutori esterni accettano input influenzabili dall’agente.

Gli sviluppatori devono aggiornare entrambi i prodotti Codex

Per risolvere Heapjack, gli utenti devono installare la build 26.818.21641 o una versione successiva di Codex Desktop. Per correggere Overpatch, devono invece aggiornare il Codex CLI alla versione 0.149.0 o successiva.

Applicare un solo aggiornamento non è sufficiente, perché le vulnerabilità interessano componenti e modalità di sicurezza differenti.

Fino alla distribuzione degli aggiornamenti, gli sviluppatori dovrebbero evitare di aprire in Codex repository provenienti da autori non attendibili. L’analisi in sola lettura non deve essere considerata una difesa completa contro le istruzioni contenute nei repository o l’esecuzione controllata dall’agente.

I responsabili della sicurezza e gli utenti interessati possono inoltre verificare:

• ~/.codex/config.toml alla ricerca di configurazioni node_repl inattese o di altre modifiche non autorizzate.
• .zshrc e gli altri file di avvio della shell alla ricerca di comandi sconosciuti aggiunti in coda.
• Invocazioni del comando di sistema open correlate a Codex.
• Accessi inattesi a socket Unix, in particolare ai socket del demone Docker.
• Attività di applicazione di patch che coinvolgono /tmp, l’ambito della radice del filesystem o symlink diretti al di fuori del progetto.
• Applicazioni avviate al di fuori dell’albero dei processi previsto per Codex.

Heapjack può lasciare meno tracce evidenti, perché non richiede una normale scrittura su file e può eseguire comandi senza un prompt visibile. La telemetria dei processi, i log di accesso ai socket e i registri di esecuzione dei comandi potrebbero quindi essere più utili del solo controllo del repository.

Overpatch ha maggiori probabilità di lasciare un artefatto persistente in .zshrc, ma il comando malevolo potrebbe non essere eseguito fino alla sessione successiva del terminale.

Non risultano sfruttamenti

Al momento non ci sono prove che gli attaccanti abbiano utilizzato Heapjack o Overpatch contro utenti di Codex prima della disponibilità delle correzioni. L’assenza di attacchi documentati non riduce il rischio creato dall’apertura di un repository controllato da un attaccante.

Non sono stati segnalati identificativi CVE, punteggi CVSS, intervalli di versioni interessate o inserimenti nel catalogo CISA Known Exploited Vulnerabilities. Non sono inoltre note le build vulnerabili precise che precedevano le release corrette.

Il riferimento operativo è quindi rappresentato dalle versioni aggiornate: build 26.818.21641 di Codex Desktop e versione 0.149.0 di Codex CLI. Qualsiasi installazione precedente alle rispettive release deve essere aggiornata, invece di fare affidamento sulle modalità di sola lettura o workspace-write come misura di protezione.