Los fallos del sandbox de OpenAI Codex convierten el análisis de repositorios en ejecución de comandos a nivel del host

Dos vulnerabilidades de OpenAI Codex permitían que operaciones controladas por el agente escaparan de sus límites de seguridad previstos y afectaran al sistema host del desarrollador. Una funcionaba incluso con la política de solo lectura más restrictiva, mientras que la otra eludía las restricciones de escritura limitada al espacio de trabajo.

Los investigadores bautizaron los fallos como Heapjack y Overpatch. Heapjack afecta a Codex Desktop y puede permitir la ejecución de comandos fuera del sandbox sin solicitar aprobación ni mostrar una advertencia visible. Overpatch afecta al Codex CLI de código abierto y puede modificar archivos fuera del directorio del proyecto permitido, incluido el archivo .zshrc del usuario.

Ambas vulnerabilidades se notificaron a OpenAI el 12 de agosto de 2026. OpenAI las solucionó en un plazo de ocho días: publicó Codex Desktop build 26.818.21641 para Heapjack y Codex CLI 0.149.0 para Overpatch.

No se han divulgado identificadores CVE ni puntuaciones CVSS oficiales. Tampoco existen indicios públicos de que alguna de las dos vulnerabilidades se haya explotado activamente.

Heapjack rompe el límite de seguridad de solo lectura

Heapjack es el más grave de los dos hallazgos porque puede pasar del análisis de código dentro del sandbox a la actividad a nivel del host. Un desarrollador podría activar el ataque al abrir en Codex el repositorio de otra persona y pedirle al agente que respondiera a una pregunta sobre su contenido.

El exploit sigue funcionando cuando Codex está configurado en modo de solo lectura. Con esta política, lo habitual sería esperar que el agente inspeccionara los archivos sin modificar el sistema ni ejecutar operaciones en el host fuera del sandbox.

Sin embargo, Heapjack apunta al componente node_repl instalado por Codex Desktop. Durante la instalación, Codex Desktop añade este componente al archivo de configuración global ubicado en:

~/.codex/config.toml

El componente está habilitado de forma predeterminada. No requiere una activación independiente y no se ha divulgado ninguna opción específica para deshabilitarlo. Como la configuración es global, los usuarios del Codex CLI también pueden heredar la herramienta sin recibir otra solicitud de autorización.

Esto significa que la capacidad vulnerable no está limitada a un único repositorio ni a una sesión aprobada explícitamente. Pasa a formar parte del entorno compartido de Codex del usuario.

Un token secreto almacenado junto a JavaScript no confiable

El diseño vulnerable de node_repl utiliza un proceso de Node.js que contiene dos contextos de JavaScript independientes. Uno es de confianza y ejecuta código de OpenAI. El otro no es de confianza y ejecuta código controlado por el agente.

El contexto de confianza se comunica con un proceso principal nativo que se ejecuta fuera del sandbox. Autentica cada solicitud mediante un token generado aleatoriamente para esa ejecución.

Sin embargo, separar los contextos de JavaScript no separa su memoria subyacente. Ambos contextos utilizan el mismo heap de Node.js, por lo que el token de autenticación queda al alcance del código que se ejecuta en el contexto no confiable.

La prueba de concepto de Heapjack llama a:

v8.getHeapSnapshot()

A continuación, examina la instantánea del heap de V8 resultante en busca de cadenas que coincidan con la estructura esperada, similar a un UUID, del token. Encontrar valores candidatos es solo el primer paso. El exploit también debe determinar cuál de ellos es válido.

Los investigadores lo consiguieron observando cómo respondía el proceso principal a diferentes solicitudes. Un token incorrecto provocaba un fallo de autorización. Un token correcto enviado con un argumento no válido producía un error de validación diferente. Esta distinción actuaba como un oráculo de autenticación que confirmaba cuándo se había recuperado el token legítimo.

El contexto no confiable podía entonces escribir una solicitud falsificada en el mismo canal de comunicación utilizado por el componente de confianza. Como el mensaje contenía el token válido, el proceso principal sin sandbox lo aceptaba y ejecutaba la operación solicitada.

En el ataque demostrado, el proceso principal invocaba el comando open del sistema para iniciar una aplicación fuera del árbol de procesos de Codex. La operación no generaba ninguna solicitud de aprobación ni indicación visible en pantalla dentro de Codex.

Los hallazgos técnicos publicados también identificaron los sockets Unix como un posible objetivo de gran valor. En particular, un socket accesible del daemon de Docker podría tener consecuencias importantes, ya que puede exponer capacidades que van mucho más allá del análisis habitual de repositorios. Los investigadores también obtuvieron acceso a una herramienta capaz de editar la configuración global de Codex.

Overpatch amplía el acceso de escritura más allá del espacio de trabajo

Overpatch ataca un control diferente del Codex CLI de código abierto. Afecta al modo de escritura en el espacio de trabajo, diseñado para permitir que el agente modifique archivos del proyecto e impedir las escrituras en cualquier otra ubicación.

Con esta política, los intentos directos desde el shell de escribir en el directorio personal del desarrollador son rechazados. El bypass utiliza, en cambio, la propia herramienta apply_patch de Codex.

El problema reside en cómo apply_patch determina el ámbito de escritura autorizado. La herramienta calcula los permisos a partir de los directorios principales de las rutas incluidas en un parche. Esas rutas pueden introducirse mediante contenido del parche controlado por el agente.

El exploit funcional incluye dos cambios. El primero hace referencia a /tmp, no porque el atacante tenga necesariamente que modificar allí un archivo, sino porque esa ruta hace que la herramienta amplíe el ámbito de permisos hasta la raíz del sistema de archivos.

El segundo cambio sigue un enlace simbólico y añade un comando controlado por el atacante al archivo .zshrc del desarrollador. Al incluir la entrada /tmp, la escritura externa se completa correctamente. Si se elimina esa entrada, la misma operación es denegada.

El comando inyectado no se ejecuta de inmediato. Se ejecuta fuera del sandbox de Codex cuando el desarrollador abre posteriormente un terminal que procesa .zshrc.

Por tanto, Overpatch crea una vía de ejecución diferida y persistencia. El agente parece trabajar dentro del proyecto, pero su operación de parche modifica el comportamiento de inicio del shell en el directorio personal del usuario.

Ambos fallos sitúan la aplicación de las restricciones en el lugar equivocado

Heapjack y Overpatch utilizan técnicas diferentes, pero su fallo de diseño subyacente es similar: se permite que el componente restringido participe en la aplicación de sus propias restricciones.

En Heapjack, un secreto de autenticación privilegiado se almacena en una memoria compartida con JavaScript hostil. El modelo de seguridad confía en un token que el entorno de ejecución no confiable puede recuperar y reutilizar.

En Overpatch, el componente de aplicación de parches deriva su autoridad de las rutas proporcionadas por el agente al que debería limitar. Por tanto, un parche hostil puede influir en el cálculo utilizado para determinar dónde se permite escribir.

Se trata de problemas de confianza confusa, no de simples errores de análisis. El agente no necesita romper directamente un sandbox del kernel si puede convencer a un mecanismo externo de confianza para que ejecute la acción sensible.

En julio de 2026 se notificaron fallos comparables en los límites de confianza de agentes relacionados con Cursor, Codex, Gemini CLI y Antigravity de Google. En esos casos, un agente podía permanecer técnicamente dentro de su sandbox mientras conseguía que una herramienta de mayor confianza ejecutara un archivo creado por el propio agente.

La lección recurrente es concreta: aplicar un sandbox al proceso del agente no basta cuando las herramientas auxiliares, la memoria compartida, los gestores de configuración o los ejecutores externos aceptan entradas influidas por el agente.

Los desarrolladores deben actualizar ambos productos de Codex

Los usuarios deben instalar Codex Desktop build 26.818.21641 o posterior para solucionar Heapjack. Además, deben actualizar el Codex CLI a la versión 0.149.0 o posterior para corregir Overpatch.

Aplicar una sola de las actualizaciones no basta, porque las vulnerabilidades afectan a componentes y modos de seguridad diferentes.

Hasta que se implementen las actualizaciones, los desarrolladores deberían evitar abrir en Codex repositorios de autores no confiables. El análisis en modo de solo lectura no debe considerarse una defensa completa frente a instrucciones incluidas en el repositorio o a la ejecución controlada por el agente.

Los equipos de defensa y los usuarios afectados también pueden revisar:

• ~/.codex/config.toml en busca de configuraciones inesperadas de node_repl u otros cambios no autorizados.
• .zshrc y otros archivos de inicio del shell en busca de comandos desconocidos añadidos al final.
• Invocaciones del comando open del sistema relacionadas con Codex.
• Accesos inesperados a sockets Unix, especialmente a sockets del daemon de Docker.
• Actividad de aplicación de parches que implique /tmp, un ámbito que abarque la raíz del sistema de archivos o enlaces simbólicos que apunten fuera del proyecto.
• Aplicaciones iniciadas fuera del árbol de procesos esperado de Codex.

Heapjack puede dejar menos rastros evidentes porque no requiere una escritura de archivo convencional y puede ejecutarse sin mostrar una solicitud. Por ello, la telemetría de procesos, los registros de acceso a sockets y los registros de ejecución de comandos pueden ser más útiles que revisar únicamente el repositorio.

Es más probable que Overpatch deje un artefacto persistente en .zshrc, pero el comando malicioso puede no ejecutarse hasta la siguiente sesión de terminal.

No se han notificado explotaciones

Por el momento, no existen indicios de que los atacantes utilizaran Heapjack o Overpatch contra usuarios de Codex antes de que estuvieran disponibles las correcciones. La ausencia de ataques notificados no reduce la exposición que implica abrir un repositorio controlado por un atacante.

No se han notificado identificadores CVE, puntuaciones CVSS, rangos de versiones afectadas ni entradas en el catálogo de vulnerabilidades explotadas conocidas de CISA. Tampoco se conocen las compilaciones vulnerables exactas anteriores a las versiones corregidas.

Por tanto, el límite operativo es la versión corregida: Codex Desktop build 26.818.21641 y Codex CLI 0.149.0. Cualquier instalación anterior a esas respectivas versiones debe actualizarse, en lugar de confiar en el modo de solo lectura o de escritura en el espacio de trabajo como medida de protección.