Dos fugas del sandbox de OpenAI Codex: cómo abrir un repositorio en el agente bastaba para que su autor ejecutase código en tu máquina

Dos vulnerabilidades descubiertas por Oren Yomtov, de Accomplish AI, demuestran que abrir un repositorio externo en OpenAI Codex podía bastar para que su autor ejecutase comandos sin sandbox en la máquina del desarrollador. Una de las dos fugas funcionaba incluso en el modo más restrictivo del agente, donde, sobre el papel, no debería poder escribir nada.

Ambas se notificaron a OpenAI el 12 de agosto y quedaron parcheadas en ocho días. La primera, bautizada como Heapjack, es la grave: convierte un repositorio de terceros en un vector de ejecución remota. La segunda, Overpatch, secuestra la herramienta de parches interna de Codex para escribir fuera del workspace.

Codex es el agente de programación de OpenAI, disponible como CLI y como app de escritorio. Igual que Cursor, Claude Code o Gemini CLI, aísla sus acciones en un sandbox para que el código que manipula no pueda tocar el resto del sistema. Las dos fugas derrotan ese aislamiento desde dentro.

Heapjack: robar el token al proceso Node

El primer ataque apunta al componente node_repl, que Codex Desktop escribe en el archivo global ~/.codex/config.toml al instalarse. No hay opción para desactivarlo, y los usuarios de la CLI heredan la misma herramienta sin que se les pregunte.

node_repl levanta un único proceso Node.js que sostiene dos contextos de JavaScript en paralelo. Uno es de confianza y contiene el código de OpenAI; el otro no lo es y ejecuta el código del agente. El contexto de confianza se identifica presentando un token aleatorio generado en cada arranque.

El problema es que ambos contextos viven en el mismo proceso Node y comparten el mismo heap de memoria. El token, por tanto, no es más que un string dentro del heap al que el lado no confiable puede llegar.

El camino del ataque es directo. El código no confiable toma una instantánea del heap con v8.getHeapSnapshot() y va probando cadenas con forma de UUID. Si el token falla, obtiene «not authorized». Si el token acierta pero el argumento es incorrecto, recibe un error de validación real, señal inequívoca de que ha encontrado el bueno.

Con el token en la mano, el código no confiable escribe su propia petición en el mismo pipe que el contexto de confianza usa para hablar con un proceso padre nativo, no confinado. El padre valida el token, lo ve legítimo y ejecuta la acción fuera del sandbox.

La prueba de concepto usó el comando open del sistema para lanzar una aplicación fuera del árbol de procesos de Codex. El mismo acceso llega a cualquier socket Unix — un socket del daemon de Docker es el objetivo obvio — y a una herramienta que edita el archivo de configuración global.

Todo esto ocurre en modo read-only, el nivel más estricto del sandbox, en el que el agente, en teoría, ni siquiera debería poder escribir.

Overpatch: la herramienta de parches que se autodefine sus permisos

La segunda vulnerabilidad vive 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 home recibe un rechazo.

Los investigadores convencieron a la herramienta interna de parches, apply_patch, de escribir igualmente en ese directorio prohibido. La herramienta concede acceso de escritura a la carpeta padre de cada ruta mencionada en un parche. Nombra /tmp y concedes acceso de escritura a la raíz del disco.

El exploit funcional usa un parche con dos cambios: uno que menciona /tmp sin hacer nada útil excepto ampliar permisos, y otro que añade una línea a .zshrc a través de un enlace simbólico que apunta al home. Quita el primer cambio y la escritura se rechaza. Con él, el próximo terminal que abra el desarrollador ejecuta la línea del atacante, ya fuera del sandbox.

El mismo patrón, repetido

Las dos vulnerabilidades comparten una estructura: el mecanismo que debía imponer el aislamiento vivía dentro de aquello que tenía que aislar. apply_patch deducía sus propios permisos a partir de entradas controladas por el atacante. node_repl guardaba el secreto que separaba el código de confianza del que no lo era en la misma memoria que el código no confiable.

En ambos casos, el sandbox recibió desde dentro la orden de dejar pasar algo.

La clase de bug no es nueva. En julio de 2026, los investigadores de Pillar Security demostraron la misma idea contra Cursor, Codex, Gemini CLI y Antigravity de Google: un agente que se mantiene dentro de su sandbox escribe un archivo que una herramienta de confianza fuera del sandbox ejecuta después. Lo que cambia ahora es que las dos fugas se dan en el modo más restrictivo del producto, no en configuraciones permisivas.

Cómo mitigarlo

OpenAI corrigió Heapjack en Codex Desktop build 26.818.21641 y Overpatch en Codex CLI 0.149.0. Si usas Codex en cualquiera de sus dos formas, actualiza a esa versión o posterior.

Más allá del parche, hay una lección de arquitectura que los desarrolladores de agentes deberían grabarse a fuego: un sandbox cuyo mecanismo de enforce comparte memoria con el código que debería estar confinado no es un sandbox, es una promesa que el heap nunca firmó. La separación entre código de confianza y código no confiable tiene que vivir en procesos distintos, idealmente con distintos privilegios de sistema operativo, o el límite deja de existir en el momento en que un atacante lo busca.

En resumen: dos fugas del mismo tipo en el mismo agente, ambas con un denominador común — el guardián y el guarded compartían casa — bastan para recordar que ejecutar código generado por IA sigue siendo ejecutar código de un autor en el que, hasta que demuestre lo contrario, no se puede confiar.