Injection par objets de messagerie : la faille de sérialisation des assistants IA

De quoi s’agit-il ?

Le 10 juin 2026, Imperva Threat Research (Yohann Sillam) a publié une analyse d’un vecteur de prompt injection qui ne réside ni dans un document ni dans une page web, mais dans les objets de messagerie structurés qu’un assistant IA personnel manipule au quotidien : contacts partagés, vCards (.vcf) et points de géolocalisation. L’étude visait OpenClaw, un agent auto-hébergé répandu qui relie un LLM aux systèmes de fichiers, aux shells et à des plateformes de messagerie comme WhatsApp ou Telegram. The Hacker News l’a relayé le lendemain, aux côtés de travaux parallèles de Varonis.

L’instruction injectée était invisible pour la victime, franchissait la frontière de confiance jusqu’au contexte utilisateur authentifié et — dans le laboratoire d’Imperva, face à Gemini 3.1 Pro (préversion) — a conduit l’agent à télécharger et exécuter un script depuis un serveur contrôlé par les chercheurs. Imperva a procédé à une divulgation responsable ; OpenClaw a livré un correctif en version 2026.4.23.

Comment ça marche

La faille tient à la plomberie, pas au modèle. Lorsque OpenClaw transmet du contenu web au LLM, il enveloppe ce contenu dans un marqueur de contenu non fiable. Lorsqu’il transmet un objet de messagerie — un contact, une vCard, un libellé de localisation — il l’aplatit directement dans le texte du prompt, sans aucune frontière le signalant comme non fiable.

Seuls certains champs parviennent au modèle, et c’est précisément ce que la technique exploite. Un contact partagé n’envoie que son champ nom, sérialisé sous une forme du type <contact: nom, numéro>. Les chevrons sont des caractères parfaitement légaux dans un nom : le modèle n’a donc aucun moyen fiable de savoir où finit le vrai nom et où commence le texte injecté. À l’écran, le nom du contact est tronqué : la victime ne voit pas non plus la charge utile en fin de chaîne. La même logique s’applique au champ nom complet (FN) d’une vCard, pris en charge nativement par WhatsApp, et au libellé d’un point de localisation partagé.

Fait révélateur, Imperva rapporte qu’une simple image porteuse d’instructions cachées a échoué — cette attaque a été tellement médiatisée que les modèles sont désormais entraînés à y résister. La voie des objets de messagerie a fonctionné précisément parce que les modèles en ont vu beaucoup moins d’exemples. Aucune charge utile n’est reproduite ici ; le point structurel suffit.

Le problème de fond : il n’existe aucun standard décrivant comment les objets de messagerie sont sérialisés avant d’atteindre un LLM. L’intégration d’outils dispose de MCP ; les récupérations web ont leurs marqueurs de contenu non fiable ; les objets de messagerie riches n’ont ni l’un ni l’autre. Chaque assistant les aplatit à sa façon, de manière ad hoc, et Imperva a observé le même schéma d’aplatissement dans d’autres assistants personnels — ce n’est donc pas propre à OpenClaw.

Pourquoi c’est important

Les assistants IA personnels ne sont pas des chatbots : ce sont des exécuteurs authentifiés disposant d’un accès aux fichiers, aux shells et aux comptes connectés. Une injection qui en atteint un hérite de cet accès. Deux propriétés rendent le vecteur des objets de messagerie plus redoutable qu’une injection indirecte classique. D’abord, l’invisibilité des deux côtés — ni le modèle ni l’humain ne perçoit la charge comme anormale. Ensuite, viralité et persistance : un seul contenu partagé (une carte de visite relayée des milliers de fois), combiné à la mémoire activée par défaut de l’agent, peut discrètement amorcer une compromission sur chaque assistant qui l’ingère, là où l’exécution n’est pas isolée.

C’est la triade létale sous forme concrète — accès à des données privées, exposition à du contenu non fiable et canal sortant — livrée via une couture de sérialisation que la plupart des défenseurs n’avaient jamais modélisée. Elle appartient à la même famille que l’injection indirecte observée en conditions réelles, mais par un canal que les règles d’assainissement pensées pour les documents et les URL ne couvrent tout simplement pas.

Défenses

• Marquez tout champ non fiable comme non fiable. Le correctif d’OpenClaw fait office de modèle : sortir les noms de contact, les champs de vCard et les libellés de localisation du corps inline du prompt vers un canal de métadonnées non fiables structuré, afin que le modèle les reçoive étiquetés, et non fondus dans les instructions. Appliquez-le à tous les champs d’objets de messagerie, pas seulement à ceux d’un avis donné.
• Recensez chaque couture de sérialisation. Auditez chaque chemin par lequel un objet structuré (contact, invitation d’agenda, vCard, localisation, lien enrichi) est aplati dans le prompt. Chacun est un canal d’injection jusqu’à preuve du contraire.
• Maintenez l’exécution isolée et au moindre privilège. L’exécution de code doit être désactivée ou en bac à sable par défaut ; limitez les compétences et connecteurs au strict nécessaire. Le rayon d’action de l’injection est exactement l’autorité permanente de l’agent.
• Filtrez les actions sortantes et à haut risque. Exigez une validation humaine pour tout premier envoi vers une destination inconnue et pour les actions touchant aux identifiants ou aux paiements, afin qu’un agent détourné ne puisse pas finaliser seul une étape d’exfiltration.
• Traitez la mémoire comme une surface d’attaque. Avec la persistance activée par défaut, un seul objet empoisonné peut laisser des instructions durables. Limitez ce que le contenu non fiable peut écrire en mémoire à long terme.

Statut

Élément	Détail
Divulgué	2026-06-10 (Imperva Threat Research)
Vecteur	Injection via champs d’objets de messagerie (nom de contact, FN de vCard, libellé de localisation) aplatis inline
Testé contre	OpenClaw + Gemini 3.1 Pro (préversion)
Correctif	OpenClaw 2026.4.23 — champs non fiables déplacés vers un canal de métadonnées structuré
Portée	Imperva a observé le même schéma d’aplatissement dans d’autres assistants personnels

Le correctif clôt l’instance d’OpenClaw. La classe — objets de messagerie riches sérialisés dans les prompts sans frontière de non-fiabilité — reste ouverte tant que les assistants n’auront pas adopté une manière cohérente de transporter des champs structurés et non fiables jusqu’au modèle. D’ici là, chaque nouveau type d’objet qu’un assistant apprend à ingérer est un nouveau canal d’injection à auditer.