Comment des préférences synchronisées peuvent détourner les outils locaux de Claude Desktop

De quoi s’agit-il ?

Dans des travaux publiés début juillet 2026 — repris par The Register le 1er juillet 2026 et détaillés par Pentera Labs sous le nom AI Double Agent — des red teamers ont montré que les paramètres synchronisés d’un assistant IA de bureau très répandu pouvaient être transformés en un canal d’injection de prompt persistant. La cible est le champ Préférences personnelles de l’assistant : un prompt configurable par l’utilisateur qui stocke le ton, les flux de travail et des consignes de comportement, et qui se synchronise automatiquement sur tous les appareils et sessions liés au compte, y compris l’application de bureau.

Il ne s’agit pas d’un bug de corruption mémoire ni d’une faille distante non authentifiée. C’est un problème de frontière de confiance : un élément de configuration contrôlé par le compte, que l’assistant traite comme des instructions, est aussi un endroit où un attaquant peut écrire dès lors qu’il détient le compte. Les chercheurs l’ont signalé à l’éditeur en novembre 2025. Celui-ci l’a reconnu mais a refusé de le qualifier de vulnérabilité de sécurité, estimant que les préférences, skills et connecteurs sont des fonctionnalités conçues pour laisser l’assistant agir — aucun CVE n’a donc été attribué. Ce désaccord est en soi la partie intéressante, et c’est pourquoi nous traitons ce cas comme une leçon défensive plutôt que comme un défaut à corriger.

Comment ça marche

La chaîne comporte trois étapes conceptuelles, et aucune ne nécessite de livraison de malware ni d’e-mail de phishing envoyé à la victime.

Access au compte  -> l'attaquant atteint le compte de l'assistant de la victime
Payload stocke    -> instructions ecrites dans les Preferences personnelles synchronisees
Sync + declenche  -> l'app de bureau les charge et pilote les outils locaux

Dans le scénario démontré, l’accès initial provenait d’un service tiers qui agrégeait les boîtes de réception de nombreux utilisateurs ; une authentification faible à cet endroit a permis aux chercheurs de rebondir vers les comptes associés via des liens magiques et des réinitialisations de mot de passe. Une fois le compte en main, ils ont placé un bloc d’instructions encodé dans les Préférences personnelles. Écrit sous forme de chaîne opaque plutôt que de commandes en clair, il passe facilement inaperçu lors d’une relecture rapide — l’objectif étant de se fondre dans un champ que les utilisateurs auditent rarement.

Comme le champ se synchronise, à la prochaine ouverture de l’application de bureau, le contenu injecté se charge silencieusement comme partie intégrante des consignes permanentes de l’assistant. À partir de là, la logique du payload est conditionnelle. Si une extension capable d’exécuter des commandes — les articles citent un outil local d’exécution de commandes — est déjà installée, l’assistant peut être orienté pour l’invoquer en arrière-plan tout en continuant de répondre aux questions visibles de l’utilisateur, créant une boucle où chaque interaction peut récupérer et exécuter des instructions actualisées depuis l’infrastructure de l’attaquant. Si aucun outil de ce type n’est présent, le payload bascule vers l’ingénierie sociale : il fait afficher à l’assistant une erreur réaliste, calquée sur le flux de travail, qui pousse l’utilisateur à installer une extension précise « pour résoudre le problème ». L’assistant, en qui l’utilisateur a confiance, devient la couche de phishing.

Nous ne publions volontairement ni le payload ni son encodage. Le mécanisme — une configuration stockée et synchronisée est traitée comme des instructions de confiance, et les outils connectés héritent de cette confiance — est ce qui importe ici.

Pourquoi c’est important

C’est une instance concrète de la « triade létale » : du contenu non fiable, un agent doté d’outils, et la capacité d’atteindre l’extérieur. La nouveauté tient à l’endroit où réside le contenu non fiable. La plupart des analyses sur l’injection de prompt se concentrent sur du contenu chargé à l’exécution — une page web, un document, un résultat d’outil. Ici, l’instruction malveillante est garée dans les paramètres du compte de l’utilisateur et livrée par le mécanisme de synchronisation de l’éditeur, ce qui la rend persistante et portable d’un appareil à l’autre.

Le rayon d’impact dépend de la victime. Sur une machine de développeur ou DevOps, l’exécution de commandes peut signifier la récupération de clés SSH, d’identifiants cloud, de kubeconfigs et de jetons CI/CD, et une voie de déplacement latéral vers la production. Sur un poste non technique, la même confiance peut être détournée vers le vol de session, l’extraction d’identifiants depuis le navigateur et l’usurpation d’identité sur les outils collaboratifs. Et la position de l’éditeur — selon laquelle il s’agit d’une fonctionnalité attendue — signifie que les défenseurs ne peuvent pas attendre un correctif pour refermer cette porte. Si votre modèle de menace inclut la compromission de compte, la configuration synchronisée de l’assistant fait désormais partie de votre surface d’attaque.

Défenses

Protégez d’abord le compte. Toute la chaîne commence par l’accès d’un tiers au compte de l’assistant : l’authentification multifacteur, l’examen attentif des agrégateurs de boîtes de réception tiers et des autorisations OAuth, ainsi que la surveillance des signaux de prise de contrôle de compte, sont les contrôles à plus fort effet de levier.

Traitez la configuration synchronisée comme un état non fiable et sensible pour la sécurité. Les Préférences personnelles, la mémoire, les skills et les définitions de connecteurs doivent être revus périodiquement et après toute compromission suspectée ; un bloc encodé opaque dans un champ de préférences est un signal d’alerte, pas une bizarrerie.

Limitez ce que les outils peuvent faire. Appliquez le moindre privilège aux extensions capables d’exécuter des commandes — n’installez des outils d’exécution de code local que lorsque c’est réellement nécessaire, et isolez-les. Exigez une approbation humaine explicite pour chaque action d’outil plutôt que d’autoriser une exécution silencieuse en arrière-plan, afin qu’une instruction empoisonnée ne puisse pas piloter discrètement le shell.

Partez du principe que l’assistant peut devenir une surface de phishing. Un assistant de confiance qui recommande d’installer une extension précise est désormais un vecteur : vérifiez toute demande de ce type par un canal indépendant avant d’agir.

Ajoutez de la défense en profondeur autour du poste. Restreignez le trafic sortant des postes qui exécutent des assistants outillés, maintenez un EDR en place, et pratiquez une bonne hygiène des secrets — jetons à courte durée de vie, aucune clé SSH ou identifiant cloud à longue durée stocké en clair dans les répertoires personnels.

Statut

Élément	Détail
Divulgation	Signalé à l’éditeur en novembre 2025 ; articles publics début juillet 2026 (The Register, 1er juil. 2026)
Position de l’éditeur	Préférences, skills et connecteurs MCP considérés comme des fonctionnalités conçues pour exécuter du code ; classé en fonctionnement attendu, aucun CVE attribué ; améliorations annoncées comme prévues
Prérequis	Nécessite un accès préalable au compte ; ce n’est pas une faille distante non authentifiée
Nature	Problème de frontière de confiance / injection de prompt stockée permettant l’exécution d’outils locaux et la persistance via la configuration synchronisée
État du correctif	Aucun correctif attendu par conception — la mitigation passe par la sécurité du compte, des outils à moindre privilège et l’approbation humaine