Solicitud del usuario
El usuario encarga a Codex una tarea que implica la lectura de un proyecto o la ejecución de herramientas.
Procesando…
IA y ciberseguridad
Dos vulnerabilidades descubiertas en OpenAI Codex permitían eludir su sandbox. Overpatch autorizaba escrituras fuera del workspace, mientras que Heapjack podía conducir a la ejecución de comandos no sandboxados.
Investigadores de seguridad descubrieron dos formas de eludir las protecciones de la sandbox de OpenAI Codex. Denominadas Overpatch y Heapjack, estas técnicas podían otorgar al código ejecutado por el agente capacidades normalmente prohibidas. Según su informe, las vulnerabilidades ya han sido corregidas.
Overpatch permitía ampliar el perímetro de escritura más allá del workspace. Heapjack podía explotar un secreto presente en una memoria compartida para solicitar un componente nativo ejecutado fuera de la sandbox.
Los agentes de programación ya no se limitan a sugerir unas pocas líneas de código. Pueden leer un proyecto, modificar archivos, ejecutar comandos, lanzar pruebas, utilizar Git y manipular distintas herramientas instaladas en el equipo del desarrollador.
Esta capacidad de acción implica una restricción esencial: el agente no debe superar los permisos que se le conceden. Ese es el papel de la sandbox, que sitúa los comandos locales en un entorno restringido.
OpenAI explica que Codex se ejecuta localmente, en particular a través del CLI, de una extensión de entorno de desarrollo o de la aplicación de escritorio. Un proceso de Codex dispone de los permisos de un usuario real, mientras que la sandbox reduce las capacidades de los comandos lanzados por el agente. En modo workspace-write, las escrituras deben permanecer limitadas al workspace autorizado.
El funcionamiento esperado puede resumirse así:
El usuario encarga a Codex una tarea que implica la lectura de un proyecto o la ejecución de herramientas.
Los comandos del agente se sitúan en la sandbox y sus procesos hijos deben heredar sus restricciones.
Las operaciones permitidas se realizan en el workspace y según el modo de seguridad elegido.
Debe bloquearse un intento de escritura fuera del proyecto o de acceso a una capacidad no autorizada.
En agosto de 2026, Oren Yomtov, investigador de Accomplish, afirmó haber descubierto dos técnicas que eludían estas protecciones. La empresa indica haberlas comunicado a OpenAI el 12 de agosto de 2026 y haber publicado los detalles técnicos el 15 de septiembre. Según Accomplish, ambos problemas se corrigieron en los ocho días posteriores a su notificación.
Codex dispone de una herramienta denominada apply_patch, encargada de aplicar automáticamente modificaciones a los archivos. En el modo workspace-write, esta herramienta debe limitar sus escrituras a la carpeta del proyecto.
Según el análisis de Accomplish, la vulnerabilidad procedía de la forma en que apply_patch determinaba las carpetas a las que conceder temporalmente permiso de escritura. Cuando una ruta figuraba en un patch, la herramienta autorizaba la escritura en su carpeta principal.
Los investigadores explican que una ruta especialmente construida podía ampliar este perímetro. En su demostración, una ruta asociada a /tmp hacía subir el permiso hasta la raíz /. Codex no obtenía por ello todos los privilegios de administrador, pero podía escribir en ubicaciones que la sandbox debía prohibirle.
apply_patch recibe una modificación, verifica su destino y solo autoriza los archivos situados en el workspace.
Una ruta diseñada para influir en el cálculo de la carpeta principal extiende la zona accesible más allá del proyecto.
La posibilidad de modificar un archivo arbitrario puede tener consecuencias más importantes que una simple alteración del proyecto. Los investigadores presentan, en particular, un escenario que implica ~/.zshrc, un archivo cargado al iniciar un nuevo shell Zsh.
En su demostración, un enlace simbólico combinado con el comportamiento de apply_patch permitía escribir en este archivo. Un comando inyectado podía entonces ejecutarse posteriormente, cuando el usuario abría un terminal, en su contexto normal y fuera de la sandbox de Codex.
El riesgo no se limita a la modificación de un archivo externo al proyecto. Si ese archivo es posteriormente interpretado por un shell u otra aplicación, la escritura puede convertirse en un medio para ejecutar más tarde un comando fuera de la sandbox.
La segunda vulnerabilidad se basaba en un mecanismo diferente. Afectaba a un componente JavaScript instalado con Codex Desktop y configurado mediante ~/.codex/config.toml.
Según Accomplish, este componente utilizaba un proceso Node.js que contenía dos contextos JavaScript V8: uno para código considerado fiable y otro para código menos fiable ejecutado en el marco del agente. Un token aleatorio debía permitir al componente nativo distinguir las solicitudes procedentes del contexto fiable.
El problema residía en que ambos contextos V8 compartían el mismo heap de memoria. El secreto que establecía la frontera de confianza se almacenaba así en un espacio de memoria accesible desde el proceso que también ejecutaba el código no fiable.
Los investigadores indican haber utilizado v8.getHeapSnapshot() para producir una instantánea del heap V8. A continuación, el código podía buscar cadenas similares a UUID y probar los valores encontrados hasta identificar el token esperado por el componente privilegiado.
Heapjack no eliminaba necesariamente las restricciones del proceso Node.js. El código permanecía en la sandbox, pero podía convencer a un proceso Rust situado fuera de ella para que realizara una acción en su lugar.
El componente nativo recibía solicitudes en formato JSON y verificaba el token antes de aceptarlas. Una vez descubierto este secreto, el contexto no fiable podía forjar sus propias solicitudes. La frontera de seguridad no se destruía directamente: se eludía mediante un componente privilegiado.
read-onlyAccomplish indica haber demostrado Heapjack mientras Codex funcionaba en modo read-only, que se supone que impide al agente escribir en la máquina. Los investigadores afirman haber logrado una ejecución de comandos no sandboxada sin solicitar autorización al usuario.
El componente nativo podía, en particular, llamar al comando macOS open. La aplicación así iniciada se arrancaba después a través de launchd, fuera del árbol de procesos sometido a la sandbox de Codex.
Un entorno no es realmente de solo lectura si una interfaz que sigue siendo accesible puede escribir o ejecutar comandos en su lugar.
Los investigadores evocan el escenario de un desarrollador que utiliza un agente para examinar un repositorio Git controlado por un tercero. Incluso sin solicitar explícitamente la ejecución de un programa, el repositorio puede contener archivos o instrucciones diseñados para influir en el comportamiento del agente.
Con una vulnerabilidad que permite atravesar la sandbox, un repositorio malicioso se convierte en un vector de ataque potencial. Accomplish afirma que, en el escenario de Heapjack probado, un repositorio especialmente preparado podía conducir a una ejecución no sandboxada, incluso en modo read-only.
Este riesgo acerca la seguridad de los agentes de desarrollo a los problemas de la cadena de suministro de software: el contenido de un repositorio desconocido debe considerarse no fiable desde el momento en que un agente puede interpretarlo y orquestar herramientas a partir de él.
Estas vulnerabilidades no describen un modelo de inteligencia artificial que decide voluntariamente eludir las protecciones de su sistema. Afectan a la infraestructura de software que rodea al agente: el mecanismo de aplicación de patches, la asignación de permisos, un componente Node.js, un proceso Rust privilegiado y la separación entre los componentes fiables y no fiables.
Codex se apoya en estos componentes para ejecutar las acciones propuestas por el modelo. Por tanto, una debilidad en uno de ellos puede otorgar al agente más capacidades de las previstas, del mismo modo que una vulnerabilidad del navegador puede permitir a una página web superar los límites que normalmente se le imponen.
Un agente de desarrollo puede orquestar Git, npm, Python, Node.js, Docker, SSH, un shell, un compilador, scripts del proyecto o herramientas MCP. Esta versatilidad aumenta mecánicamente su superficie de ataque.
Por tanto, una sandbox no se reduce a tres permisos de lectura, escritura y ejecución. Incluso limitado a una carpeta, un agente puede llegar a alcanzar un socket Unix, un daemon Docker, un gestor de paquetes, un servidor MCP, una herramienta del sistema o una aplicación intermedia con privilegios adicionales.
Cada puente entre la sandbox y la máquina anfitriona debe aplicar la misma política de seguridad. Heapjack muestra que un proceso correctamente restringido puede seguir siendo peligroso cuando se comunica con un componente que no lo está.
Overpatch y Heapjack se basaban en mecanismos distintos, pero Accomplish destaca un punto común: una parte del mecanismo de control permanecía demasiado cerca del entorno no fiable.
apply_patch recibía las rutas y las utilizaba para determinar los permisos. Por tanto, una ruta especialmente construida podía ampliar esos permisos.
El contexto fiable poseía un token, pero el contexto no fiable compartía el mismo heap y podía intentar recuperar ese valor.
Sí, según el informe de Accomplish. La empresa indica haber comunicado ambos problemas a OpenAI el 12 de agosto de 2026 y precisa que se corrigieron en los ocho días siguientes.
| Componente | Vulnerabilidad | Versión corregida indicada |
|---|---|---|
| Codex CLI | Overpatch | 0.149.0 o posterior |
| Codex Desktop | Heapjack | Build 26.818.21641 o posterior |
Estos números son los comunicados por Accomplish en su análisis. Para el CLI, la versión instalada puede verificarse con el siguiente comando:
codex --versionLos usuarios tienen interés en mantener actualizados tanto el CLI como la aplicación de escritorio. Los agentes de desarrollo constituyen ahora una capa de software sensible, cuyos mecanismos de aislamiento deben tratarse como componentes de seguridad críticos.
La actualización es la primera medida que debe aplicarse, pero no basta para reducir todos los riesgos relacionados con una futura vulnerabilidad.
Este caso no afecta únicamente a Codex. Los asistentes de programación se están convirtiendo progresivamente en agentes capaces de realizar por sí mismos operaciones antes reservadas al desarrollador. Su seguridad se parece ahora más a la de un sistema de ejecución que a la de un simple chatbot.
El modelo es solo una capa de la arquitectura. A su alrededor se encuentran el agente, sus herramientas, la sandbox, el sistema operativo, los secretos y la infraestructura. Una debilidad en cualquiera de estas capas puede modificar el nivel de seguridad real del conjunto.
Para el usuario, una configuración de solo lectura significa naturalmente que el agente puede consultar los datos sin modificar nada. Para que esta promesa sea efectiva, también deben bloquearse todas las vías de modificación indirecta.
Una restricción aplicada al sistema de archivos no basta si el agente puede enviar una solicitud a un proceso privilegiado capaz de realizar la acción en su lugar. Esa es la diferencia entre un permiso local y una verdadera frontera de seguridad.
Overpatch y Heapjack ilustran la creciente complejidad de la seguridad de los agentes de programación. En el primer caso, una herramienta destinada a modificar código podía ampliar su perímetro de escritura. En el segundo, un secreto que separaba código fiable y no fiable podía recuperarse en una memoria compartida y utilizarse después para comunicarse con un componente privilegiado.
Las vulnerabilidades han sido corregidas según Accomplish, pero sus enseñanzas van más allá de este incidente. A medida que los agentes manipulan archivos, terminales, contenedores, API y herramientas externas, la sandbox se convierte en una de las protecciones esenciales del equipo del desarrollador.
Por tanto, la cuestión ya no se refiere únicamente a lo que la IA es capaz de generar, sino también a lo que el agente encargado de ejecutarlo puede alcanzar realmente en la máquina.
El análisis de las vulnerabilidades se basa en el informe técnico publicado el 15 de septiembre de 2026 por Oren Yomtov, investigador principal de seguridad en Accomplish. La empresa indica haber comunicado Overpatch y Heapjack a OpenAI el 12 de agosto de 2026 y precisa que ambos problemas se corrigieron en los ocho días siguientes.
La presentación del funcionamiento general de la sandbox y del modelo de permisos de Codex también se apoya en la documentación técnica de OpenAI fechada el 13 de mayo de 2026, tal como se describe en el brief editorial.
IA Y CIBERSEGURIDAD
La arquitectura, los permisos, el aislamiento y la validación humana convierten la automatización en una capacidad útil sin exponer tus sistemas de producción.
Introduce al menos 2 caracteres para iniciar la búsqueda.