Magazine LLM Opensource · 15 October 2026

Agents IA Android open source : quand un texte invisible à l’écran exécute du code sur votre PC

Ils sont censés automatiser vos tâches, gérer vos fichiers, contrôler votre domotique. Mais une étude publiée en juillet 2026 révèle que cinq frameworks d’agents IA open source pour Android peuvent être détournés par du texte quasi invisible à l’écran – et que ce simple artifice suffit à exécuter du code arbitraire sur le PC connecté. La menace ne vient pas d’un malware complexe, mais de la confiance aveugle d’un modèle de vision dans ce qu’il « lit ». Pire : des semaines après la divulgation, le code vulnérable est toujours en ligne, et aucun correctif n’existe. Pendant ce temps, l’écosystème des LLM open source s’emballe — Mistral Large 4, Reflection Beam, Kolibri, Solar Open 2 — mais la sécurité des agents reste le parent pauvre de cette effervescence.

L’attaque venue de l’écran : quand un texte invisible prend le contrôle de votre PC

Le 1er juillet 2026, une équipe de chercheurs issus de l’université Simon Fraser (Canada), de l’université chinoise de Hong Kong, de l’université du Shandong et du laboratoire Xingtu de QAX (Chine) a déposé sur arXiv une étude qui a immédiatement fait réagir la communauté sécurité. Révisée le 14 juillet, elle détaille une méthode d’attaque aussi simple que redoutable : afficher du texte à 2 % d’opacité par-dessus une application légitime, et laisser l’agent IA Android le lire comme s’il s’agissait d’une instruction normale. Le papier est disponible sur arXiv sous la référence 2607.00333, et l’affaire a été relayée par The Hacker News ainsi que par la presse francophone spécialisée.

Cinq frameworks open source ont été passés au crible : AppAgent, AppAgentX, Mobile-Agent-v3, Open-AutoGLM et MobA. Tous ont succombé à au moins six des sept attaques testées. Plus inquiétant encore : dans 20 essais sur 20, les chercheurs ont réussi à faire exécuter une commande ADB (Android Debug Bridge) depuis le téléphone vers le PC hôte, lançant une application sur la machine de l’opérateur sans aucune interaction humaine.

Le paradoxe est cruel : un agent conçu pour assister l’utilisateur devient, par sa propre capacité à lire et interpréter le contenu de l’écran, le vecteur d’une compromission silencieuse. Et comme le souligne l’étude, aucun correctif officiel ni canal de signalement n’a été identifié chez les éditeurs des frameworks à la date de publication. Le premier auteur, Zidong Zhang, a confirmé à The Hacker News que l’équipe a contacté les mainteneurs par courriel avant la publication du preprint — sans recevoir la moindre réponse à ce jour. Aucun CVE n’a été attribué, et les chercheurs n’ont pas de preuve que ces techniques aient été utilisées en dehors d’un cadre contrôlé.

2 % d’opacité, 100 % de danger : le mécanisme technique décortiqué

Pour comprendre l’attaque, il faut suivre la chaîne de traitement d’un agent Android typique. Prenons AppAgent, l’un des plus connus : il capture l’écran du téléphone, transmet l’image à un modèle de vision (GPT-4o, Claude Opus 4.5, Gemini 3 Pro, etc.), qui extrait le texte visible, puis un contrôleur décide de l’action à effectuer (taper, glisser, lancer une commande système).

Les chercheurs ont exploité une faiblesse à chaque maillon :

1. Camouflage visuel : une application malveillante affiche une fenêtre overlay contenant du texte à 2 % d’opacité. L’utilisateur ne voit rien, mais le modèle de vision, lui, le lit parfaitement. Sur six modèles testés, tous ont détecté le texte dans au moins 18 cas sur 20 ; certains ont obtenu un score parfait de 20/20. GPT-4o, Claude Opus 4.5 et Gemini 3 Pro sont nommément cités.

2. Injection dans la chaîne de commande : le texte invisible contient des caractères spéciaux – par exemple adb shell am start -n com.malware/.MainActivity. Or, le contrôleur d’AppAgent exécute les commandes système sans filtrage de ces caractères. Le code réel est encore plus parlant que le papier : la fonction de contrôle d’AppAgent utilise subprocess.run(adb_command, shell=True) et construit l’entrée texte en injectant directement la sortie du modèle dans adb shell input text {input_str}. La version en ligne fait un peu mieux que le papier ne le laisse croire — elle supprime les espaces et les guillemets simples avant interpolation — mais laisse tous les autres métacaractères shell intacts : pas de filtrage des ;, &, >, etc. Une chaîne lue à l’écran par le modèle, puis retranscrite telle quelle, est donc découpée par le shell de l’ordinateur hôte, et la seconde moitié s’exécute sur la machine Windows de l’opérateur.

3. Propagation au PC : via ADB, cette commande est transmise au PC hôte. Dans 20 essais sur 20, les chercheurs ont déclenché le lancement d’une application (par exemple calc.exe) sur le poste de l’opérateur. Un test de bout en bout contre AppAgent a utilisé la charge utile test;pwd>rce_success, qui a écrit le répertoire de travail de l’hôte dans un fichier — preuve de l’exécution de commandes arbitraires.

Les chercheurs ont également identifié des techniques auxiliaires : substitution de fenêtre en 50 à 500 ms (pour remplacer une capture d’écran légitime par une piégée), exploitation des zones cachées de l’écran (bords arrondis, encoche de la caméra), et une attente de 3 secondes prétextant une synchronisation réseau pour élargir la fenêtre d’attaque. La course à la capture d’écran est un élément clé : Open-AutoGLM, par exemple, exécute screencap -p /sdcard/tmp.png puis un adb pull séparé, laissant une fenêtre de vulnérabilité exploitable.

Cinq frameworks, une seule faille : anatomie d’un écosystème exposé

Les cinq frameworks testés couvrent un large spectre d’usages :

The Hacker News a vérifié les cinq frameworks après la publication : les chemins de capture d’écran, l’appel shell et le fallback par broadcast décrits dans le papier sont toujours présents sur les branches principales au 17 juillet 2026. Aucun correctif n’a été poussé, aucune issue de sécurité ouverte.

Les cas d’usage concrets sont nombreux : un agent de domotique qui allume les lumières ou ouvre une serrure connectée ; un assistant professionnel qui trie des documents sur le PC ; un outil de gestion de fichiers qui copie des données entre téléphone et ordinateur. Dans tous ces scénarios, l’agent a besoin d’un accès à l’écran et, souvent, aux commandes système.

L’open source aggrave le risque de deux manières. D’une part, le code est accessible à tous, y compris aux attaquants qui peuvent l’étudier pour trouver des failles. D’autre part, aucun des frameworks testés n’intègre de mécanismes de sécurité comme le sandboxing des commandes ADB, la validation de l’origine visuelle du texte, ou une confirmation utilisateur avant exécution système. La transparence du code ne garantit pas la sécurité des intégrations.

Scénarios rouges : ce que les chercheurs ont réellement déclenché

L’étude ne s’est pas contentée de prouver le concept. Les chercheurs ont simulé des attaques complètes :

• Lancement d’application sur le PC : dans 20 essais sur 20, une commande ADB piégée a ouvert une application (par exemple une calculette) sur le poste de l’opérateur. Preuve que l’exécution de code arbitraire est possible.
• Écriture de fichiers arbitraires : le test test;pwd>rce_success a démontré qu’une commande shell pouvait écrire la sortie d’une commande dans un fichier sur la machine hôte.
• Vol de fichiers : bien que non testé directement, le mécanisme permet d’envoyer des commandes adb pull pour exfiltrer des documents vers le téléphone, puis vers un serveur distant.
• Installation de malware : adb install peut charger un APK malveillant sur le PC (si ADB est configuré pour accepter les installations).
• Attaque sur la domotique : un agent contrôlant une serrure connectée pourrait recevoir l’ordre invisible « ouvrir la porte » et l’exécuter sans que l’utilisateur ne voie rien.

Ces attaques s’inscrivent dans la continuité des « overlay attacks » connues sur Android (où une application malveillante affiche une fausse fenêtre de connexion), mais l’IA agentive les amplifie considérablement. Là où un overlay classique vole un mot de passe, l’agent peut exécuter des commandes système complexes sur plusieurs appareils.

Des commandes audio inaudibles au texte invisible : une génération d’attaques qui monte en gamme

Ce n’est pas la première fois que des chercheurs exploitent les canaux de communication « invisibles » des IA. En 2017-2018, des attaques par ultrasons ont montré qu’on pouvait activer Siri ou Alexa avec des fréquences inaudibles pour l’humain. Plus récemment, l’injection de prompts sur les chatbots web a permis de détourner des modèles de langage.

Mais le texte invisible présente plusieurs avantages pour l’attaquant :

• Discrétion : aucune onde sonore, aucun fichier suspect. Le texte est affiché par une application banale.
• Pas de matériel spécifique : un simple téléphone Android suffit.
• Exploitation de la confiance visuelle : les modèles de vision sont entraînés à lire tout ce qui est à l’écran, sans notion de « légitimité » du contenu.
• Propagation multi-appareils : via ADB, l’attaque saute du mobile au PC, ce qui était absent des précédents vecteurs.

La nouveauté réside aussi dans la chaîne complète : camouflage visuel + injection de commande + exécution distante. Les attaques audio ne pouvaient pas, par exemple, lancer une commande shell sur un ordinateur connecté.

En août 2026, la menace s’est encore élargie. Des chercheurs ont montré que des instructions chiffrées peuvent tromper des assistants IA comme Grok et Gemini, rendant la détection encore plus difficile. Parallèlement, des outils comme Panda (présenté par Korben) démontrent qu’une IA peut prendre le contrôle total d’un Android, et une IA a même débusqué deux failles critiques dans Android 17 permettant de prendre le contrôle complet d’un smartphone. La surface d’attaque ne cesse de croître.

Plus récemment encore, fin août 2026, une faille dans l’API d’Ollama a été mise en lumière : NemoClaw et OpenClaw, deux frameworks d’agents IA, seraient vulnérables à un empoisonnement persistant des modèles via une erreur de conception dans la communication réseau. Si les détails restent à confirmer officiellement (le CVE-2026-65105 circule sur LinkedIn sans validation NVD/MITRE/NVIDIA), le schéma est identique : l’architecture des agents ouvre des portes que les développeurs n’avaient pas anticipées.

Benchmarks aveugles : pourquoi les tests de sécurité actuels ne voient pas la menace

Les benchmarks standards de sécurité pour les modèles de langage – AdvBench, SafetyBench – ne couvrent pas les agents mobiles ni les attaques adversariales visuelles. Ils testent la résistance à des prompts malveillants textuels, pas à des images contenant du texte invisible. De même, les frameworks d’agents Android n’ont pas de score de robustesse public.

Conséquence : cette vulnérabilité est passée inaperçue jusqu’à l’étude de juillet 2026. Aucun des cinq frameworks n’avait été audité sous cet angle. Les modèles de vision, eux, sont évalués sur des tâches de compréhension d’image (répondre à des questions, décrire une scène), mais jamais sur leur capacité à ignorer un texte anormalement peu contrasté.

Cette lacune est d’autant plus préoccupante que l’écosystème agentique, lui, explose. Selon le Work Trend Index 2026 de Microsoft, les agents IA actifs dans l’écosystème Microsoft 365 ont crû d’un facteur 15× en un an, et même 18× dans les grandes entreprises. McKinsey, dans son State of AI 2026, relève que 40 % des grandes entreprises (plus d’un milliard de dollars de chiffre d’affaires) passent à l’échelle sur les agents, contre 27 % un an plus tôt. Autrement dit : on déploie massivement des agents dont la robustesse n’est pas mesurée. Le décalage entre l’adoption et l’audit de sécurité est le vrai sujet.

L’écosystème open source en octobre 2026 : des modèles toujours plus forts, des agents toujours plus exposés

La faille des agents Android ne se lit pas dans le vide. Elle contraste violemment avec l’accélération de l’écosystème LLM open source, où les sorties s’enchaînent à un rythme effréné — et où les capacités agentiques sont précisément devenues l’argument de vente numéro un.

Mistral Large 4, dit « Le Chonk ». Le 6 octobre 2026, Mistral AI a dévoilé Mistral Large 4, un modèle de frontière à plus de 1 000 milliards de paramètres dont environ 49 milliards activés par réponse, multimodal et doté de capacités agentiques revendiquées. L’aperçu public a été ouvert le 6 octobre, les poids étant annoncés pour le 27 octobre sur Hugging Face. Mistral le présente comme le meilleur modèle à poids ouverts hors de Chine, avec un positionnement explicite sur la cybersécurité — un écho direct aux préoccupations soulevées par les agents vulnérables. Comme le résume ZDNET, les modèles ouverts cherchent à devenir la solution de défense « de monsieur Tout-le-monde » face à une prolifération de brèches agentiques.

Reflection Beam. Le 5 octobre 2026, Reflection AI — soutenue par Nvidia — a levé le voile sur Beam, son premier modèle à poids ouverts : un système Mixture-of-Experts de 501 milliards de paramètres (23 milliards actifs), taillé pour le code et le raisonnement. Son argument : rivaliser avec les meilleurs modèles chinois en consommant 3 à 4× moins de calcul d’inférence. Les poids sont attendus plus tard dans le mois. Là encore, la cible est explicitement l’entreprise et les nations souveraines, avec la promesse de « fabriques d’IA » locales.

Kolibri d’Aleph Alpha. Le 3 octobre 2026, jour de la Réunification allemande, l’allemand Aleph Alpha a publié Kolibri-1 : un MoE de 78,1 milliards de paramètres (environ 3,46 milliards actifs, soit ~4,4 %), contexte jusqu’à 1 048 576 tokens, licence Apache 2.0. Un geste autant politique que technique, qui installe l’Europe dans la course aux poids ouverts.

Solar Open 2 d’Upstage. Le 23 juillet 2026, le coréen Upstage a dévoilé Solar Open 2 : 250 milliards de paramètres, 15 milliards activés, contexte d’un million de tokens, conçu spécifiquement pour les tâches d’agents. C’est peut-être le point le plus révélateur : les modèles sont désormais vendus pour piloter des agents, alors que les frameworks d’agents eux-mêmes restent, comme le montre l’étude de juillet, sans garde-fous.

DeepSeek V4. Depuis le coup de force du 24 avril 2026 (V4-Pro et V4-Flash, 1,6 billion de paramètres au total, 49 milliards actifs), DeepSeek a fait passer V4-Pro en production le 12 août 2026 avec des capacités agentiques renforcées. La guerre des prix qu’il a déclenchée (−75 %) a mécaniquement poussé à l’adoption massive d’agents open source — donc à l’exposition massive à des failles comme celle décrite ici.

Le fil rouge est clair : chaque nouvelle génération de modèles open source ajoute des capacités agentiques, mais aucune ne s’accompagne d’un cadre de sécurité équivalent. Les modèles savent agir ; ils ne savent pas refuser d’agir sur un contenu non fiable.

Ce que cela change pour les praticiens

Pour les équipes qui déploient des agents Android ou des assistants multi-appareils, l’étude de juillet 2026 impose une réévaluation immédiate :

1. Ne pas exposer ADB sans sandbox. Toute commande issue d’une lecture d’écran doit être traitée comme une entrée non fiable. Le filtrage des métacaractères shell (;, &, >, |, backticks) est un minimum, pas une solution.
2. Valider l’origine du texte. Un texte à 2 % d’opacité ne devrait jamais être interprété comme une instruction. Les modèles de vision doivent être évalués sur leur capacité à ignorer le contenu anormalement peu contrasté.
3. Confirmation utilisateur sur les actions sensibles. Lancer une application, installer un paquet, ouvrir une serrure : ces actions méritent une validation explicite.
4. Suivre les benchmarks agentiques. Les scores de type APEX-Agents, Tau2/Tau3-Bench ou BFCL mesurent la performance, pas la robustesse. Aucun benchmark public ne mesure aujourd’hui la résistance aux attaques visuelles adversariales — c’est le trou dans la raquette que l’étude met au jour.

La bonne nouvelle, paradoxale, vient de l’écosystème lui-même : des modèles comme Mistral Large 4, positionné sur la cyberdéfense, ou les approches « fabriques d’IA » de Reflection, suggèrent que la sécurité des agents devient un argument commercial. Reste à savoir si les mainteneurs des cinq frameworks concernés finiront par répondre aux chercheurs — et par pousser un correctif. À ce jour, rien.

Sources

• Étude originale : arXiv 2607.00333 — « Open-Source Android AI Agents Could Let Invisible Screen Text Run Code », université Simon Fraser, université chinoise de Hong Kong, université du Shandong, laboratoire Xingtu de QAX, 1er juillet 2026 (révisée le 14 juillet 2026).
• The Hacker News — Open-Source Android AI Agents Could Let Invisible Screen Text Run Code
• Ouest-France — Des agents IA Android open source peuvent être piratés par du texte invisible à l’écran
• Korben — Mistral Large 4, le modèle à 1 000 milliards de paramètres surnommé Le Chonk
• ZDNET — Mistral’s new Le Chonk model brings AI cybersecurity to your business
• TechCrunch — Reflection debuts Beam, an open-weight AI model to rival Chinese models at lower compute cost
• Unite.AI — Reflection AI Unveils Beam, a 501B-Parameter Open-Weight Model
• Hugging Face — Aleph-Alpha/Kolibri-1-BF16
• Microsoft Work Trend Index 2026 / McKinsey State of AI 2026 — données d’adoption des agents

Article recherché et rédigé automatiquement · Magazine Electrosens