Dos fallos en OpenAI Codex permitían escapar del sandbox: ya están corregidos

Investigadores de seguridad han revelado dos vulnerabilidades diferentes que permitían superar las protecciones del sandbox de OpenAI Codex. Una afectaba al mecanismo utilizado por Codex CLI para aplicar cambios en archivos y la otra podía llegar a ejecutar acciones fuera del entorno aislado incluso cuando Codex estaba configurado en su restrictivo modo de solo lectura.

Las dos vulnerabilidades ya están corregidas. Según Accomplish, firma responsable del descubrimiento, los problemas se comunicaron a OpenAI el 12 de agosto de 2026 y fueron solucionados en un plazo de ocho días.

Para quedar protegido frente a los dos fallos divulgados, los investigadores recomiendan utilizar como mínimo Codex Desktop 26.818.21641 y Codex CLI 0.149.0, o cualquier versión posterior.

No se han publicado indicios de explotación masiva de estas vulnerabilidades. La investigación demuestra, sin embargo, por qué la frontera de seguridad de los agentes de programación resulta especialmente importante cuando se utilizan para analizar repositorios o código procedente de terceros.

Qué es el sandbox de Codex y por qué importa

Codex puede ejecutar comandos, inspeccionar proyectos y modificar archivos para completar tareas de programación. Para reducir el riesgo de que esas capacidades afecten al resto del ordenador, OpenAI utiliza diferentes niveles de aislamiento y permisos.

Uno de ellos es workspace-write, donde el agente puede trabajar dentro del directorio autorizado del proyecto pero no debería escribir libremente en otras ubicaciones del sistema.

También existe un modo read-only, pensado para limitar todavía más las capacidades del agente. En ese escenario, Codex debería poder analizar el proyecto sin realizar modificaciones persistentes en el sistema de archivos.

Las vulnerabilidades descubiertas por Accomplish resultan relevantes precisamente porque permitían romper esas expectativas de aislamiento desde dos componentes diferentes.

El primer fallo estaba relacionado con apply_patch

El primer problema recibió el nombre de Overpatch y afectaba al Codex CLI de código abierto.

Codex dispone de una herramienta interna denominada apply_patch que utiliza para aplicar modificaciones a los archivos de un proyecto. Bajo una configuración normal de workspace-write, esas modificaciones deberían quedar limitadas a las rutas para las que el agente tiene permisos.

Los investigadores descubrieron que la lógica utilizada por esta herramienta para calcular qué ubicaciones podían escribirse podía manipularse mediante la propia información proporcionada al sistema de parcheado.

Como consecuencia, un parche preparado de forma específica podía ampliar indebidamente los permisos disponibles para la operación y permitir escrituras fuera del espacio de trabajo autorizado.

El problema era especialmente significativo porque el escape podía producirse sin que apareciera una solicitud adicional de aprobación.

Un parche podía superar el límite del directorio de trabajo

En condiciones normales, un comando ejecutado por Codex en workspace-write debería ser rechazado si intenta modificar un archivo situado fuera del proyecto.

Con Overpatch, la operación gestionada por apply_patch podía terminar escribiendo en ubicaciones que el sandbox pretendía mantener fuera de alcance.

Eso abre diferentes escenarios de riesgo. Un repositorio malicioso podría intentar provocar cambios en archivos que posteriormente fueran utilizados por herramientas o procesos ejecutados fuera del sandbox.

No reproducimos aquí la secuencia utilizada por los investigadores para conseguirlo. Lo relevante para los usuarios es que la vulnerabilidad estaba en la forma en que el propio sistema de edición calculaba temporalmente sus permisos de escritura y que esa lógica ya fue corregida.

Overpatch está corregido en Codex CLI 0.149.0

Accomplish sitúa la corrección de Overpatch en Codex CLI 0.149.0.

Los usuarios que todavía ejecuten una versión anterior deberían actualizar a la 0.149.0 o posterior.

OpenAI continúa distribuyendo versiones posteriores de Codex, por lo que no es necesario instalar exactamente esa compilación si ya existe una más reciente disponible para el sistema.

La regla práctica es sencilla: no utilizar una versión de Codex CLI anterior a 0.149.0 si se quiere contar con la corrección descrita por los investigadores.

El segundo fallo podía escapar incluso del modo read-only

La segunda vulnerabilidad, denominada Heapjack, es más llamativa porque los investigadores lograron superar el aislamiento desde el modo read-only.

El problema estaba relacionado con una herramienta JavaScript instalada por Codex Desktop y con la separación entre el código considerado confiable y el código ejecutado dentro del sandbox.

Según la investigación, ambos contextos estaban aislados lógicamente, pero compartían parte del mismo entorno de ejecución en memoria.

El componente privilegiado utilizaba un valor secreto para distinguir las peticiones autorizadas de las que procedían del contexto no confiable. El fallo consistía en que ese secreto podía quedar accesible desde el mismo espacio de memoria en el que se ejecutaba el código que debía mantenerse aislado.

El sandbox funcionaba, pero el componente exterior podía ser engañado

Heapjack no consistía simplemente en desactivar el sandbox.

El código JavaScript continuaba ejecutándose dentro del entorno restringido, pero los investigadores encontraron una forma de hacer que un componente nativo situado fuera de esa frontera aceptase solicitudes como si procedieran del contexto de confianza.

Ese componente tenía capacidades que el JavaScript aislado no debía poseer directamente.

El resultado demostrado por Accomplish fue la posibilidad de desencadenar ejecución de acciones fuera del sandbox, incluso partiendo de una sesión configurada como read-only y sin que Codex mostrara una aprobación adicional al usuario.

Un repositorio no confiable podía convertirse en el punto de entrada

El escenario resulta especialmente relevante para desarrolladores porque una de las funciones habituales de los agentes de código es analizar repositorios creados por otras personas.

Según los investigadores, Heapjack permitía construir un repositorio preparado para activar la cadena de explotación cuando Codex interactuaba con determinado contenido del proyecto.

Esto significa que el usuario no tenía necesariamente que ejecutar manualmente un binario desconocido fuera del agente. El riesgo estaba precisamente en confiar en el sandbox para inspeccionar código potencialmente hostil.

Accomplish demostró que el comportamiento podía terminar alcanzando el entorno nativo del sistema más allá de las restricciones que el usuario esperaba de read-only.

Heapjack está corregido en Codex Desktop 26.818.21641

Los investigadores indican que OpenAI solucionó Heapjack a partir de Codex Desktop build 26.818.21641.

Por tanto, cualquier instalación anterior debería actualizarse.

También aquí es preferible instalar la versión estable más reciente disponible en lugar de buscar específicamente esa compilación mínima. Las versiones posteriores incluyen la misma corrección y otros cambios acumulados.

Las dos vulnerabilidades tenían un problema conceptual parecido

Aunque Overpatch y Heapjack afectaban a componentes diferentes, los investigadores encuentran una similitud en la raíz del problema.

En ambos casos, una parte de la lógica encargada de decidir qué estaba permitido quedaba demasiado expuesta a información procedente del contexto que debía restringir.

En Overpatch, la propia operación de parcheado influía sobre los permisos que posteriormente utilizaba para escribir.

En Heapjack, la separación entre código privilegiado y no privilegiado dependía de información que coexistía dentro de un entorno de memoria compartido.

El resultado en ambos casos era que el control de seguridad podía ser manipulado desde el lado que se suponía que debía permanecer limitado.

Que un agente funcione en sandbox no hace seguro cualquier repositorio

El descubrimiento también pone de relieve una diferencia importante entre utilizar una herramienta de programación convencional y un agente con capacidad de ejecutar acciones.

Un repositorio puede contener algo más que código que posteriormente se compila manualmente. Puede incluir instrucciones para agentes, configuraciones del entorno de desarrollo, tareas automatizadas, scripts, dependencias y otros elementos que una herramienta inteligente podría decidir inspeccionar o utilizar durante su trabajo.

Por eso el sandbox se convierte en una frontera de seguridad crítica: el modelo puede encontrarse con contenido controlado por un atacante incluso cuando el propio usuario no considera que esté «ejecutando» ese contenido de la forma tradicional.

No hay que desactivar el sandbox como solución

Estos fallos no significan que la solución sea ejecutar Codex permanentemente con acceso completo.

Eso eliminaría precisamente la capa diseñada para reducir las consecuencias de un comportamiento inesperado, una dependencia comprometida o instrucciones maliciosas presentes en un repositorio.

La medida correcta es actualizar a las versiones corregidas y seguir utilizando el nivel de permisos mínimo que necesite cada tarea.

Para proyectos desconocidos o descargados de Internet, read-only continúa siendo una opción más restrictiva que conceder permisos completos, siempre que la versión de Codex utilizada incluya las correcciones de seguridad correspondientes.

Cómo comprobar la versión de Codex CLI

Los usuarios de la herramienta de terminal pueden consultar la versión instalada mediante:

Si aparece una versión anterior a 0.149.0, debe actualizarse antes de seguir utilizando Codex con repositorios no confiables.

Si el resultado muestra 0.149.0 o una versión superior, la corrección de Overpatch descrita por Accomplish ya está incluida.

Qué deben hacer los usuarios de Codex Desktop

En la aplicación de escritorio, comprueba la versión instalada desde la información de la aplicación y actualiza si utilizas una compilación anterior a 26.818.21641.

La propia documentación actual de OpenAI ya hace referencia a versiones posteriores de la rama 26.818 para Codex Desktop, por lo que los usuarios con actualizaciones recientes deberían encontrarse por encima de la compilación mínima identificada por los investigadores.

Después de actualizar, conviene cerrar y volver a iniciar Codex para asegurarse de que los componentes locales que acompañan a la aplicación también se han renovado.

Qué hacer si se utilizó una versión vulnerable con repositorios no confiables

La publicación de Accomplish demuestra que las vulnerabilidades podían utilizarse para superar la frontera local de seguridad, pero no afirma que todos los usuarios de versiones vulnerables hayan sido comprometidos.

Si Codex se utilizó únicamente con proyectos propios y de confianza, la existencia del fallo no significa por sí misma que haya ocurrido un ataque.

El escenario merece más atención si una versión afectada se empleó para analizar repositorios, pull requests o proyectos procedentes de fuentes desconocidas o poco fiables.

En esos casos, además de actualizar, puede ser razonable revisar cambios inesperados en el entorno de desarrollo, configuraciones locales, procesos ejecutados y credenciales potencialmente accesibles desde la máquina.

Los fallos fueron corregidos antes de su publicación detallada

Accomplish comunicó ambos problemas de forma privada a OpenAI el 12 de agosto y afirma que la compañía completó las correcciones dentro de los ocho días siguientes.

La investigación técnica se publicó posteriormente, el 15 de septiembre, cuando ya existían versiones corregidas.

La divulgación coordinada reduce el riesgo de que los detalles técnicos se hagan públicos antes de que los usuarios dispongan de una actualización.

La prioridad es actualizar Codex CLI y Desktop

Para los usuarios de Codex, las dos referencias de seguridad son claras: Codex CLI 0.149.0 o posterior para corregir Overpatch y Codex Desktop 26.818.21641 o posterior para Heapjack.

Los dos problemas permitían superar protecciones que estaban precisamente diseñadas para contener código o acciones no confiables. Heapjack resultaba especialmente relevante porque funcionaba incluso desde el modo read-only, mientras Overpatch podía permitir escrituras fuera del workspace a través de la lógica de apply_patch.

Ambos fallos están corregidos. El principal riesgo actual se concentra, por tanto, en instalaciones que sigan utilizando versiones antiguas de Codex.