Dos formas de salir del sandbox de OpenAI Codex: Heapjack y Overpatch

El 15 de septiembre de 2026, Oren Yomtov, investigador principal de seguridad en Accomplish AI, publicó un relato técnico de dos formas distintas de escapar de la sandbox que rodea al agente de programación Codex de OpenAI. Según su informe, ambas se notificaron a OpenAI el 12 de agosto de 2026 y ambas se corrigieron en un plazo de ocho días: Heapjack en Codex Desktop build 26.818.21641 y Overpatch en Codex CLI 0.149.0. Heapjack es la más grave de las dos. No requiere nada de la persona atacada más allá de abrir un repositorio en Codex y hacer una pregunta sobre el código, y se ejecuta en modo de solo lectura, el modo más estricto que ofrece el producto, sin solicitud de aprobación y sin nada mostrado en pantalla. Según la Cloud Security Alliance, no se asignó ningún CVE a ninguna de las dos fallas ni se publicó un aviso independiente de OpenAI, y no se ha reportado que nadie haya resultado perjudicado por ellas. Se cataloga junto con las demás entradas de control de agentes del año en el archivo de incidentes de IA, donde cada registro incluye sus documentos de origen, su grado de confianza y su indicador de disputa.

Heapjack: el token residía en un heap que el lado no confiable podía leer

Codex Desktop no pregunta antes de instalar el componente que Yomtov atacó. Durante la instalación, escribe un bloque node_repl en el archivo de configuración global en ~/.codex/config.toml, y Yomtov informa que no hay opt-in ni ningún ajuste que lo desactive. Como la entrada reside en la configuración compartida en lugar de en una elección por usuario, un usuario normal de Codex CLI hereda la misma herramienta sin que se le pregunte en ningún momento.

La herramienta node_repl es en sí misma un programa nativo que se ejecuta fuera del sandbox. Puede abrir aplicaciones, conectarse a sockets Unix y editar el archivo de configuración global. Lo que inicia dentro del sandbox es un único proceso Node.js, y ese proceso alberga dos contextos de ejecución de JavaScript: uno de confianza que contiene el propio código de OpenAI, y otro no confiable que ejecuta lo que se le haya pedido hacer al agente.

El contexto de confianza demuestra que es de confianza presentando un token aleatorio, generado de nuevo en cada ejecución. Se supone que esa es la frontera entre los dos contextos. No lo es, porque ambos contextos viven en un único isolate de V8 que comparte un único heap de memoria, así que el token es una cadena que está en memoria y que el código no confiable puede leer. Un comentarista que reaccionó a la revelación en X expresó el punto con más crudeza, en una frase que BleepingComputer citó: «Los contextos de V8 aíslan los globales, no la memoria, así que el sandbox era en realidad una promesa que el heap nunca aceptó». Esa es una caracterización, no una prueba; la prueba es la prueba de concepto.

El exploit de Yomtov hace exactamente lo que implica esa descripción. JavaScript que no es de confianza llama a v8.getHeapSnapshot(), escanea la instantánea resultante en busca de cadenas con forma de UUID y prueba cada candidata. Una conjetura incorrecta devuelve «not authorized». Un token correcto combinado con un argumento no válido devuelve, en cambio, un error de validación genuino. La diferencia entre los dos mensajes de error es el oráculo que identifica el valor correcto.

Con el token en mano, el proceso en sandbox escribe su propia solicitud JSON en el descriptor de archivo 1 — la misma tubería stdout que el contexto de confianza usa para llegar al padre nativo. El padre valida el token, encuentra uno válido y hace el trabajo. En la prueba de concepto, ese trabajo era el comando de apertura del sistema, que entrega la solicitud a launchd y lanza la aplicación fuera del árbol de procesos de Codex por completo. El mismo token permite conexiones a sockets Unix arbitrarios, entre ellos un socket del daemon de Docker, y llega a una herramienta para editar el archivo de configuración global.

Todo se ejecuta en modo de solo lectura, el modo que un usuario cauteloso selecciona precisamente porque el repositorio que tiene delante no es de confianza. No apareció ninguna solicitud de aprobación en ninguna etapa. El escenario práctico es breve: abrir un repositorio clonado en Codex, en modo de solo lectura, y hacer una pregunta sobre el código. Quien haya escrito ese repositorio obtiene ejecución de comandos sin sandbox en la máquina, y nada en pantalla lo indica.

Overpatch: una herramienta de parches que otorgaba el padre de todo lo que tocaba

El segundo fallo reside en Codex CLI, el agente de línea de comandos de código abierto, y es un error de permisos en lugar de uno de memoria. En el modo workspace-write, el agente puede escribir dentro de la carpeta del proyecto y en ningún otro lugar; un comando de shell dirigido al directorio home se rechaza. Se suponía que la herramienta apply_patch debía respetar esa restricción. En cambio, derivaba sus permisos de las rutas nombradas en el parche que estaba aplicando, y concedía acceso de escritura al directorio padre de cada una.

Nombra una ruta bajo /tmp en un parche y la concesión se amplía hasta la raíz del disco, porque el directorio padre de /tmp es /. Ese es todo el truco.

El exploit funcional utiliza dos entradas en un solo parche. La primera nombra /tmp y no hace nada útil —falla, ya que un archivo no puede sobrescribir un directorio— y existe solo para ampliar el permiso concedido. La segunda añade una línea a .zshrc mediante un enlace simbólico hacia el directorio home. Si se elimina la primera entrada, la escritura se rechaza. Si se mantiene, el siguiente terminal que el desarrollador abra ejecutará la línea del atacante sin sandbox, con el sandbox completamente fuera del proceso.

Eso convierte a Overpatch en un bug de persistencia en lugar de un ataque de un solo uso. El archivo de arranque envenenado se ejecuta de nuevo en cada shell que abre el desarrollador, hasta que alguien lee .zshrc y advierte la línea añadida; por eso la recomendación de Cloud Security Alliance es ir a buscarlo en lugar de esperar a que aparezca un síntoma.

Ambos errores sitúan la aplicación de la restricción dentro de aquello mismo que se restringe.

El propio planteamiento de Yomtov es la parte que trasciende Codex. apply_patch calculaba sus propios permisos a partir de datos de entrada proporcionados por un atacante. node_repl mantenía en memoria el secreto que separa el código confiable del no confiable, una memoria que el código no confiable podía leer. En cada caso, se le indicó al sandbox, desde dentro, que dejara pasar algo.

La forma no es nueva. BleepingComputer, que informó de la divulgación el 20 de septiembre de 2026, señala que en julio de 2026 los 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 de confianza fuera del sandbox ejecuta después. Lo que distingue al par de Codex es el bypass de solo lectura en Heapjack y la ausencia de cualquier ajuste para desactivar el componente que lo porta.

Las correcciones, y lo que OpenAI ha dicho y no ha dicho

OpenAI corrigió Heapjack en la compilación 26.818.21641 de Codex Desktop y Overpatch en Codex CLI 0.149.0, según Accomplish. Ambos llegaron dentro de los ocho días posteriores al informe del 12 de agosto —para el 20 de agosto, según una lectura literal de esa cronología—, y Yomtov atribuyó a OpenAI el cambio de rumbo.

OpenAI no publicó ningún aviso de seguridad independiente para ninguna de las dos fallas, y no se asignó ningún identificador CVE; la Cloud Security Alliance registra ambas ausencias en una nota de investigación fechada el 22 de septiembre de 2026. Cuando se le pidió comentario, un portavoz de OpenAI dijo a BleepingComputer: "Agradecemos a los investigadores por contactarnos y compartir sus hallazgos. Abordamos ambos problemas en agosto, pero fortalecemos continuamente nuestros entornos aislados, con actualizaciones recientes que refuerzan los controles sobre dónde pueden escribir archivos los agentes y amplían las pruebas de esas protecciones en todas las plataformas".

Esa declaración confirma las correcciones y no dice nada sobre los mecanismos. No dice si los cambios de agosto eliminaron el patrón de diseño o cerraron los dos caminos específicos para salir de él. Tampoco lo ha dicho nadie fuera de OpenAI.

Qué está establecido y qué depende de un solo investigador

El archivo registra esta entrada como un hallazgo de investigación, gravedad alta, región global, confianza B —documentado, pero a partir de una fuente única o secundaria—, no disputado y sin daños reales registrados. Esa calificación es la lente correcta para leer el resto de este artículo, porque la división entre lo que confirman varias partes y lo que solo afirma quien hizo el hallazgo recorre toda la historia.

Establecido, en el sentido de que más de una parte lo afirma:

• La divulgación existe y está fechada. El informe de Yomtov se publicó el 15 de septiembre de 2026; ambos fallos se notificaron a OpenAI el 12 de agosto de 2026 y, según su versión, se corrigieron en un plazo de ocho días.

• OpenAI confirma que actuó en agosto. Su portavoz dijo a BleepingComputer que ambos problemas fueron solucionados, lo que corrobora la cronología de notificación y corrección de forma independiente del descubridor, aunque la empresa no publicó ningún aviso ni una explicación técnica propia.

• Las versiones corregidas se indican de forma coherente. La compilación 26.818.21641 para Codex Desktop y la versión 0.149.0 para Codex CLI son proporcionadas por Accomplish, repetidas por BleepingComputer y recogidas en un aviso del 22 de septiembre de 2026 del Uganda National Computer Emergency Response Team and Coordination Center, que calificó el par como «Red».

• Sin CVE, sin aviso del proveedor y sin explotación reportada. La nota de Cloud Security Alliance del 22 de septiembre de 2026 registra la ausencia tanto de una CVE como de un aviso independiente de OpenAI, y no informa de casos confirmados de que una organización haya encontrado implementado el mecanismo de persistencia de Overpatch.

• El archivo no lo disputa en absoluto. El registro está marcado como no disputado, y su grado de confianza refleja el patrón de las fuentes más que cualquier desacuerdo sobre los hechos.

No establecido, o establecido por nadie más que quien lo encontró:

• El detalle del mecanismo es de Yomtov. El oráculo de instantáneas de heap, el descriptor de archivo compartido y la concesión del directorio padre —todo ello proviene de su informe y su prueba de concepto. Cloud Security Alliance, cuya nota es el resumen de terceros más detallado en circulación, describe que sintetiza su relato y la cobertura de BleepingComputer, y no afirma haber reproducido ninguno de los dos exploits ni haber probado ninguna de las dos correcciones. El aviso de CERT.UG recopila el mismo material.

• Los rangos de versiones vulnerables nunca se publicaron. Solo se indican las versiones corregidas, por lo que no hay una lista de qué compilaciones anteriores incluían cada fallo.

• No se especifica si una instalación parcheada está a salvo de la clase de vulnerabilidad, en lugar de estarlo solo de estas dos instancias. La frase de OpenAI «fortalecer continuamente nuestras sandboxes» es un compromiso general, no una afirmación sobre un mecanismo específico.

• No se ha informado de que nadie haya explotado ninguna de las dos fallas. Eso es una ausencia de reportes, no una constatación de ausencia, y la prueba de concepto muestra que la vía de Heapjack no deja nada en pantalla que un usuario pueda notar.

Aquello sobre lo que un usuario puede actuar

Cualquier persona que use una compilación de Codex Desktop anterior a 26.818.21641, o una versión de Codex CLI anterior a 0.149.0, está del lado vulnerable de la línea que traza Accomplish, y actualizar es el único remedio que ofrece la divulgación. Además, Cloud Security Alliance recomienda auditar las sesiones pasadas de Codex Desktop que hayan involucrado repositorios no confiables en busca de actividad de launchd o de open y de conexiones al socket de Docker, y leer los archivos de inicio del shell —.zshrc, .bashrc y sus equivalentes— en busca de comandos que se hayan añadido en lugar de haber sido escritos por el usuario.

La misma nota desaconseja tratar el modo de solo lectura como protección cuando el repositorio no es de confianza, que es la conclusión a la que Heapjack llega por su cuenta. Sus recomendaciones estructurales van más allá: aislamiento físico de procesos y memoria en lugar de secretos compartidos y convenciones, credenciales mantenidas fuera del alcance del agente, y parches que hacen referencia a rutas fuera del proyecto tratados como sospechosos a primera vista. Esas son propuestas de un tercero. No se sabe públicamente si OpenAI ha adoptado alguna de ellas más allá de los dos incrementos de versión.

Al final, vale la pena mantener separadas dos cosas. Una es un par de errores en un agente de programación muy utilizado, notificados el 12 de agosto de 2026, corregidos en menos de ocho días y cerrados en dos números de compilación. La otra es la cuestión de diseño que Yomtov señala —si un entorno aislado puede ser impuesto por el propio código que se supone debe contener—, y esa pregunta no es algo que responda un número de versión. Ni Accomplish ni OpenAI han dicho que los cambios de agosto la resuelvan.