Un grupo de investigadores de Simon Fraser University, Chinese University of Hong Kong, Shandong University y el laboratorio Xingtu (QAX) publicó en arXiv un trabajo que demuestra siete ataques contra cinco frameworks abiertos de agentes móviles de IA: AppAgent, AppAgentX, Mobile-Agent-v3, Open-AutoGLM y MobA. La cadena de ataque comienza con texto invisible para el ser humano en la pantalla de un dispositivo Android y termina en la ejecución de comandos arbitrarios en el PC que controla al agente. Cada uno de los cinco frameworks resultó vulnerable al menos a seis de las siete técnicas demostradas. Según los autores, no se ha observado explotación en condiciones reales, y el software afectado es un conjunto de herramientas para desarrolladores que requiere tener activada la depuración por USB y una aplicación auxiliar instalada.
Anatomía de la cadena: del píxel al shell
El problema clave es la ausencia de un límite de seguridad entre lo que el modelo de IA “ve” en la captura de pantalla y lo que transmite al shell del sistema en el host. El ataque explota simultáneamente tres eslabones débiles: la percepción del modelo, el sistema de archivos del dispositivo y el mecanismo de introducción de comandos.
Texto invisible, visible para los modelos
Según los investigadores, los seis modelos de visión por computador probados —incluidos GPT-4o, Claude Opus 4.5, Gemini 3 Pro y GLM-4V— reconocieron texto con una opacidad del 2 % al menos en 18 de 20 intentos. Cuatro de ellos obtuvieron un resultado de 20/20. La visión humana, en condiciones normales de visualización, no percibe este texto. Esto crea una asimetría: una aplicación maliciosa con permiso para dibujar sobre otras ventanas puede colocar instrucciones invisibles para el usuario pero completamente legibles para el agente.
La versión hardware de este mismo problema son las esquinas redondeadas y los recortes para la cámara. El framebuffer sigue siendo rectangular, y los píxeles ocultos tras el marco aparecen en cada captura de pantalla. En el Pixel 4, según el estudio, se trata de unos 78 píxeles de ancho en una esquina, suficiente para una orden corta. Los cinco agentes leyeron la carga útil en estas áreas.
Carrera por la captura de pantalla
Los frameworks guardan las capturas de pantalla en el almacenamiento público del dispositivo antes de subirlas al host. Open-AutoGLM escribe el archivo en una ruta fija, /sdcard/tmp.png. Mobile-Agent-v3 utiliza /sdcard/screenshot.png con una pausa de medio segundo entre la captura y la extracción. AppAgentX emplea nombres previsibles con un contador incremental. La configuración de AppAgent por defecto apunta a /sdcard.
Los investigadores midieron la ventana entre la escritura y la lectura del archivo: de 50 a 500 ms, con una media de unos 210 ms en 100 ejecuciones. Un servicio en segundo plano que sondea el archivo cada 5–10 ms consigue sustituir el PNG antes de que el agente lo recupere. La tasa de éxito de la sustitución fue de 19/20 a 20/20 para cuatro de los cinco frameworks.
De la captura de pantalla a la ejecución de código en el host
El eslabón más crítico es el controlador de AppAgent, que llama a subprocess.run(adb_command, shell=True) e inserta directamente la salida del modelo en la construcción adb shell input text {input_str}. El código elimina espacios y comillas simples, pero no filtra los metacaracteres del shell: ;, &, >. La cadena que el modelo lee de la pantalla es dividida por el shell del sistema en el host, y la segunda parte se ejecuta en la máquina del operador.
Según los investigadores, la carga útil para lanzar calc.exe funcionó en 20 de 20 intentos contra AppAgent, AppAgentX, Mobile-Agent-v3 y MobA. Una prueba independiente con la construcción test;pwd>rce_success escribió el directorio de trabajo del host en un archivo.
Canal de entrada sin protección
Los agentes usan los mecanismos de depuración de Android como canal principal de interacción con el dispositivo. Open-AutoGLM codifica el texto en Base64 y lo envía mediante un broadcast implícito ADB_INPUT_B64, destinado a ADB Keyboard, una herramienta de automatización de pruebas. Cualquier aplicación que registre la misma action recibe los mismos datos sin ningún tipo de permiso.
MobA comprueba la cadena con text.isascii(): una sola letra no ASCII en el mensaje hace que todo el texto se envíe íntegro mediante broadcast. Otro ataque, a través del servicio de accesibilidad, permite interceptar el texto introducido, incluidas contraseñas, mediante el evento TYPE_VIEW_TEXT_CHANGED; según los investigadores, esto funcionó contra los cinco frameworks.
Otra demostración: una Activity de autenticación falsa, superpuesta a la aplicación real, recopiló credenciales en las 100 ejecuciones de prueba. Ninguno de los cinco agentes detectó la suplantación.
Contexto: el patrón se repite
El modelo de ataque descrito —la salida de una LLM que llega al shell del sistema— ya ha recibido reconocimiento formal. Microsoft, en mayo de 2026, describió un problema análogo en su framework Semantic Kernel, asignándole los identificadores CVE-2026-25592 y CVE-2026-26030, y publicó una corrección. La formulación de Microsoft —«su LLM no constituye un límite de seguridad»— es aplicable sin cambios a los agentes móviles.
Trabajos previos de Wu et al. (mayo de 2025) y Ding et al. (octubre de 2025) ya habían demostrado la inyección de prompts mediante overlays contra AppAgent y Mobile-Agent. El nuevo trabajo amplía la cadena hasta salir del dispositivo y alcanzar el host del operador.
Evaluación del impacto
El riesgo inmediato está limitado por varios factores: se ven afectados frameworks de investigación de código abierto y no asistentes integrados (Samsung Bixby y Xiaomi XiaoAi quedaron fuera del alcance del estudio); los ataques requieren que la depuración USB/inalámbrica esté activada y que haya una aplicación instalada. Sin embargo, una de las variantes de ataque no requiere en absoluto una aplicación maliciosa: la carga útil puede incrustarse en los canales de crominancia de una imagen que la víctima reciba por un mensajero. Los autores lo presentan como una extensión conceptual, no como un resultado medido.
Open-AutoGLM tiene más de 25 000 estrellas en GitHub y su documentación guía al usuario paso a paso para activar la depuración USB e instalar el teclado, creando todos los pre-requisitos para los ataques descritos, excepto la propia aplicación maliciosa.
Ninguno de los cinco repositorios, según los datos disponibles, dispone de una política de seguridad publicada ni de un canal para comunicar vulnerabilidades. Los investigadores notificaron los problemas por correo electrónico antes de publicar el preprint pero, según el primer autor, no recibieron respuesta. No se han asignado identificadores CVE a los problemas descritos.
Recomendaciones para la mitigación
Las medidas propuestas no requieren modificar los propios modelos:
- Abandonar
shell=True: pasar los argumentos como lista (argv) para que los metacaracteres se mantengan como literales. Open-AutoGLM ya implementa este enfoque y, según los investigadores, es el único de los cinco resistente a la inyección de comandos en el host. - Transmisión en streaming de las capturas de pantalla mediante
exec-outen lugar de escribir en el dispositivo y extraer posteriormente. MobA ya utiliza este método, eliminando la ventana de carrera. - Protección de los canales de entrada por broadcast: uso de permisos de nivel de firma o intents explícitos en lugar de broadcasts implícitos.
- Control de la Activity: comparar la Activity en primer plano antes y después de cada acción, manteniendo una lista de paquetes permitidos para la tarea.
- Aumento del contraste de las capturas antes de enviarlas al modelo: una medida parcial contra el texto invisible, no una solución completa.
Para la inyección a través de áreas hardware (esquinas, recortes), los autores señalan explícitamente: «no existe una solución software eficaz». Enmascarar las esquinas es una forma de rodear un hecho de hardware. El mecanismo de confirmación de acciones sensibles, implementado en Open-AutoGLM, es, según la evaluación de los investigadores, insuficiente: los ataques a la percepción reescriben el propio juicio del modelo sobre lo que es sensible.
Los desarrolladores de frameworks de agentes móviles deberían eliminar de inmediato la inyección de comandos vía shell=True y pasar a la transmisión en streaming de las capturas de pantalla: estas dos medidas cierran los eslabones más críticos de la cadena, desde la sustitución del archivo hasta la ejecución de código en el host. Igualmente importante es crear un canal formal para la notificación de vulnerabilidades: la ausencia de una política de seguridad en repositorios con decenas de miles de estrellas es un problema sistémico que convierte la divulgación responsable en una carta al vacío.
