En los sistemas de desarrollo modernos, los asistentes de programación en la nube operan con credenciales y permisos que facilitan tareas pero también crean vectores de ataque. OpenAI Codex, integrado en varias superficies como la web de ChatGPT, la CLI de Codex, el SDK y la extensión del IDE, procesaba nombres de rama sin una validación adecuada. Esa falta de filtrado permitió que un atacante inyectara comandos en el entorno de inicialización del contenedor y recuperara el token OAuth de GitHub embebido en la URL remota del repositorio.
Lo que complicó la detección fue una técnica de camuflaje basada en caracteres Unicode: el uso de 94 espacios ideográficos (U+3000) para esconder la carga maliciosa en el selector de ramas de la interfaz. Al mismo tiempo, el intérprete de Bash ignoraba esos caracteres durante la ejecución. El resultado fue una exfiltración silenciosa de credenciales hacia un servidor externo controlado por el atacante, y la posibilidad de automatizar el ataque a través de la API de GitHub cuando el adversario tenía permisos de escritura.
Cómo se produjo la inyección y qué información se filtró
El flujo de inicio de una tarea de Codex incluía clonar el repositorio usando una URL remota con el token OAuth incorporado. Durante esa fase, el sistema ejecutaba comandos de shell que recibían el nombre de rama directamente sin comillas ni escapes apropiados. La presencia de metacaracteres de Bash como ;, && o la ejecución en subshell con `…` permitía terminar la instrucción prevista y añadir una segunda orden que leyera la URL remota y la enviara fuera del entorno.
Además, la técnica ${IFS} (el Internal Field Separator) se aprovechó para sortear las restricciones de GitHub sobre espacios en nombres de rama, transformando secuencias válidas en espacios al evaluarse por Bash.
Modos de explotación y alcance del impacto
El vector se presentó en varias formas: creación manual de ramas maliciosas, automatización por API mediante el endpoint de referencias de GitHub y explotación indirecta a través de menciones a @codex en comentarios de pull request que disparaban contenedores de revisión.
En algunos casos la técnica no solo robó tokens OAuth de usuarios sino también Installation Access tokens vinculados a aplicaciones de GitHub, lo que podía otorgar permisos organizacionales más amplios. Además, los investigadores localizaron credenciales almacenadas en claro en ~/.codex/auth.json, lo que permitió replicar ataques desde la API de backend cuando la CLI no usaba el keyring del sistema.
Obfuscación visual con Unicode
Una contribución clave a la sigilosidad del ataque fue el uso del espacio ideográfico (U+3000). Al añadir 94 de esos caracteres tras el nombre visible de la rama y colocar luego || true o un separador de comandos, el portal mostraba únicamente la parte visible («main» u otro nombre), mientras que el resto de la carga quedaba oculto fuera del área visible. Esta técnica convertía una trampa persistente: un administrador podía incluso establecer esa rama como branch por defecto, haciendo que cada interacción con Codex que usase la rama activase la exfiltración.
Confirmación y pruebas prácticas
Los investigadores validaron la cadena de ataque configurando un servidor HTTP de prueba y observando las solicitudes con los tokens exfiltrados en los registros de acceso. En el proceso de divulgación responsable, BeyondTrust Phantom Labs notificó a OpenAI y la coordinación llevó a varias correcciones. Entre los hitos informados figuran acciones desplegadas desde diciembre de 2026 y, según el informe público, la clasificación y permiso para divulgación se produjo el 05 de febrero de 2026, con la publicación pública del hallazgo el 30 de marzo de 2026.
Lecciones y recomendaciones prácticas
La lección principal es que los agentes de codificación en la nube requieren un modelo de permisos y validaciones distinto al software local. Las medidas imprescindibles incluyen auditar y minimizar el alcance de las credenciales, aplicar principio de menor privilegio a las integraciones, rotar tokens con regularidad y revisar los registros de API para actividad inusual. Técnicas de mitigación específicas son: validar y escapar nombres de rama antes de pasarlos al shell, limitar la exposición de tokens dentro de los contenedores de inicialización y detectar patrones de nombres de rama con espacios Unicode sospechosos. Por último, la seguridad debe contemplar tanto la interfaz de usuario como los canales backend y los archivos locales donde se puedan almacenar credenciales en texto sin formato.
