Continue resistió, pero los demás cedieron: diez agentes de IA cayeron ante la vulnerabilidad GuardFall y filtraron secretos a hackers.

Las herramientas en las que cada vez confían más el código y los archivos de trabajo resultaron vulnerables no por una nueva técnica de ataque, sino por un viejo truco de la línea de comandos que rompe las comprobaciones de seguridad de los agentes de IA.

Los especialistas de Adversa AI describieron la clase de problemas GuardFall en agentes de IA de código abierto para programación y manejo del ordenador. Esos agentes pueden ejecutar comandos en la shell con los privilegios del usuario, incluyendo acceso a claves SSH, credenciales en la nube y archivos en el directorio personal. En muchos proyectos la protección se reduce a comprobar el texto del comando según una lista de patrones peligrosos, pero bash antes de ejecutar cambia la cadena: expande variables, elimina comillas y recompone los argumentos.

Debido a la diferencia entre el comando «comprobado» y el realmente ejecutado, una acción peligrosa puede pasar el filtro. La fuente describe técnicas como dividir una palabra con comillas, reemplazar espacios mediante $IFS, sustitución de comandos, pasar una cadena Base64 a sh y usar utilidades que solo son destructivas con ciertos flags. Ese enfoque no requiere vulnerar el propio agente: una instrucción maliciosa puede aparecer en un README, Makefile, la descripción del paquete, una respuesta del servidor MCP, un correo o cualquier otro texto que el agente lea durante su funcionamiento.

La comprobación abarcó 11 agentes populares de código abierto, incluyendo Hermes, opencode, Goose, Cline, Roo-Code, Aider, Plandex, OpenInterpreter, OpenHands, SWE-agent y Continue. En diez de ellos la frontera entre el comando del agente y bash siguió siendo vulnerable en distintas variantes: parte de los proyectos usaba la verificación de la cadena sin procesar, parte dependía de la confirmación humana y parte se protegía con un contenedor solo hasta que se activaba el modo local. Continue fue el único ejemplo donde la protección por defecto cubría la mayor parte de la superficie de ataque.

En las pruebas de laboratorio el ataque se realizaba a través de un escenario de trabajo habitual. En un ejemplo un Makefile malicioso inducía al agente a ejecutar make test, tras lo cual un comando eliminaba las credenciales en la nube del directorio personal. Los autores subrayan que la cadena depende del comportamiento del modelo de lenguaje y del contexto: un comando malicioso directo suele ser rechazado por el modelo, pero el mismo comando presentado como parte de un archivo de trabajo o de una instrucción puede parecer para el agente una tarea normal.

El riesgo principal está en los modos de autoarranque y el trabajo local sin un entorno aislado. En integración continua, en el portátil del desarrollador o en un servidor propio para ejecutar tareas de CI, el comando del agente obtiene los mismos permisos que el usuario. Un contenedor reduce el daño solo en entornos de trabajo efímeros, y desactivar el contenedor vuelve a exponer el ataque al host.

Para reducir el riesgo, los especialistas recomiendan ejecutar los agentes con un HOME separado sin acceso a ~/.ssh y ~/.aws, revisar scripts shell multilínea antes de su ejecución, tratar las configuraciones procedentes de repositorios como código no confiable, desactivar el autoarranque de comandos y no ejecutar agentes sobre pull request desde forks en CI privilegiados.

Para protección a largo plazo, a los desarrolladores de agentes se les sugiere implementar una comprobación que analice el comando de la misma forma que la shell, tenga en cuenta sustituciones, canalizaciones hacia intérpretes y patrones destructivos prohibidos.