Tres investigadores dedicaron meses a no atacar el sandbox

Eilon Cohen, Dan Lisichkin y Ariel Fogel, de Pillar Security, se plantearon una pregunta muy acotada sobre los sandboxes que vienen de serie con los agentes de código con IA. No si los muros aguantan, sino si los muros están levantados donde corresponde. El 20 de julio de 2026 empezaron a publicar la respuesta en forma de serie, bajo el nombre Week of Sandbox Escapes, con una entrega diaria dedicada a Cursor, a la CLI de OpenAI Codex, a la CLI de Google Gemini y a Google Antigravity.

En todos los casos el agente se comportó. No salió del espacio de trabajo que se le había asignado ni incumplió ninguna regla de las que el sandbox aplica. Escribió un archivo. Un proceso ajeno al sandbox leyó ese archivo, le dio crédito y ejecutó lo que decía. La fuga se produjo sin que el agente llegara a rozar el perímetro.

Pillar condensa el hallazgo en una línea: el radio de impacto de un agente no es el proceso del agente, sino todo aquello que el agente puede escribir y que el host da luego por bueno. Esa frase es la noticia, y explica por qué parchear los fallos uno a uno no cierra el asunto.

Un socket explica tres de los cuatro productos

El hallazgo más nítido es también el menos exótico. Codex CLI, Cursor y Gemini CLI podían llegar al socket local de Docker desde dentro de sus sandboxes. Un demonio privilegiado en el host levanta un contenedor para cualquiera que sepa dirigirse a él, y ese contenedor corre por completo fuera del sandbox. Un solo aviso, GHSA-v4xv-rqh3-w9mc, cubre tres de los cuatro productos analizados. Ya está corregido.

Codex arrastraba un segundo problema de otra naturaleza. Su lista de comandos seguros autorizaba por nombre. Daba paso a git show como operación de solo lectura sin considerar lo que ciertos argumentos peligrosos de git show pueden llegar a hacer. Eso queda corregido en la versión 0.95.0, y el informe se llevó una recompensa de severidad alta.

Leídos juntos, el patrón salta a la vista. Los dos son listas de permitidos. Los dos se escribieron sobre aquello que un operador alcanza a ver, una ruta de socket y un nombre de comando, y no sobre lo que esa cosa permite hacer una vez que se llega a ella.

Las fugas entraron por archivos en los que su editor ya confía

Cursor aportó tres. Un agente podía reescribir el intérprete de un entorno virtual de Python y esperar a que la propia extensión de Python del editor, que corre sin sandbox, lo ejecutara. Podía crear un directorio de Git con un nombre no estándar, de modo que las reglas de sandbox basadas en rutas no llegaran a coincidir, y dejar que fsmonitor lo recogiera. Y podía dejar caer en el espacio de trabajo una configuración de hooks que las herramientas ejecutaban sin sandbox. Esta última tiene asignado el CVE-2026-48124 y el aviso GHSA-pc9j-3qc2-95wv, y las tres están corregidas en Cursor 3.0.0.

Los dos de Google son de la misma familia. El perfil Seatbelt de macOS que sostiene Antigravity estaba escrito como lista de denegación, que deja pasar todo lo que no se nombra de forma expresa, y una configuración de tareas .vscode conseguía burlar las protecciones del Secure Mode. Google dijo a los investigadores que el informe era de una calidad excepcional, y a continuación clasificó los hallazgos como difíciles de explotar porque exigen ingeniería social, y los rebajó por ese motivo.

La clasificación se sostiene según sus propios criterios y no aporta nada a quien tiene estas herramientas en producción. Ingeniería social, tratándose de un agente, es una frase en un README, un comentario en una incidencia o un párrafo en la documentación de una dependencia. Leer texto no confiable es la jornada de trabajo corriente del agente.

El perímetro que compró no es el perímetro que tiene

Todos estos productos presentan el sandbox como el control que vuelve aceptable la programación autónoma. Esa es la respuesta que recibe una revisión de seguridad, y es el motivo por el que se concedieron las aprobaciones. La investigación demuestra que el sandbox gobierna una sola cosa, el proceso del agente. Nunca fue una afirmación sobre el espacio de trabajo.

La superficie real es el espacio de trabajo, porque lo lee una larga lista de procesos diseñados años antes de que existieran los agentes, todos ellos partiendo de la base de que un humano tecleó lo que están leyendo. La extensión de Python. El demonio de Git. El socket de Docker. El hook de pre-commit. El instalador de dependencias. El runner de CI que clona la rama. Ninguno se construyó para tratar el contenido de un repositorio como entrada hostil, y hoy todos hacen exactamente eso.

De modo que el objeto de gobierno está mal escogido. Los responsables llevan tiempo aprobando agentes. Lo que necesita una política es el espacio de trabajo, y la regla cabe en una línea: un repositorio en el que puede escribir un agente de IA es entrada no confiable para todos los procesos que quedan aguas abajo, en el mismo plano que un archivo subido por un desconocido.

Qué cambiar esta semana

Empiece por el socket, porque un solo aviso cubrió tres de los cuatro productos. Ningún agente de código necesita acceso a un socket de Docker, y quitárselo es un cambio de configuración, no un proyecto. Después, actualice las versiones. Cursor 3.0.0 y Codex CLI 0.95.0 son las líneas corregidas, y las herramientas de desarrollo se actualizan usuario a usuario y no por flota, así que un fabricante que publica un parche no equivale a unos ingenieros que ya lo tienen puesto.

El cambio que perdura está en dónde se ejecutan los agentes. Una rama que haya pasado por un agente debería llegar a la CI marcada como no confiable, lo que en la práctica significa que el pipeline no ejecuta hooks, tareas ni intérpretes procedentes de esa rama mientras una persona no haya aprobado el diff. Es una decisión de pipeline y no de herramienta, y sigue en pie tras la siguiente divulgación.

Con NIS2 en la mano, un incidente que arranca en el editor de un desarrollador y acaba en su pipeline de producción está sujeto a los mismos plazos de notificación que cualquier otro. El deber no distingue entre un atacante que se hizo con las credenciales de un ingeniero por phishing y un agente que leyó un README envenenado, así que el control tiene que situarse donde el pipeline pueda imponerlo.

Leer a continuación: El parche de nginx ya está, el exploit llega en agosto  |  ServiceNow parcheó su nube primero y a usted 103 días más tarde