Overpatch and Heapjack: Two Techniques for Bypassing Codex's Write Restrictions and Escaping Its Read-Only Sandbox

Two novel bypass techniques have been discovered that allow circumventing the security measures of OpenAI Codex's sandbox environment. The first technique, dubbed Overpatch, enables writing data outside the sandbox workspace. This vulnerability arises from the Codex CLI's apply_patch function, which erroneously grants write permissions based on the parent directory of specified paths in a patch.

Researchers crafted a patch file that targeted the /tmp directory, while simultaneously creating a symbolic link within the sandbox to alter the $HOME/.zshrc configuration file. As a result, any commands added to this file would be executed outside the sandbox when the developer subsequently opens a terminal.

The second technique, Heapjack, allows execution of host commands even when Codex is in read-only mode. This vulnerability is exploited by recovering the trusted context's authorization token from the shared V8 heap within Codex Desktop. By submitting forged requests to the unsandboxed native parent process, Heapjack can execute malicious commands.

This is achieved by analyzing the V8 heap snapshot for UUID-shaped token strings and identifying the correct token through a token oracle mechanism. Once the token is obtained, Heapjack can send forged requests to the native node_repl parent process, effectively bypassing Codex's sandbox restrictions. In the demonstration PoC, the macOS open command was successfully executed outside the sandbox, highlighting the severity of this vulnerability.

Both Overpatch and Heapjack were reported to the OpenAI Codex developers and promptly patched within eight days of disclosure. No real-world attacks have been reported thus far. The researchers recommend updating to Codex CLI version 0.149.0 or later and Codex Desktop build 26.818.21641 or later to mitigate these security risks.

Additionally, implementing containment measures such as running the agent, tools, and child processes within a separate VM boundary, and restricting access to paths and sockets outside the workspace, are advised as further protective measures.