GitHub detecta 24 vulnerabilidades Android con su IA open source

El Taskflow Agent de GitHub encontró 24 fallos en apps Android usando IA

Un equipo de GitHub Security Lab reportó haber detectado 24 vulnerabilidades en aplicaciones Android ejecutando un agente de IA de código abierto bautizado como GitHub Security Lab Taskflow Agent. El hallazgo, publicado en el blog oficial de GitHub, incluye dos casos críticos: un fallo en la app de navegación OsmAnd (más de 10 millones de descargas en Google Play) que permite rastrear la ubicación del usuario sin su consentimiento, y un takeover de cuenta en la app de Wikipedia para Android encadenando dos bugs en el manejo de deeplinks.

El contexto importa: según datos publicados por Cloudflare en septiembre de 2026, la National Vulnerability Database (NVD) ya acumulaba 60.475 vulnerabilidades en lo que va del año, superando las 48.185 registradas en todo 2025. La velocidad a la que aparecen fallos supera la capacidad de revisión manual, y ahí es donde el enfoque de GitHub busca marcar diferencia.

¿Qué es el Taskflow Agent y cómo funciona?

A diferencia de los escáneres tradicionales que buscan patrones conocidos de vulnerabilidades (CVEs, firmas estáticas, reglas SAST), el Taskflow Agent está construido sobre flujos de trabajo en YAML que guían a un modelo de lenguaje (LLM) paso a paso por el código de un repositorio. El repositorio se llama seclab-taskflows y es open source, aunque requiere una licencia de GitHub Copilot para ejecutarse, ya que los prompts consumen peticiones a modelos premium.

🤖 La IA no es solo para leer sobre ella

En la comunidad la aplicamos: automatización, agentes IA y herramientas reales para emprender, no solo para informarte.

👥 Aplicarla en la comunidad

El flujo general es:

Clonar el repositorio en un Codespace de GitHub.
Ejecutar ./scripts/audit/run_mobile.sh myorg/myrepo en la terminal.
Esperar una o dos horas para un repositorio mediano.
Revisar los resultados en una base SQLite local, filtrando por la columna has_vulnerability.

Para aplicaciones móviles, el equipo añadió dos piezas clave que no existían en sus flujos genéricos:

gather_mobile_entry_point_info.yaml — clasifica los puntos de entrada del código separando los móviles (Activities, Intents, ContentProviders) de los de web, escritorio o backend. Esto permite auditar repositorios mixtos sin que el modelo se confunda con la superficie de ataque equivocada.
classify_application_local.yaml — inyecta al LLM una lista priorizada de clases de vulnerabilidad típicas de Android (confused deputy, broadcasts inseguros, path traversal en almacenamiento externo, deep link hijacking, etc.) que el modelo debe evaluar para cada punto de entrada.

La lógica subyacente es iterativa: el agente ejecuta el flujo varias veces, alternando entre prompts estrictos (que garantizan que no se escapen errores obvios) y prompts abiertos (que dejan al modelo aplicar su creatividad). El propio equipo reconoce que esto puede consumir muchos tokens y exige Copilot con cuota generosa.

Los dos hallazgos que demuestra el verdadero poder del enfoque

OsmAnd: rastrear la ubicación del usuario sin permisos

OsmAnd es una app de navegación basada en OpenStreetMap con más de 10 millones de descargas en Android. La vulnerabilidad aprovechaba que su MapActivity está exportada y acepta intent extras controlables por cualquier app del dispositivo. Esos extras (replace, silentImport, settingsVersion)permitían sobrescribir los ajustes del mapa en silencio y redirigir la URL de los tiles a un servidor atacante.

El resultado: el servidor malicioso recibía las coordenadas exactas (x, y, zoom) de cada tile que el usuario había cargado, lo que permitía reconstruir su ubicación con precisión de manzana, e incluso capturar origen y destino de cada ruta planificada. Todo esto desde una app sin permisos especiales, en una llamada que la víctima nunca notaba.

Wikipedia: takeover de cuenta encadenando dos bugs

En la app oficial de Wikipedia para Android, dos bugs separados en el manejo de deeplinks wikipedia:// se combinaban para un ataque devastador:

Un primer fallo en el parser del hostname permitía cargar URLs que no eran de wikipedia.org dentro del WebView de la app.
Un segundo bug en SharedPreferenceCookieManager.kt hacía que las cookies de la sesión se enviaran a cualquier dominio que terminara en el patrón wikipedia.org (por ejemplo, evil-wikipedia.org).

La cadena de ataque: la víctima hace clic en un enlace malicioso en su navegador → la app de Wikipedia abre → carga una página controlada por el atacante que parece de Wikipedia → el WebView envía automáticamente las cookies de sesión. El atacante obtiene usuario, token de larga duración y token de sesión válidos en todos los proyectos Wikimedia (Wikipedia en todos los idiomas, Commons, Wikidata, Meta).

Lo que los LLMs aún no hacen bien

El equipo de GitHub fue transparente con las limitaciones:

Estimación de severidad incorrecta. El modelo suele marcar como críticas vulnerabilidades que en la práctica tienen factores mitigantes, y al revés. Por ejemplo, un path traversal cuyo filepath está restringido al almacenamiento externo tiene impacto relativo bajo.
Falsos positivos por no entender el contexto completo. Si una app prioriza datos del almacenamiento interno sobre el externo, una vulnerabilidad que sólo afectara al segundo podría no ser explotable. El LLM, sin ver el flujo completo, la reporta igual.
Dependencia del prompting. Los autores tuvieron que pedir explícitamente al modelo que generara pruebas de concepto (PoC) para forzar al LLM a intentar explotar la vulnerabilidad y descartar falsos positivos. Aun así, recomiendan revisión humana de cada hallazgo por un investigador con experiencia en mobile.

La conclusión que dejan es pragmática: los LLMs son buenos detectando vulnerabilidades (incluso lógica compleja, no solo patrones genéricos), pero malos priorizando su impacto real. El humano sigue en el loop.

¿Qué significa esto para tu startup?

Si estás construyendo una app móvil, una webapp o cualquier producto que maneje datos sensibles, hay tres movimientos concretos que puedes hacer esta semana:

Audita tus puntos de entrada exportados. Cualquier Activity, deep link, intent filter o ContentProvider que declares como exported="true" en tu AndroidManifest es una puerta abierta. Haz una lista y pregúntate: ¿qué extras acepta? ¿Quién puede invocarlos? ¿Qué datos pueden sobreescribir? El caso de OsmAnd es un recordatorio de que basta un intent extra mal validado para perder toda la ubicación de tus usuarios.
Prueba el Taskflow Agent en tu propio repo. Es open source, está en github.com/seclab-taskflows, y aunque requiere Copilot, el costo de ejecutarlo contra tu app es muchísimo menor que el costo de un breach. Empieza con ./scripts/audit/run_mobile.sh tuorg/turepo y revisa la columna has_vulnerability en el SQLite resultante.
Combina IA con revisión humana. La industria ya va en esa dirección: en Black Hat 2026, vendors como Bugcrowd lanzaron Savant Pathseeker para hacer pentesting continuo con IA más validación humana. Cloudflare anunció un servicio con OpenAI Daybreak (GPT-5.6 Cyber) para descubrir y parchear vulnerabilidades en minutos tras la divulgación. La tendencia es clara: la IA escala el hallazgo, el humano decide qué arreglar primero y cómo.

El mensaje de fondo para founders es incómodo pero útil: la IA ya encuentra los fallos que tu equipo de seguridad no tiene tiempo de buscar. Ignorar eso en 2026 es dejar que la competencia (o un atacante) los encuentre antes que tú.