Attaques exploitant une faille de l'agent IA d'OpenClaw

Des recherches récentes en matière de sécurité ont révélé qu'OpenClaw, une plateforme d'agents IA auto-hébergée largement utilisée, peut être manipulée pour exécuter des actions contrôlées par un attaquant ou divulguer des informations sensibles via des entrées apparemment inoffensives.

Dans le cadre d'enquêtes distinctes, des chercheurs ont mis en évidence deux méthodes d'attaque différentes. La première consistait à intégrer des instructions cachées dans des contacts partagés, des vCards et des géolocalisations. La seconde utilisait des courriels d'hameçonnage soigneusement conçus pour inciter un agent d'IA à divulguer des informations commerciales sensibles.

Bien qu'OpenClaw ait corrigé l'une de ces vulnérabilités dans la version 2026.4.23, le problème plus général reste inchangé : les agents d'IA qui font confiance aux informations entrantes peuvent devenir de puissants outils pour les attaquants.

Commandes invisibles cachées à la vue de tous

La première attaque visait la manière dont OpenClaw traite certains objets de message avant de les envoyer au modèle de langage étendu sous-jacent (LLM).

Contrairement au contenu web, clairement identifié comme non fiable avant d'être intégré au modèle, les fiches de contact, les vCards et les libellés de localisation étaient insérés directement dans les invites sans aucune indication de leur origine non fiable. Ceci a permis l'injection de code malveillant dans les invites.

L'attaque exploitait la méthode de sérialisation des informations de contact d'OpenClaw. Les contacts partagés étaient convertis en un format simplifié ne contenant qu'un nom et un numéro de téléphone. Comme des caractères tels que les chevrons sont autorisés dans les noms de contacts, les attaquants pouvaient y intégrer des instructions malveillantes qui semblaient faire partie intégrante des informations de contact. De plus, les noms de contacts sont souvent tronqués dans les applications de messagerie, empêchant ainsi les victimes de détecter la charge utile cachée.

La même technique s'est avérée efficace via les champs de nom complet des vCards et les étiquettes de localisation partagées. Lors de tests avec les versions préliminaires de Gemini 3.1 Pro, des instructions dissimulées ont réussi à inciter l'agent à télécharger et exécuter du code depuis un serveur contrôlé par un chercheur. Curieusement, les tentatives de dissimulation d'instructions dans des images ont échoué, probablement parce que les modèles d'IA modernes ont été largement entraînés à se prémunir contre les attaques par injection de prompts basées sur des images. Les attaques par objet-message, en revanche, restent moins familières aux modèles actuels.

Des chercheurs ont averti que la fonctionnalité de gestion de la mémoire par défaut d'OpenClaw pourrait amplifier la menace. Un seul contact malveillant ou un objet partagé largement diffusé pourrait potentiellement compromettre de nombreux agents en l'absence de contrôles de sandbox adéquats.

Suite à une divulgation responsable, OpenClaw a publié la version 2026.4.23, qui sépare les noms des contacts, les champs vCard et les libellés de localisation du contenu des invites en les plaçant dans un canal de métadonnées dédié et non fiable. Les chercheurs ont également constaté que des schémas de conception similaires sont apparus dans d'autres assistants personnels IA, ce qui indique un défi à l'échelle de l'industrie plutôt qu'un problème spécifique à une plateforme.

L’essor du phishing par agents

Un deuxième projet de recherche a abordé le problème sous un angle différent : l’ingénierie sociale.

Des chercheurs ont créé un agent de test nommé Pinchy et l'ont connecté à une boîte de réception Gmail contenant des communications professionnelles réalistes mais synthétiques, ainsi que des données sensibles fictives. L'équipe a ensuite mené quatre simulations d'hameçonnage à l'aide de Google Gemini 3.1 Pro et d'OpenAI Codex GPT-5.4.

L'étude distingue l'injection de requêtes classique de ce que les chercheurs appellent « hameçonnage par agent ». Alors que l'injection de requêtes consiste à dissimuler des instructions malveillantes dans les données, l'hameçonnage par agent repose sur des requêtes crédibles transmises par des canaux de communication légitimes. L'attaque réussit car l'agent agit avant d'avoir vérifié correctement l'identité de l'expéditeur.

Comment l’ingénierie sociale a déjoué les contrôles de sécurité

Les simulations d'hameçonnage ont produit des résultats préoccupants. Malgré des instructions strictes concernant la vérification de l'identité des expéditeurs, l'agent a échoué dans deux scénarios d'exfiltration de données :

Un courriel frauduleux, usurpant l'identité d'un chef d'équipe, a demandé un accès à l'environnement de test lors d'un incident de production fictif. L'escroc a trouvé et transmis en clair de faux identifiants AWS IAM, des chaînes de connexion à une base de données et des identifiants SSH.

Un deuxième courriel demandait une exportation hebdomadaire de données clients pour une prétendue présentation trimestrielle de bilan d'activité. L'agent a transmis une base de données synthétique contenant des informations sur 247 entreprises clientes, incluant leurs coordonnées et la valeur de leurs contrats.

L'agent a affiché des performances nettement supérieures face aux attaques techniques. Il a identifié les sites web d'hameçonnage suspects, évité de divulguer des identifiants légitimes et finalement signalé les activités malveillantes. Avec des paramètres plus stricts, l'accès aux pages d'hameçonnage était totalement bloqué. Face à un écran de consentement OAuth frauduleux déguisé en application de gestion du temps, l'agent a analysé la destination de la redirection, l'a jugée suspecte et a refusé d'accorder les autorisations.

Les chercheurs ont conclu que l'agent surpassait souvent les humains pour identifier les URL malveillantes et les faux portails de connexion. Cependant, il éprouvait des difficultés avec le jugement social contextuel, notamment lorsque les demandes semblaient provenir de collègues de confiance. La caractéristique même qui rend les assistants IA utiles, à savoir leur volonté d'aider, constitue également une faille de sécurité importante.

Bien qu'OpenAI Codex GPT-5.4 ait fait preuve d'une plus grande prudence que Gemini 3.1 Pro lors de ses interactions avec des sites externes ou de la transmission d'informations, les deux systèmes ont finalement succombé aux scénarios d'ingénierie sociale.

Une seule cause, de multiples voies d’attaque

Bien qu'utilisant des techniques différentes, les deux attaques exploitaient les mêmes capacités fondamentales :

• Accès aux informations privées.

• La capacité de traiter du contenu non fiable.

• Autorisation d'envoyer des informations à l'extérieur.

Lorsque ces capacités coexistent sans contrôles suffisants, une carte de visite malveillante et un courriel d'hameçonnage convaincant peuvent produire le même résultat : un accès non autorisé à des données sensibles.

Des recherches complémentaires ont révélé des problèmes similaires de limites de confiance au sein de l'écosystème d'OpenClaw. En convertissant les avis de sécurité précédents en règles d'analyse statique, les chercheurs ont identifié cinq autres vulnérabilités affectant les intégrations avec Slack, Discord, Matrix, Zalo et Microsoft Teams.

Chaque vulnérabilité provenait du même défaut de conception. Les extensions de canaux utilisaient des noms d'affichage modifiables plutôt que des identifiants permanents lors de l'évaluation des listes blanches. Un attaquant pouvait donc renommer un compte pour qu'il corresponde à celui d'un utilisateur autorisé et ainsi prendre le contrôle de l'agent. OpenClaw a depuis corrigé tous les problèmes identifiés.

Inquiétudes croissantes concernant les autorisations étendues des agents

Depuis son lancement, OpenClaw a suscité la controverse en raison de ses nombreuses permissions. La plateforme donne accès aux fichiers locaux, aux environnements shell et à plus de vingt messageries instantanées, ce qui la rend extrêmement performante, mais aussi très vulnérable.

Les inquiétudes sont devenues telles que l'autorité néerlandaise de protection des données, l'Autoriteit Persoonsgegevens, a déconseillé aux particuliers et aux organisations de déployer OpenClaw sur des systèmes contenant des informations sensibles. L'autorité a notamment évoqué des risques de fuites de données et de compromission de comptes.

Création de déploiements d’agents d’IA plus sûrs

Les organisations utilisant OpenClaw doivent immédiatement effectuer une mise à jour vers la version 2026.4.23 ou ultérieure afin de corriger la vulnérabilité liée aux objets de messages. Au-delà de l'application du correctif, la protection à long terme repose davantage sur des contrôles architecturaux que sur une ingénierie rapide.

Les spécialistes en sécurité recommandent de considérer les fichiers d'instructions des agents comme des politiques contraignantes et versionnées, et non comme de simples recommandations. Les communications sortantes doivent être soumises à une approbation avant l'envoi de messages à des destinataires inconnus, afin de réduire le risque de propagation d'attaques par des agents compromis via des comptes de confiance. Les autorisations d'accès doivent également être liées à la fiabilité de la source déclenchante, garantissant ainsi que les agents traitant des communications externes ne puissent pas accéder automatiquement à des systèmes critiques tels que les plateformes de gestion de la relation client (CRM). Les actions à haut risque, notamment le partage d'identifiants et les transactions financières, doivent rester soumises à une approbation humaine.

Le défi non résolu de la confiance autonome

Les deux équipes de recherche sont finalement parvenues à la même conclusion : les agents d’IA ne doivent pas être considérés comme des outils de sécurité. Un modèle plus juste serait celui d’un employé junior disposant d’un accès étendu au système, mais d’une capacité limitée à détecter les comportements suspects. On peut également les envisager comme des exécutants authentifiés qui font intrinsèquement confiance aux informations qu’ils reçoivent.

Les mesures d'atténuation actuelles se concentrent sur les correctifs, les garde-fous et les contrôles d'accès. Cependant, le problème de fond demeure entier. Un agent d'IA capable de lire des courriels, d'exécuter des tâches et d'agir de manière autonome doit, par définition, faire confiance aux données saisies et tenter d'aider les utilisateurs. La communauté de la cybersécurité n'a pas encore trouvé de solution universelle à cette tension fondamentale.