L’agent IA open source de GitHub découvre 24 failles Android, dont un détournement de comptes Wikipédia
Le Taskflow Agent de GitHub Security Lab a trouvé 24 vulnérabilités Android réelles, du suivi de localisation via OsmAnd à la prise de contrôle de comptes Wikipédia. L’IA sait désormais trouver les bugs de logique à fort impact, mais pas encore les hiérarchiser.
28 septembre 2026. Kevin Stubbings, de GitHub Security Lab, publie le bilan d’un audit mené avec le Taskflow Agent, leur agent d’IA de sécurité open source : 24 vulnérabilités Android découvertes et signalées. 28 septembre 2026. Le billet détaille deux cas critiques, dont un suivi de localisation sur OsmAnd, une app de navigation dépassant les 10 millions de téléchargements. 28 septembre 2026. La même technique permet une prise de contrôle de comptes Wikipédia à travers l’application officielle. Pourquoi c’est important : l’IA franchit un seuil — elle ne trouve plus seulement des classes de bugs génériques, mais des bugs de logique à impact critique.
Un agent qui découpe l’audit en étapes guidées
Le Taskflow Agent repose sur un principe simple : les grands modèles comprennent bien le code, mais se perdent sur les gros dépôts. La parade de GitHub Security Lab consiste à découper la recherche en taskflows — des fichiers YAML qui portent des prompts décrivant, étape par étape, ce que le modèle doit chercher.
Pour Android, deux ajouts font la différence. Un taskflow gather_mobile_entry_point_info.yaml isole les points d’entrée — les endroits du code où une donnée contrôlée par un attaquant peut pénétrer — et les sépare entre mobiles et non mobiles, afin que le modèle cible la bonne surface d’attaque. Un second fichier, classify_application_local.yaml, injecte une liste de classes de vulnérabilités mobiles (confused deputy, diffusion non sécurisée, etc.) que le modèle doit vérifier à chaque point d’entrée.
L’intérêt est double. Le prompt strict et les passes répétées évitent de rater les bugs évidents, tandis que le prompt large laisse le modèle exercer sa créativité sur les cas tordus. Le tout est exécutable en une commande :
git clone https://github.com/GitHubSecurityLab/seclab-taskflows
cd seclab-taskflows
./scripts/audit/run_mobile.sh myorg/myrepoLe coût est assumé et documenté : une licence GitHub Copilot, des appels de modèles premium, et une consommation de jetons qui peut grimper vite. Un audit complet prend une à deux heures sur un dépôt de taille moyenne.
OsmAnd : suivre un utilisateur à travers ses tuiles de carte
Le premier exemple montre que l’impact dépasse le simple crash. OsmAnd exporte une activité nommée MapActivity, qui gère l’import de fichiers de configuration via des intent extras : settings_version, silent_import, replace, export_type_list_key.
Le problème est structurel. Cette activité est exportée, donc n’importe quelle app peut lui envoyer un intent avec des extras arbitraires — Android n’offre aucun mécanisme pour restreindre ce qu’un appelant externe peut poser. En injectant silent_import et replace, une app sans aucune permission importe une configuration à l’insu de l’utilisateur.
La configuration importée contient le modèle d’URL des tuiles de carte. OsmAnd formate l’URL de chaque tuile ainsi :
MessageFormat.format(urlTemplate, zoom, x, y)En remplaçant ce modèle par un domaine contrôlé par l’attaquant, chaque tuile chargée remonte au serveur ses coordonnées x, y et son niveau zoom. L’attaquant reconstitue alors les coordonnées exactes de chaque tuile affichée, ainsi que l’origine et la destination de chaque itinéraire calculé — sans que l’utilisateur ne voie rien. Un suivi de localisation complet, obtenu par une simple manipulation de configuration.
Wikipédia : la prise de contrôle par deeplink
Le second exemple est plus grave encore. L’application Wikipédia enregistre un hook pour le deeplink wikipedia://, censé n’ouvrir que des pages du domaine Wikipédia. Une erreur de logique dans l’analyse du nom d’hôte permet de charger n’importe quelle URL.
La conséquence en cascade est dévastatrice. L’attaquant fait ouvrir une page se terminant par wikipedia.org — par exemple evil-wikipedia.org — qui passe le test de domaine alors qu’elle est hostile. La page s’exécute dans la WebView de l’application, avec du JavaScript arbitraire, dans un contexte normalement considéré comme sûr. Une seconde faiblesse, dans SharedPreferenceCookieManager.kt, vérifie le domaine des cookies avec un simple endsWith :
if (domain.endsWith(domainSpec)) {
buildCookieList(cookieList, cookiesForDomainSpec, null)
}En chaînant les deux failles, l’attaquant récupère les cookies de longue durée de la victime : son nom d’utilisateur, son jeton de session et son jeton longue durée, valables sur tous les projets Wikimedia — toutes les Wikipédia, Commons, Wikidata, Meta. Une prise de contrôle de compte complète, à partir d’un simple clic sur un lien.
Ce que l’IA sait faire — et ce qu’elle ne sait pas
Le bilan est nuancé, et c’est ce qui le rend crédible. GitHub Security Lab constate que les modèles excellent à trouver des vulnérabilités, au point de remonter des bugs de faible gravité sans grande importance, et qu’ils possèdent une connaissance fine des API sensibles — capable de produire des preuves de concept presque exploitables sans modification.
Le point faible est ailleurs : l’estimation de la sévérité. Le modèle surévalue ou sous-évalue régulièrement l’impact réel, faute de voir les facteurs atténuants — par exemple une traversée de chemin cantonnée au stockage externe, ou une donnée interne qui écrase une donnée contrôlée par l’attaquant. D’où la règle d’or énoncée par l’équipe : chaque découverte doit être revue par un chercheur humain qui connaît le mobile.
La leçon tient en une phrase : l’IA est devenue un amplificateur de recherche, pas un remplaçant. Elle multiplie le nombre de bugs trouvés, y compris des bugs de logique à impact critique ; elle ne décide pas, seule, de ce qui mérite un correctif.
Ce que ça change pour la défense
Le même outillage change la donne des deux côtés. Pour un défenseur, ces taskflows transforment un audit manuel de plusieurs semaines en une passe de quelques heures — le temps de configurer le dépôt, de lancer le script et de trier les résultats. Pour un attaquant, le raisonnement inverse s’applique : un modèle capable de produire des preuves de concept quasi exploitables réduit le coût de la découverte.
L’asymétrie n’est pourtant pas nouvelle. Elle tient à la vélocité : quand la découverte s’automatise, la fenêtre entre la publication d’une app et l’exploitation de ses failles se réduit. La réponse n’est pas de fuir l’IA, mais de l’intégrer dans le cycle de développement — en auditant avant la publication, pas après la compromission.
Verdict
Si vous maintenez une app Android open source, lancer les taskflows du Taskflow Agent sur votre dépôt est une démarche à fort rendement : le coût est une licence Copilot et quelques heures, le gain est un tri des bugs de logique que les scanners classiques ne voient pas. Si vous consommez du code ou des apps tierces, retenez surtout le seuil franchi — des attaquants disposent désormais du même outillage, et la frontière entre audit et exploitation devient une question de qui tire la première. Dans les deux cas, gardez un humain dans la boucle pour la sévérité : l’IA trouve, l’humain décide.