Investigadores logran escapar del sandbox de OpenAI Codex y ejecutar comandos en el host

Investigadores escapan del sandbox de OpenAI Codex para ejecutar comandos en el host

Por Ax Sharma, 20 de septiembre de 2026, 08:00 AM. Investigadores de seguridad encontraron dos formas de salir del sandbox de OpenAI Codex, una de ellas capaz de ejecutar comandos en la máquina de un desarrollador desde el modo más bloqueado de Codex, sin solicitud de aprobación y sin mostrar nada en pantalla. Ambas fallas fueron reportadas a OpenAI el 12 de agosto y corregidas en un plazo de ocho días, según Oren Yomtov de Accomplish AI.

La más grave de las dos, que los investigadores denominan Heapjack, convierte una acción rutinaria en ejecución remota de código: abrir el repositorio de otra persona en Codex, hacer una pregunta sobre el código y quien haya escrito ese repositorio obtiene ejecución de comandos sin sandbox en tu computadora. Codex es el agente de codificación de OpenAI, disponible como herramienta de línea de comandos y aplicación de escritorio. Al igual que agentes rivales, ejecuta las acciones del modelo dentro de un sandbox para que el código no confiable no pueda tocar el sistema en general. Ambas fugas funcionan derrotando esa frontera desde adentro.

Heapjack

La técnica Heapjack, según el informe de Yomtov, ataca un componente llamado node_repl, que Codex Desktop escribe en el archivo global '~/.codex/config.toml' durante la instalación. No hay opción de adhesión ni configuración para desactivarlo, y como la entrada vive 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 mantiene 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 es confiable presentando un token aleatorio generado de nuevo en cada ejecución.

El problema es que ambos contextos viven en un mismo proceso de Node y comparten un mismo montón de memoria, por lo que el token es solo una cadena en memoria que el lado no confiable puede leer. El código no confiable toma una instantánea del montón con 'v8.getHeapSnapshot()' y prueba cada cadena con forma de UUID. Una suposición incorrecta devuelve 'no autorizado'. 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 la misma tubería que el contexto confiable usa para comunicarse con un proceso padre nativo sin sandbox. El padre verifica el token, ve uno válido y hace el trabajo. La prueba de concepto utilizó el comando 'open' del sistema para lanzar una aplicación fuera del árbol de procesos de Codex por completo. El mismo acceso llega a cualquier socket de Unix, siendo el socket del daemon 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 nada.

Overpatch

La segunda falla, Overpatch, se encuentra en el Codex CLI de código abierto. En modo workspace-write, el agente solo puede escribir dentro de la carpeta del proyecto, y un comando de shell dirigido al directorio home es rechazado. Los investigadores lograron que la propia herramienta de parches de Codex, apply_patch, escribiera allí de todos modos. La herramienta otorga acceso de escritura a la carpeta padre de cada ruta nombrada en un parche. Nombra '/tmp' y otorga 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 en el directorio home. Elimina el primer cambio y la escritura es rechazada. Con él, la próxima terminal que abra el desarrollador ejecuta la línea del atacante sin sandbox.

El mismo error subyacente

Ambos errores comparten una forma: el mecanismo de aplicación vivía dentro de lo que se suponía que 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 separa el código confiable del no confiable en la misma memoria que el código no confiable. En cada caso, se le dijo al sandbox, desde adentro, 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 después. Reaccionando a la publicación de Yomtov en X, un comentarista escribió que 'los contextos de V8 aíslan globales, no memoria, así que el sandbox era realmente una promesa que el montón nunca aceptó'. Otro llamó a la frontera de confianza 'un separador de ambientes'. El comportamiento habilitado por defecto atrajo su propio escrutinio, y uno preguntó por qué un token privilegiado era accesible desde JavaScript no confiable.

Qué hacer

OpenAI corrigió Heapjack en la compilació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 atribuyó a OpenAI haber resuelto ambos problemas en los ocho días posteriores a su informe. BleepingComputer se comunicó con OpenAI para obtener comentarios antes de la publicación.

Construya su plano de seguridad para ataques impulsados por IA

Únase a Mikko Hyppönen y líderes de seguridad de la NFL, CHANEL y Atlassian para un summit digital de dos horas sobre qué cambian los ataques a velocidad de IA, qué deben dejar de hacer los defensores y cómo validar, decidir, corregir y revalidar a velocidad de máquina.