GuardFall: los guardas de comandos de los agentes de código inspeccionan un texto que el shell reescribe

¿Qué es esto?

El 30 de junio de 2026, Adversa AI publicó GuardFall, un estudio sobre cómo los agentes de código de IA de código abierto deciden si un comando de shell es seguro de ejecutar. La firma probó once agentes populares de código y de uso-de-ordenador de código abierto y encontró la misma debilidad en diez de ellos; solo uno, Continue, estaba diseñado para resistirla. La cobertura siguió en The Hacker News, SecurityWeek y SC Media.

No se trata de un error aislado de un producto. Adversa lo describe como «una convención peligrosa y una clase de problemas», por lo que no existe ningún identificador único que rastrear o parchear. Los agentes protegen la ejecución del shell comparando cada comando con una lista negra de patrones peligrosos, como texto en bruto. Luego el shell reescribe ese mismo texto —elimina comillas, expande atajos— antes de ejecutarlo. El filtro y el shell examinan dos cadenas distintas. Es el mismo desajuste entre inspección y ejecución que ha impulsado la inyección SQL y la inyección de shell clásica durante décadas, reaparecido en el runtime de los agentes.

Es un pariente cercano de la evasión de la lista de bloqueo de shell del agente de Microsoft: una lista negra que razona sobre la representación equivocada del comando.

Cómo funciona

Un agente que protege comparando texto en bruto revisa una representación que el sistema operativo nunca ejecuta realmente. La brecha se ve mejor con la eliminación de comillas: un filtro que vigila un comando de borrado destructivo no ve nada anómalo en una variante donde se insertan comillas vacías entre dos letras, porque para un comparador de texto son cadenas diferentes. Bash descarta las comillas vacías y ejecuta igualmente el comando original.

El guarda inspecciona:   r''m  -rf  <ruta>   -> sin coincidencia ("rm" ausente como texto)
Bash ejecuta:            rm    -rf  <ruta>   -> comillas eliminadas, el comando real se ejecuta

Aquí no se reproduce ninguna carga funcional —el punto es estructural, y estas peculiaridades del shell son de dominio público desde hace décadas. La misma idea se generaliza: un comando oculto en un blob base64 y canalizado hacia un shell, o una herramienta ordinaria y permitida (un buscador de archivos, una utilidad de disco) vuelta destructiva con el indicador adecuado. Añadir más entradas a la lista negra no arregla nada, porque el guarda razona sobre el artefacto equivocado.

Deben alinearse dos condiciones, y ninguna es exótica:

• El modelo tiene que emitir el comando. Una petición directa de borrarlo todo suele rechazarse, pero la misma instrucción escondida en un trabajo rutinario —un archivo de compilación, o la respuesta de «documentación» de una herramienta que el agente lee a mitad de tarea— se emite como un paso ordinario. Es la inyección de prompt indirecta la que aporta la carga.
• El agente tiene que ejecutarse sin supervisión, con un indicador de autoejecución activado o el entorno aislado del contenedor desactivado —ambos habituales en las canalizaciones automatizadas. Las pruebas en vivo de Adversa usaron Claude Sonnet 4.6.

Las diez herramientas que dejaban la brecha abierta fueron opencode, Goose, Cline, Roo-Code, Aider, Plandex, Open Interpreter, OpenHands, SWE-agent y el proyecto Hermes, donde el problema apareció por primera vez. En conjunto, las herramientas estudiadas sumaban unas 548 000 estrellas de GitHub en mayo de 2026. Adversa demostró el ataque de extremo a extremo contra el binario de producción de Plandex y comprobó que la misma forma funcionaba contra otros ocho. Describe el trabajo como investigación de laboratorio; no se ha informado de explotación pública.

Por qué importa

Estos agentes ejecutan comandos de shell con todos los privilegios de la cuenta del desarrollador. Apunte uno hacia un repositorio o una dependencia manipulados, y una instrucción oculta puede lanzar en silencio un comando que borra archivos o alcanza todo lo que la cuenta pueda alcanzar —claves SSH, credenciales en la nube, cualquier cosa en el directorio personal. La condición previa es un hábito diario del desarrollador: clonar un proyecto desconocido y dejar que el agente trabaje en él. Eso lo convierte en una vía de cadena de suministro creíble, de la misma familia que AutoJack y Agentjacking, donde contenido no confiable se convierte en un comando que el agente ejecuta con los derechos de su propietario. El hilo común: texto no confiable llega a un shell real antes de que el guarda entienda qué hará bash en realidad.

Defensas

La solución duradera es arquitectónica, y una herramienta probada ya lo demuestra.

1. Proteger el comando ejecutado, no el texto. Continue aguantó porque lee el comando como lo hará bash antes de decidir: tokeniza y expande la cadena en los mismos fragmentos que produciría el shell, comprueba qué se ejecuta realmente y mantiene una lista estricta de comandos destructivos bloqueados de plano. Adversa considera el diseño portable y estima su reimplementación en unos dos días de ingeniería. Analizar-y-luego-comprobar, nunca comparar-texto-en-bruto.

2. Preferir listas blancas a listas negras. Una lista de bloqueo de patrones «peligrosos» es una batalla perdida frente a la reescritura del shell. Permita un pequeño conjunto de comandos seguros conocidos y rechace el resto, evaluado tras la expansión.

3. Neutralizar el radio de impacto. Apunte $HOME a un directorio desechable para que secretos como ~/.ssh y ~/.aws queden fuera de alcance, y mantenga activo el entorno aislado del contenedor. Si el comando esquiva al guarda, debería aterrizar en un lugar inútil.

4. No ejecutar sin supervisión sobre entradas no confiables. Desactive los indicadores de autoejecución (--auto-exec, --auto-run, --auto-test, dangerously-skip-permissions) salvo que la tarea realmente no pueda detenerse para un humano, y nunca ejecute un agente sobre pull requests procedentes de forks —el camino más corto entre el archivo de un atacante y sus secretos.

5. Tratar la configuración incluida en el repositorio como código no confiable. Un archivo de configuración incluido en un repositorio (por ejemplo .aider.conf.yml) puede dirigir al agente desde la primera edición aceptada. Revíselo antes de que el agente actúe sobre él.

Estado

Elemento	Referencia	Fecha	Notas
Divulgación de GuardFall	Adversa AI	2026-06-30	Convención de clase; sin CVE único asignado
Alcance probado	Adversa AI	2026-06	11 agentes de código abierto; 10 vulnerables, Continue resistente
Demo de extremo a extremo	Adversa AI	2026-06	Binario de producción de Plandex; investigación de laboratorio, sin explotación pública
Evasiones relacionadas	LLM Hacking	2026	Evasión de lista de bloqueo de shell, AutoJack, Agentjacking — misma brecha inspección/ejecución

El encuadre honesto no es «una herramienta de IA tiene un error», sino que un guarda que inspecciona el texto de un comando no puede asegurar un shell que reescribe ese texto antes de ejecutarlo. Hasta que los agentes analicen los comandos como lo hace el shell, la defensa depende de usted: revise el comando ejecutado, prefiera listas blancas, aísle el runtime y mantenga a un humano en el bucle en todo lo que no sea confiable.