La sandbox de Codex falló: un agente de IA extrajo tokens de GitHub desde la memoria del Runner vía /tmp

Un mensaje de error habitual en GitHub pudo haber sido el primer paso para la publicación de una actualización maliciosa de OpenAI Codex. Los especialistas de Depi demostraron una cadena de ataques que comienza con la suplantación de instrucciones para la IA, atraviesa la sandbox de seguridad y conduce a la toma de control de la publicación del paquete oficial de npm @openai/codex. El paquete se descarga millones de veces al mes.

El punto de entrada fue el workflow de GitHub Actions Issue Labeler, que analizaba automáticamente las nuevas incidencias en el repositorio openai/codex. El título y el contenido de la incidencia se enviaban directamente en la solicitud a Codex, y la configuración allow-users: "*" permitía la ejecución a cualquier usuario. Al atacante le bastaba crear una incidencia con un texto especialmente preparado para intentar imponer al agente sus propias órdenes.

Durante las pruebas, el equipo hizo que Codex ejecutara comandos de shell, ocultando el script malicioso mediante compresión y codificación. El siguiente obstáculo fue la sandbox de Linux, que restringe el acceso a la red, los procesos y el sistema de archivos. Sin embargo, mediante canales de depuración con nombre de CoreCLR en el directorio /tmp se logró acceder a la memoria de los procesos de GitHub Actions Runner, sortear las prohibiciones de las conexiones de red habituales.

De la memoria del proceso Runner.Worker se consiguió extraer el GITHUB_TOKEN y el ACTIONS_RUNTIME_TOKEN. Los secretos no estaban en el entorno del propio agente, pero seguían almacenados en el proceso controlador. Los privilegios obtenidos permitieron preparar una caché envenenada de GitHub Actions para un proceso de compilación más privilegiado rust-ci.yml. Al restaurar la caché, un archivo Python malicioso podría llegar al directorio de trabajo y ejecutarse durante las pruebas.

La etapa final consistía en crear un lanzamiento falso de Codex. La eliminación de dicho lanzamiento por parte del responsable debía activar el workflow preparado y abrir el acceso al token de OpenID Connect. A través del mecanismo Trusted Publishing, el atacante potencialmente obtenía la posibilidad de publicar una versión infectada de @openai/codex sin un token permanente de npm. Un mecanismo similar de publicación de confianza ya había sido objetivo de ataques contra npm.

Depi demostró la ejecución de comandos y la extracción de tokens en su propio entorno de pruebas, pero no confirmó la publicación de una versión maliciosa de Codex. Existe además una limitación técnica: la configuración pública de OpenAI usaba el modo sandbox: read-only, mientras que la salida de la sandbox descrita se comprobó con workspace-write. El éxito de toda la cadena en la configuración original no está completamente demostrado.

Una limitación adicional está relacionada con la protección de GitHub. Ya en junio de 2026 la plataforma limitó la escritura en la caché para eventos no confiables, y en septiembre amplió la gestión de permisos. Por ello, el esquema descrito de envenenamiento de caché depende de los permisos concretos del workflow. El peligro de la suplantación de actualizaciones de confianza ya se había manifestado en el compromiso del CLI de Bitwarden.

Depi trasladó el hallazgo a OpenAI a través de Bugcrowd. La empresa corrigió la configuración vulnerable, y en el workflow público en vez del agente se añadió una llamada al Responses API sin herramientas de ejecución de comandos. La recompensa inicial fue de 1000 dólares; la valoración final aún está pendiente. No se han publicado un CVE separado ni una puntuación CVSS para la cadena descrita. No hay confirmaciones de que el paquete oficial de npm estuviera infectado; los usuarios de Codex no necesitan una corrección adicional.