Un agente de IA para cazar fallos en Android

Kevin Stubbings, investigador de GitHub Security Lab, ha publicado el 28 de septiembre de 2026 un informe en el que detalla cómo un agente de seguridad basado en inteligencia artificial, desarrollado internamente y disponible en código abierto, logró identificar 24 vulnerabilidades en aplicaciones Android. La herramienta se llama Taskflow Agent y nace con un objetivo concreto: permitir que los investigadores de seguridad automatizen, empaqueten y compartan los prompts y flujos de trabajo que consideran más eficaces. El repositorio seclab-taskflows contiene estas taskflows listas para usar, aunque su ejecución requiere una licencia de GitHub Copilot y consume una cantidad elevada de tokens por las numerosas llamadas a herramientas que genera.

Los modelos de lenguaje están mejorando en comprensión de código, pero Stubbings señala que los prompts personalizados permiten guiar al modelo mediante la división del análisis en pasos incrementales. Esta estrategia acelera la detección de fallos complejos que podrían pasar desapercibidos con un enfoque más general. Los resultados ya se publican en la página de advisories de GitHub, donde se van haciendo públicos los hallazgos a medida que se reportan a los responsables de cada proyecto.

Cómo funciona el análisis automatizado

El proceso comienza descargando el repositorio seclab-taskflows y creando un codespace de GitHub. Una vez inicializado, basta con ejecutar el script run_mobile.sh indicando la organización y el repositorio objetivo; en repositorios de tamaño medio, el análisis puede tardar entre una y dos horas. Al finalizar, se abre un visor SQLite con los resultados en una tabla llamada audit_results, donde las filas marcadas con una palometa en la columna has_vulnerability indican los fallos detectados.

Las taskflows que Stubbings desarrolló para Android se construyen sobre el trabajo previo de sus colegas Peter y Mo. A diferencia de los análisis generales, las aplicaciones móviles presentan clases de vulnerabilidades específicas que requieren un enfoque orientado. Para ello, añadió primero una taskflow llamada gather_mobile_entry_point_info.yaml, que toma los puntos de entrada del código —lugares por donde los datos controlados por un atacante pueden fluir— y los separa entre entry points móviles y no móviles. Esto permite que el agente analice repositorios que contienen múltiples tipos de aplicación, como servidores web o software de escritorio, centrándose siempre en la superficie de ataque correcta.

Posteriormente, modificó classify_application_local.yaml para incluir una lista de clases de vulnerabilidad populares y obligar al modelo a considerarlas en el contexto de cada entry point y componente. Dado que las vulnerabilidades móviles son menos conocidas y los modelos de lenguaje no son deterministas, esta guía asegura que el agente verifique fallos esenciales. Por ejemplo, si en el paso anterior se identificó un entry point basado en intents, el agente debe consultar una lista predefinida de vulnerabilidades típicas de esa categoría, como confused deputy o broadcasts inseguros. Esta combinación de prompts estrictos con ejecuciones repetidas garantiza que los fallos evidentes no se pierdan, mientras que el prompt más amplio permite que la creatividad del modelo aplique a pleno rendimiento.

Dos casos de estudio entre los 24 fallos

De los 24 fallos reportados, Stubbings destaca dos ejemplos de alto impacto que ya han sido publicados. Ambos revelan problemas que un auditor humano podría haber pasado por alto por su complejidad o por la necesidad de recorrer múltiples capas de lógica en el código.

Rastreo de ubicación en OsmAnd

OsmAnd es una aplicación de navegación de código abierto que utiliza OpenStreetMap como fuente principal de mapas, con más de 10 millones de descargas en Google Play. Entre las tres vulnerabilidades encontradas en ella, la más relevante permite a cualquier aplicación, incluso sin permisos, rastrear la ubicación exacta del dispositivo. El fallo radica en MapActivity, una actividad exportada que maneja archivos de configuración y deeplinks. Las actividades exportadas en Android pueden ser lanzadas por componentes externos a la aplicación, pero en este caso MapActivity acepta extras de intent —pares clave-valor adjuntos a un mensaje— sin validar su procedencia, ya que solo debería recibirlos a través de un servicio AIDL.

Este diseño permite que cualquier app inyecte extras maliciosos que activan funciones de importación de configuración, incluyendo la capacidad de importar de forma silenciosa, reemplazar configuraciones existentes sin confirmación del usuario y modificar tipos de exportación. El código muestra claramente que variables como silentImport y replace provienen directamente de extras controlados por el atacante. Una vez importada la configuración maliciosa, el problema se agrava: el atacante puede sobrescribir las plantillas de URL de los tiles del mapa, sustituyendo los tiles locales por URLs指向 a un servidor controlado por él, y recuperando así las coordenadas exactas x, y de cada tile que el usuario carga en su dispositivo.

Con estos datos, un atacante puede reconstruir la posición geográfica precisa del usuario con una resolución de zoom 15, obteniendo coordenadas como 40.70979, -73.98743. El mismo mecanismo permite además capturar el origen y destino de todas las rutas que calcule el usuario, sin que este perciba ningún cambio en el comportamiento de la aplicación. Todos estos datos se envían al servidor del atacante de forma transparente.

El segundo ejemplo se encuentra en la aplicación Android de Wikipedia, que registra un deeplink con el esquema wikipedia:// para abrir páginas dentro de la app. Un deeplink típico tendría la forma wikipedia://wikipedia.org/wiki/PoC. Sin embargo, un error de lógica en el analizador de hostnames permite cargar direcciones web ajenas a Wikipedia. La función handleIntent verifica si la autoridad del URI termina en el dominio base de Wikipedia, pero un fallo en este parser abre la puerta a que URLs de dominios diferentes sean interpretadas como válidas, lo que podría permitir ataques de suplantación o toma de cuenta del usuario que utilice la app.

Disponibilidad y alcance de la herramienta

La metodología descrita por Stubbings no se limita a un solo repositorio ni a un conjunto cerrado de tareas. Las taskflows están diseñadas para ser adaptadas y extendidas por la comunidad de investigación en seguridad, lo que amplía su potencial más allá de las 24 vulnerabilidades ya descubiertas. El hecho de que el código esté disponible públicamente en el repositorio seclab-taskflows significa que otros investigadores pueden ejecutar los mismos flujos sobre sus propios proyectos o sobre aplicaciones de terceros, con el fin de descubrir fallos adicionales.

La dependencia de GitHub Copilot y el consumo elevado de tokens premium son las principales barreras de entrada. No obstante, el modelo de distribución open source y la documentación proporcionada por el equipo de GitHub Security Lab sitúan esta iniciativa como una de las primeras propuestas serias de auditoría automatizada de código móvil basada en agentes de inteligencia artificial, lo que podría terminar por establecer un nuevo estándar en la forma en que se aborda la seguridad de las aplicaciones Android.

Contexto: la IA aplicada a la ciberseguridad móvil

La publicación del 28 de septiembre de 2026 se enmarca en un momento en el que la comunidad de seguridad lleva tiempo explorando el uso de modelos de lenguaje grandes para asistir en tareas de auditoría de código. Hasta ahora, la mayoría de los esfuerzos se habían centrado en lenguajes y plataformas de servidor o escritorio; Android ha permanecido más rezagado debido a la complejidad de su modelo de componentes, sus mecanismos de comunicación interproceso y la variedad de vectores de ataque específicos de la plataforma. Las taskflows de GitHub Security Lab superan parte de esa brecha al incorporar conocimiento específico sobre entry points móviles, clases de vulnerabilidades Android y la capacidad de guiar al modelo mediante prompts segmentados.

Los 24 fallos confirmados representan solo una fracción de lo que podría descubrirse al escalar esta metodología. Stubbings indica en su publicación que ya ha reportado más de 20 vulnerabilidades utilizando estos taskflows, pero no se ofrecen cifras sobre el total de aplicaciones auditadas ni sobre la tasa de falsos positivos generados durante el proceso. Lo que sí queda claro es que la combinación de prompts especializados, ejecuciones iterativas y validación humana sigue siendo necesaria para filtrar los hallazgos y confirmar su explotabilidad antes de hacerlos públicos.