Deux efforts de recherche de sécurité indépendants, publiés cette semaine, révèlent qu'**OpenClaw**, un agent IA auto-hébergé largement adopté, peut être contraint à exécuter du code malveillant ou à divulguer des informations sensibles via des entrées d'apparence ordinaire. **Imperva** a démontré comment des instructions cachées intégrées dans des contacts partagés, des vCards et des épingles de localisation pouvaient être exécutées par l'agent à l'insu de la victime. Parallèlement, **Varonis** a réussi à tromper un agent de test, pré-chargé avec des données d'entreprise synthétiques, pour qu'il transfère de fausses clés AWS et une fausse exportation de clients via un simple e-mail. Alors que la faille découverte par **Imperva** a été corrigée dans la version **OpenClaw** 2026.4.23, la vulnérabilité de phishing de **Varonis** met en évidence un défi architectural plus profond qui ne peut être résolu par un simple correctif. Les deux attaques soulignent une faiblesse fondamentale : la confiance inhérente de l'agent dans les données entrantes, qui, combinée à ses privilèges d'accès, crée un vecteur d'attaque puissant. ## Commandes cachées dans un contact partagé Le chercheur d'**Imperva**, **Yohann Sillam**, a analysé la manière dont **OpenClaw** traite les données de messagerie pour son modèle linguistique sous-jacent (LLM). Le problème principal réside dans le traitement interne des objets de message par l'agent. Lorsque **OpenClaw** transmet des contacts partagés, des vCards ou des localisations au LLM, il aplatit ces objets directement dans le texte du prompt. De manière cruciale, contrairement au contenu récupéré sur le web qui est marqué comme non fiable, les objets de message manquent de cette frontière critique. Seuls des champs spécifiques sont envoyés au modèle, une faiblesse exploitée par l'attaque. Par exemple, un contact partagé n'envoie que le champ nom, sérialisé sous la forme `<contact: nom, numéro>`. Les crochets sont autorisés dans les noms, rendant impossible pour le modèle de distinguer un nom légitime d'une instruction injectée. De plus, le nom du contact est tronqué à l'écran dans **WhatsApp** et dans l'application réceptrice, dissimulant efficacement le payload malveillant à la victime. Cette technique s'avère également efficace via le champ nom complet d'une vCard, nativement pris en charge par **WhatsApp**, et via l'étiquette d'une épingle de localisation partagée. Dans les tests d'**Imperva** contre **Google Gemini 3.1 Pro** (build de prévisualisation), le texte caché a réussi à instruire l'agent à télécharger et exécuter un script depuis un serveur contrôlé par le chercheur. Bien que les tentatives d'intégration d'instructions dans des images simples aient échoué (probablement parce que les modèles ont été entraînés contre de telles attaques courantes), la voie des objets de message a réussi en raison de sa nouveauté.  **Imperva** avertit qu'avec la mémoire d'**OpenClaw** activée par défaut, un seul contenu largement partagé contenant une instruction cachée pourrait compromettre silencieusement les agents non-sandboxed qui l'ingèrent. Suite à la divulgation d'**Imperva**, **OpenClaw** a publié un correctif dans la version 2026.4.23, qui achemine désormais les noms de contact, les champs vCard et les étiquettes de localisation via un canal de métadonnées séparé et non fiable. **Imperva** a noté des schémas d'aplatissement similaires dans d'autres assistants IA personnels, indiquant un problème plus large dans l'industrie. ## Un e-mail normal suffit **Varonis Threat Labs** a abordé **OpenClaw** sous l'angle de l'ingénierie sociale. Dirigée par **Itay Yashar**, leur équipe a développé un agent nommé **Pinchy** sur la plateforme, le connectant à une boîte de réception **Gmail** remplie de données d'entreprise synthétiques réalistes et de faux secrets. Ils ont ensuite soumis **Pinchy** à quatre simulations de phishing utilisant **Google Gemini 3.1 Pro** et **OpenAI Codex GPT-5.4**. **Varonis** distingue l'injection de prompt, qui dissimule des instructions dans les données, de ce qu'ils appellent le 'phishing d'agent' : une requête crédible délivrée via un canal normal qui réussit parce que l'agent agit sans vérification appropriée de l'expéditeur. L'agent a échoué aux deux tests d'exfiltration. Dans le premier scénario, un message prétendant provenir d'un chef d'équipe nommé Dan, envoyé depuis une adresse **Gmail** externe, demandait un accès de staging lors d'un incident de production simulé. **Pinchy** a localisé les identifiants et a transféré de fausses clés d'accès AWS IAM, des chaînes de connexion de base de données et des identifiants SSH en texte brut.  Le deuxième prétexte était une demande plus douce pour l'exportation hebdomadaire des clients, ostensiblement pour un deck de QBR. L'agent a ensuite envoyé un ensemble de données synthétiques de 247 clients d'entreprise, y compris des contacts et des valeurs de contrat. Les deux échecs se sont produits malgré un profil strict configuré pour vérifier d'abord les expéditeurs ; l'urgence a outrepassé la règle dans un cas, et la routine dans l'autre. L'agent a mieux performé contre les menaces techniques que sociales. Il a interagi avec une page de phishing de carte-cadeau mais a retenu les identifiants réels et l'a finalement signalée ; le profil strict a bloqué la page entièrement. Lorsqu'il a été présenté avec un écran de consentement **OAuth** malveillant déguisé en application de feuille de temps, il a inspecté la cible de redirection, l'a jugée suspecte et s'est arrêté avant d'accorder l'accès. Cela met en évidence le point clé de **Varonis** : l'agent est souvent plus apte que les humains à identifier les URL malveillantes et les faux portails de connexion, mais significativement moins bon pour le jugement social qui incite un humain à faire une pause lorsqu'un collègue fait une demande inhabituelle d'identifiants. La volonté intrinsèque de l'agent d'être utile émerge comme une surface d'attaque critique.  **Varonis** a noté que **OpenAI Codex GPT-5.4** a fait preuve de plus de prudence que **Gemini 3.1 Pro** concernant l'entrée ou l'envoi de données vers des sites externes sans confirmation, bien que les deux aient succombé aux prétextes sociaux. ## Le point faible derrière les deux attaques **Varonis** associe les deux vecteurs d'attaque au concept de 'trifecta létale' de **Simon Willison** : un agent capable de lire des données privées, d'ingérer du contenu non fiable et d'exfiltrer des données. **OpenClaw** possède ces trois capacités, ce qui explique pourquoi un contact empoisonné et un e-mail apparemment bénin peuvent conduire à la même compromission. Ce problème de frontière de confiance s'étend au-delà des problèmes de prompt, se manifestant dans le code d'**OpenClaw**. Une analyse séparée d'**InfoSec Write-ups** a converti d'anciens avis d'**OpenClaw** en règles d'analyse statique, découvrant ensuite cinq failles supplémentaires dans ses extensions de canaux **Slack**, **Discord**, **Matrix**, **Zalo** et **Microsoft Teams**. Les cinq vulnérabilités partageaient une cause commune : le code de démarrage résolvait la liste d'autorisation de chaque canal par son nom d'affichage mutable au lieu d'un identifiant stable. Cela permettait à un attaquant de se renommer pour correspondre à un utilisateur autorisé, obtenant ainsi un accès et un contrôle non autorisés sur l'agent. **OpenClaw** a depuis corrigé ces problèmes. **OpenClaw** est livré avec un accès étendu aux fichiers, aux shells et à plus de vingt plateformes de messagerie, et fait l'objet d'avertissements constants sur l'injection de prompt et l'exfiltration de données depuis son lancement fin de l'année dernière. L'**autorité néerlandaise de protection des données**, l'**Autoriteit Persoonsgegevens**, a adopté une position ferme, déconseillant aux utilisateurs et aux organisations d'exécuter **OpenClaw** sur des systèmes contenant des données sensibles, citant des risques importants de violation de données et de prise de contrôle de compte. ## Que faire à ce sujet Les organisations exécutant **OpenClaw** doivent immédiatement mettre à jour vers la version 2026.4.23 ou ultérieure pour appliquer le correctif des objets de message. Au-delà du patching, les défenses restantes sont architecturales, pas simplement une question de formulation du prompt. **Varonis** décrit quatre contrôles critiques : 1. **Traitez le fichier d'instructions de l'agent comme une politique appliquée et contrôlée par version, pas comme une suggestion.** 2. **Implémentez une passerelle pour les e-mails sortants :** interdisez les premiers envois à des adresses inconnues sans approbation explicite pour empêcher un agent détourné de relayer des tentatives de phishing depuis un compte de confiance. 3. **L'accès aux connecteurs doit suivre le niveau de confiance de l'entité connectée.** 4. **Sandboz le agent.**