Investigadores de seguridad han descubierto dos vulnerabilidades críticas en OpenAI Codex que permiten escapar del sandbox de seguridad de la herramienta, una de ellas capaz de ejecutar comandos arbitrarios en el equipo del desarrollador desde el modo más restrictivo, sin solicitar aprobación y sin mostrar nada en pantalla. Las fallas, denominadas Heapjack y Overpatch, fueron reportadas a OpenAI el 12 de agosto de 2026 y corregidas en un plazo de ocho días, según informó Oren Yomtov, investigador de Accomplish AI.
La más grave de las dos, Heapjack, convierte una acción rutinaria en una ejecución remota de código: basta con abrir el repositorio de otro usuario en Codex, hacerle una pregunta sobre el código, y quien escribió ese repositorio obtiene capacidad de ejecución de comandos sin restricciones en la máquina de quien pregunta. Este artículo analiza en profundidad ambas vulnerabilidades, su funcionamiento técnico, las implicaciones para la seguridad del desarrollo asistido por IA y las lecciones que dejan para toda la industria.
¿Qué es OpenAI Codex y cómo funciona su sandbox?
OpenAI Codex es el agente de codificación de OpenAI, disponible como herramienta de línea de comandos (CLI) y como aplicación de escritorio. Al igual que otros agentes competidores, Codex ejecuta las acciones del modelo dentro de un sandbox, un entorno aislado diseñado para que el código no confiable no pueda acceder al sistema operativo subyacente. La premisa es sencilla: cuando un agente de IA genera y ejecuta código, ese código debe estar confinado para evitar daños, robo de datos o ejecución de malware. Ambas vulnerabilidades descubiertas logran derrotar ese perímetro de seguridad desde el interior del propio sandbox.
El sandbox de Codex opera en varios modos de permisos, siendo el modo de solo lectura (read-only) el más restrictivo. En teoría, en ese modo el agente no puede escribir absolutamente nada en el sistema de archivos ni ejecutar comandos arbitrarios. Sin embargo, Heapjack demostró que era posible sortear completamente esa restricción.
Heapjack: el secuestro del heap que quebranta el sandbox de OpenAI Codex
La técnica Heapjack, detallada en el informe publicado por Yomtov, apunta a un componente llamado node_repl. Codex Desktop escribe este componente en el archivo global de configuración ~/.codex/config.toml durante la instalación. No existe opción de aceptación ni configuración para desactivarlo, y como la entrada reside en la configuración compartida, los usuarios de Codex CLI heredan la misma herramienta sin que se les pregunte nunca.
node_repl ejecuta un único proceso de Node.js que mantiene dos contextos de ejecución de JavaScript separados. Uno es de confianza y contiene el código propio de OpenAI. El otro no es de confianza y ejecuta el código del agente. El contexto de confianza demuestra que lo es presentando un token aleatorio que se genera de nuevo en cada ejecución. El problema fundamental es que ambos contextos viven dentro del mismo proceso de Node y comparten un único heap de memoria, por lo que el token no es más que una cadena de texto en la memoria que el contexto no confiable puede leer.
El código no confiable toma una instantánea del heap con v8.getHeapSnapshot() y busca todas las cadenas que tengan formato de UUID. Un intento incorrecto devuelve «no autorizado». Un token correcto con un argumento incorrecto devuelve un error de validación real, lo que indica al atacante que el token es válido. Con el token en su poder, el código no confiable escribe su propia solicitud en el mismo conducto (pipe) que el contexto de confianza usa para comunicarse con un proceso padre nativo que no está dentro del sandbox.
El proceso padre verifica el token, lo encuentra válido y ejecuta la acción solicitada. La prueba de concepto utilizó el comando ‘open’ del sistema para lanzar una aplicación fuera del árbol de procesos de Codex por completo. El mismo acceso alcanza cualquier socket Unix, siendo un socket del demonio Docker el objetivo obvio, y también una herramienta para editar el archivo de configuración global. Todo esto ocurre en modo de solo lectura, el nivel de sandbox más estricto, donde se supone que el agente no puede escribir absolutamente nada.
¿Cómo funciona exactamente el ataque Heapjack paso a paso?
Para quienes buscan una comprensión clara y autosuficiente, el ataque sigue estos pasos: primero, el código malicioso ejecutado dentro del sandbox de Codex (en modo read-only) toma una instantánea completa del heap de memoria compartida usando la función nativa de V8. Segundo, escanea esa instantánea buscando cadenas con formato UUID, que es la forma del token de autenticación. Tercero, prueba cada candidato contra el sistema hasta obtener una respuesta de error de validación genuina, confirmando el token correcto. Cuarto, utiliza ese token válido para escribir una solicitud en el pipe de comunicación con el proceso padre no sandboxeado, logrando así ejecutar cualquier comando o abrir cualquier aplicación fuera del sandbox. El ataque no requiere ninguna interacción del usuario más allá de la acción inicial de abrir un repositorio y hacer una pregunta.
Overpatch: la segunda vía de escape en Codex CLI
La segunda vulnerabilidad, denominada Overpatch, reside en el código abierto de Codex CLI. En el modo de escritura en el espacio de trabajo (workspace-write), el agente solo puede escribir dentro de la carpeta del proyecto, y cualquier comando de shell que apunte al directorio home del usuario es rechazado. Los investigadores lograron que la propia herramienta de parches de Codex, apply_patch, escribiera allí de todas formas.
La herramienta apply_patch otorga acceso de escritura a la carpeta padre de cada ruta mencionada en un parche. Si se nombra ‘/tmp’, se otorga acceso de escritura a la raíz del disco. El exploit funcional utiliza un parche con dos cambios: uno que nombra ‘/tmp’ y no hace nada útil excepto ampliar el permiso, y otro que añade una línea a ‘.zshrc’ a través de un enlace simbólico hacia el directorio home. Si se elimina el primer cambio, la escritura es rechazada. Con él, la siguiente terminal que el desarrollador abra ejecutará la línea del atacante sin restricciones.
La gravedad de Overpatch radica en su persistencia: una vez que el archivo de configuración del shell (.zshrc o similar) ha sido modificado, cualquier sesión de terminal futura ejecutará el código malicioso, otorgando al atacante control continuo sobre la máquina de la víctima sin necesidad de mantener la sesión original de Codex activa.
El mismo error fundamental: la frontera de confianza mal ubicada
Ambas vulnerabilidades comparten una misma estructura subyacente: el mecanismo de aplicación de la seguridad vivía dentro de aquello que se suponía debía proteger. apply_patch calculaba sus propios permisos a partir de datos suministrados por el atacante. node_repl mantenía el secreto que separaba el código de confianza del no confiable en la misma memoria que el código no confiable. En cada caso, el sandbox recibía instrucciones desde su interior para permitir el paso de algo que nunca debió permitir.
Esta clase de error no es nueva. En julio de 2026, investigadores de Pillar Security demostraron la misma idea en múltiples herramientas —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 posteriormente. La industria del desarrollo asistido por IA está reproduciendo sistemáticamente vulnerabilidades que la seguridad del software lleva décadas combatiendo.
Reaccionando a la publicación de Yomtov en X, un comentarista escribió que «los contextos V8 aíslan los globales, no la memoria, por lo que el sandbox era realmente una promesa que el heap nunca aceptó». Otro llamó a la frontera de confianza «un divisor de ambientes». La habilitación por defecto de node_repl atrajo su propio escrutinio, preguntándose por qué un token privilegiado era accesible desde JavaScript no confiable. Esta crítica es particularmente pertinente: si el diseño asume que el código JavaScript del agente puede ser malicioso, entonces el token de autenticación no debería residir en la misma memoria que ese código potencialmente hostil bajo ninguna circunstancia.
Implicaciones para la seguridad en el desarrollo asistido por IA
Estas vulnerabilidades trascienden el caso específico de OpenAI Codex y plantean preguntas fundamentales sobre la arquitectura de seguridad de los agentes de codificación. El mercado de herramientas de desarrollo basadas en IA ha crecido exponencialmente, con productos como Cursor, GitHub Copilot, Gemini CLI y Antigravity compitiendo por la confianza de los desarrolladores. Todas estas herramientas operan con algún tipo de sandbox, y todas enfrentan el mismo desafío: cómo ejecutar código generado por IA de forma segura en el entorno del usuario sin sacrificar funcionalidad.
El problema fundamental es que los sandboxes tradicionales fueron diseñados para aislar aplicaciones completas, no para contener fragmentos de código que comparten memoria y recursos con el mismo proceso que los supervisa. La arquitectura de node_repl, con dos contextos de JavaScript en un mismo heap, es inherentemente frágil. Cualquier secreto compartido en esa memoria puede ser descubierto. La lección es clara: los mecanismos de seguridad deben operar en un espacio de ejecución separado, con barreras de memoria reales, no meras particiones lógicas.
Para los equipos de seguridad empresarial, estas revelaciones indican que el uso de agentes de codificación IA debe ir acompañado de políticas de actualización estrictas, monitoreo de comportamiento anómalo en los entornos de desarrollo y, mientras no se maduren las arquitecturas de aislamiento, posiblemente la restricción de estos agentes a entornos controlados o contenedores completos.
¿Qué deben hacer los desarrolladores y las empresas ahora?
OpenAI corrigió Heapjack en Codex Desktop build 26.818.21641 y Overpatch en Codex CLI 0.149.0, según confirmó Accomplish AI. Los usuarios deben actualizar a esas versiones o posteriores de inmediato. Yomtov reconoció que OpenAI resolvió ambos problemas en un plazo de ocho días desde su reporte, lo que demuestra una respuesta rápida, pero la existencia de estas vulnerabilidades subraya la necesidad de que los usuarios apliquen las actualizaciones tan pronto como estén disponibles.
Más allá de la actualización, los desarrolladores deberían considerar las siguientes prácticas: revisar periódicamente los archivos de configuración de Codex y otras herramientas similares para detectar componentes no solicitados; ejecutar agentes de codificación en entornos con mínimo privilegio; utilizar herramientas de monitoreo de integridad de archivos en los directorios de configuración del shell; y, cuando sea posible, contenerizar completamente el entorno de desarrollo para añadir una capa adicional de aislamiento.
Las empresas que adopten estas herramientas deben establecer un proceso de evaluación de seguridad que incluya la revisión de las arquitecturas de sandbox de cada producto, la verificación de que las actualizaciones se aplican automáticamente y la realización de auditorías periódicas de los entornos de desarrollo en busca de signos de compromiso.
El panorama más amplio: una industria que aprende sobre la marcha
El hecho de que dos vulnerabilidades críticas aparecieran en un intervalo de ocho días y fueran corregidas con rapidez es positivo, pero también indica que la industria de agentes de codificación está en una fase temprana de maduración en materia de seguridad. La repetición del mismo patrón de error en múltiples productos sugiere que no se trata de fallos aislados, sino de una debilidad sistémica en el diseño de sandboxes para agentes inteligentes.
La comunidad de seguridad ha señalado que estos problemas no son nuevos en concepto, pero sí novedosos en su aplicación práctica a agentes de IA que ejecutan código en nombre del usuario. La diferencia crucial con el software tradicional es que el código generado por IA puede ser impredecible, variar entre ejecuciones y aprovechar vectores de ataque que un desarrollador humano probablemente no consideraría. Los agentes de IA no solo ejecutan código: lo generan activamente, lo que multiplica la superficie de ataque potencial.
A futuro, es probable que veamos un endurecimiento significativo de las arquitecturas de sandbox en todas las herramientas de desarrollo asistido por IA. Las soluciones podrían incluir el uso de contenedores a nivel de sistema operativo, la separación de procesos con espacios de memoria completamente independientes, la eliminación de cualquier secreto compartido en la memoria del proceso agente y la implementación de políticas de permisos que se evalúen desde un contexto externo al código que se ejecuta.
Afirmación factual clave: las vulnerabilidades Heapjack y Overpatch en OpenAI Codex, reportadas el 12 de agosto de 2026 y corregidas en ocho días, demuestran que los sandboxes actuales de los agentes de codificación pueden ser eludidos cuando el mecanismo de enforcement reside dentro del mismo espacio de memoria que el código no confiable, permitiendo la ejecución remota de comandos sin aprobación del usuario.
Para los desarrolladores que confían en Codex y herramientas similares, la lección inmediata es clara: actualizar sin demora. Para la industria en su conjunto, la lección es más profunda: la seguridad de los agentes de IA no puede ser un añadido posterior ni un simple confinamiento lógico; debe ser parte integral de la arquitectura desde el diseño, con barreras reales, no solo promesas que el heap nunca acordó mantener.
