Investigadores de seguridad encontraron dos formas de escapar del sandbox de OpenAI Codex, una de ellas capaz de ejecutar comandos en la máquina de un desarrollador desde el modo más restringido de Codex, sin solicitud de aprobación y sin que se mostrara nada en pantalla.

Ambos fallos fueron reportados a OpenAI el 12 de agosto y corregidos en ocho días, según Oren Yomtov de Accomplish AI.

El más grave de los dos, que los investigadores llaman Heapjack, convierte una acción rutinaria en una ejecución remota de código: abrir el repositorio de otra persona en Codex, hacerle una pregunta sobre el código, y quienquiera que haya escrito ese repositorio obtiene la ejecución de comandos fuera del sandbox en su computadora.

Codex es el agente de programación de OpenAI, disponible como herramienta de línea de comandos y aplicación de escritorio. Al igual que los agentes rivales, ejecuta las acciones del modelo dentro de un sandbox para que el código no confiable no pueda tocar el sistema general. Ambos escapes funcionan derrotando ese límite desde el interior.

Heapjack

La técnica Heapjack, descrita en el informe de Yomtov [https://www.accomplish.ai/blog/escaping-the-openai-codex-sandbox-twice/], se dirige a un componente llamado node_repl, que Codex Desktop escribe en el archivo global '~/.codex/config.toml' al momento de la instalación.

No hay opción de inclusión ni configuración para desactivarlo, y debido a que la entrada reside en la configuración compartida, los usuarios de Codex CLI heredan la misma herramienta sin que se les pregunte.

node_repl ejecuta un único proceso de Node.js que contiene dos contextos de ejecución de JavaScript separados. Uno es confiable y contiene el código propio de OpenAI. El otro no es confiable y ejecuta el código del agente. El contexto confiable demuestra que lo es presentando un token aleatorio generado en cada ejecución.

El problema es que ambos contextos viven en un proceso de Node y comparten un mismo montón (heap) de memoria, por lo que el token es simplemente una cadena de texto en la memoria que el lado no confiable puede leer.

La ruta de ataque Heapjack (Accomplish.ai)

El código no confiable toma una instantánea del heap con 'v8.getHeapSnapshot()' e intenta cada cadena con forma de UUID. Una suposición incorrecta devuelve "not authorized". Un token correcto con un argumento incorrecto devuelve un error de validación real, lo que indica al atacante que el token es correcto.

Con el token, el código no confiable escribe su propia solicitud en el mismo conducto (pipe) que el contexto confiable utiliza para hablar con un proceso padre nativo y fuera del sandbox.

El padre verifica el token, ve que es válido y realiza el trabajo. La prueba de concepto utilizó el comando 'open' del sistema para lanzar una aplicación completamente fuera del árbol de procesos de Codex. El mismo acceso llega a cualquier socket de Unix, siendo el socket del demonio de Docker el objetivo obvio, y a una herramienta para editar el archivo de configuración global.

Todo esto se ejecuta en modo de solo lectura, el modo de sandbox más estricto, donde se supone que el agente no debe escribir absolutamente nada.

Overpatch

El segundo fallo, Overpatch, se encuentra en el Codex CLI de código abierto. En el modo de escritura de espacio de trabajo, el agente solo puede escribir dentro de la carpeta del proyecto, y se rechaza cualquier comando de shell dirigido al directorio principal.

Los investigadores lograron que la propia herramienta de parches de Codex, apply_patch, escribiera allí de todos modos.

La herramienta concede acceso de escritura a la carpeta padre de cada ruta nombrada en un parche. Nombre '/tmp' y concederá acceso de escritura a la raíz del disco.

El exploit funcional utiliza un parche con dos cambios: uno que nombra '/tmp' y no hace nada útil excepto ampliar el permiso, y otro que añade una línea a '.zshrc' a través de un enlace simbólico al directorio principal.

Si se elimina el primer cambio, la escritura es rechazada. Con él, la siguiente terminal que abra el desarrollador ejecuta la línea del atacante fuera del sandbox.

el mismo error subyacente

Ambos errores comparten una estructura: el mecanismo de aplicación vivía dentro de aquello que se suponía debía aplicar. apply_patch calculaba sus propios permisos a partir de la entrada proporcionada por el atacante. node_repl mantenía el secreto que separaba el código confiable del no confiable en la misma memoria que el código no confiable.

En cada caso, se le indicó al sandbox, desde el interior, que dejara pasar algo.

Esta clase de error no es nueva. En julio de 2026, investigadores de Pillar Security demostraron la misma idea en Cursor, Codex, Gemini CLI y Antigravity de Google, donde un agente que permanece dentro de su sandbox escribe un archivo que una herramienta confiable fuera del sandbox ejecuta posteriormente.

Reaccionando a la publicación de Yomtov en X, un comentarista escribió que [https://x.com/0zSchnack/status/2100164179399242043] "los contextos V8 aíslan los globales, no la memoria, por lo que el sandbox era en realidad una promesa que el heap nunca aceptó". Otro llamó al límite de confianza "un divisor de habitaciones [https://x.com/ctfstudent/status/2100281489774526867]". El comportamiento habilitado por defecto atrajo su propio escrutinio, preguntándose por qué un token privilegiado era accesible desde JavaScript no confiable.

¿Qué hacer?

OpenAI corrigió Heapjack en la versión 26.818.21641 de Codex Desktop y Overpatch en Codex CLI 0.149.0, según Accomplish.

Los usuarios deben actualizar a esas versiones o posteriores. Yomtov acreditó a OpenAI la resolución de ambos problemas en un plazo de ocho días tras su informe.


Fuente:
BleepingComputer