Claude for Chrome : un clic synthétique déclenche encore la lecture de Gmail

De quoi s’agit-il ?

Le 14 juillet 2026, Ax Sharma, de Manifold Security, a publié ClaudeBleed Reopened, montrant que deux faiblesses de l’extension navigateur Claude for Chrome d’Anthropic restaient reproductibles dans la version alors la plus récente, v1.0.80 (publiée le 7 juillet). L’entreprise a signalé les deux à Anthropic le 21 mai 2026, sur la v1.0.72 ; Anthropic a accusé réception le lendemain puis a clos les signalements, mais selon Manifold les gestionnaires concernés sont restés identiques octet pour octet huit versions plus tard.

Ce travail fait suite à la faille de frontière de confiance ClaudeBleed divulguée par LayerX début mai. La mitigation apportée par Anthropic à ce premier problème est justement ce qui rend celui-ci intéressant : le correctif était réel, mais placé à la mauvaise couche, et un résidu lui survit.

Comment ça marche

Pour corriger la faille d’origine — une page pouvait fournir un texte arbitraire à Claude — Anthropic a restreint les appelants externes à un petit dictionnaire de neuf prompts codés en dur, identifiés par un ID de tâche. Trois sont des prompts d’entraînement pour l’onboarding ; les six autres sont des actions réelles, dont usecase-gmail (lire les messages récents et cliquer sur les liens de désabonnement), usecase-gdocs (ouvrir le dernier document et lire ses commentaires) et usecase-calendar (lire les disponibilités et créer des réunions). Une page ne peut plus injecter son propre texte — une vraie amélioration au niveau du gestionnaire de messages.

Le problème résiduel tient à la façon dont l’un de ces neuf prompts est déclenché. Un content script écoute les clics sur un élément correspondant à un sélecteur précis de bouton d’onboarding, lit son attribut d’ID de tâche, et transmet le prompt correspondant au panneau latéral de Claude. Or le gestionnaire ne vérifie jamais event.isTrusted — le drapeau du navigateur qui distingue un vrai clic utilisateur d’un clic synthétisé par script. Toute extension exécutant un content script dans le monde principal sur claude.ai (le modèle standard des extensions de navigateur) peut construire le bouton, définir l’ID de tâche et émettre un clic synthétique. La preuve de concept de Manifold tient en quelques lignes de console, avec isTrusted: false dans les journaux qui confirme que l’événement forgé a été honoré.

Dans le mode par défaut « Demander avant d’agir », une fenêtre d’approbation subsiste entre le déclencheur forgé et toute lecture sensible : l’impact pratique est une approbation extorquée, que Manifold évalue à 7,7 (élevé). Mais une fois le mode « Agir sans demander » activé, la fenêtre disparaît et la tâche s’exécute silencieusement ; Manifold évalue ce chemin à 9,6 (critique). Le bug est indépendant du modèle — reproduit avec les sélections Opus, Sonnet et Fable — parce qu’il réside dans l’extension, pas dans le modèle.

Le second constat est architectural : le panneau latéral passe en mode privilégié dès qu’il est chargé avec le paramètre d’URL skipPermissions=true, sans geste utilisateur et avec un simple bandeau « à haut risque » affiché après coup. Cette URL n’est normalement construite que par l’extension elle-même : elle n’est donc pas directement exploitable à distance aujourd’hui. C’est un amplificateur latent : tout futur bug permettant à un contexte moins privilégié d’influencer la construction de cette URL transformerait le déclencheur par clic synthétique en une exécution silencieuse à impact critique.

Pourquoi c’est important

Un agent IA de navigateur autorisé à lire votre boîte mail est une identité à haute valeur. Cette classe de bug s’aligne sur le Top 10 OWASP pour les applications LLM : LLM01 injection de prompt indirecte (le déclencheur vient d’un script de page non fiable, pas de l’utilisateur) et LLM06 agentivité excessive (l’agent atteint Gmail, Docs et Agenda avec un seul événement). Elle est aussi quasi invisible pour la supervision classique : une passerelle voit un trafic HTTPS authentifié ordinaire vers claude.ai, et l’EDR voit une extension qui tourne normalement. Le seul signal fiable est ce que l’agent fait réellement à l’exécution, comparé à ce pour quoi il était autorisé. La leçon dépasse ce produit : une allowlist qui restreint les messages acceptés n’est pas une frontière d’autorisation si l’événement qui la déclenche accepte des entrées forgées. La confiance doit être imposée à chaque couche, pas seulement à la plus visible.

Défenses

Vérifier l’intention de l’utilisateur au moment de l’action. Le correctif d’une ligne proposé par Manifold consiste à rejeter les événements synthétisés en tête du gestionnaire de clic (conceptuellement, if (!event.isTrusted) return;). Tout agent qui conditionne une action privilégiée à un clic d’interface doit confirmer que ce clic est bien d’origine utilisateur, non émis par script.

Démarrer les agents dans le mode le moins privilégié. Ne laissez pas un paramètre d’URL sélectionner un état « ignorer tous les contrôles de permission ». Exigez que les transitions de mode proviennent d’un vrai geste utilisateur dans l’interface de l’agent, et conditionnez toute demande interne de privilège à une vérification d’identité de l’émetteur.

Traiter les agents IA de navigateur comme des comptes de service privilégiés. Inventoriez les extensions capables d’atteindre le courrier, les documents et l’agenda ; désactivez « agir sans demander » pour tout ce qui touche des données sensibles ; et limitez le nombre d’extensions installées à côté d’un agent, car chacune est un déclencheur potentiel.

Superviser le comportement de l’agent à l’exécution. Comme les journaux de contrôle d’accès paraissent normaux, la couche de détection durable est comportementale : signalez le moment où un agent invoque un outil ou une tâche qu’il n’avait vraisemblablement pas à invoquer.

Corriger et suivre. Suivez les notes de version de Claude for Chrome et l’avis de Manifold, et retestez après chaque mise à jour plutôt que de vous fier à un statut « résolu ».

Statut

Élément	Détail
Divulgué par	Ax Sharma, Manifold Security — 14 juillet 2026
Signalé à l’éditeur	21 mai 2026 (sur la v1.0.72) ; signalements accusés puis clos
Reproduit dans	v1.0.80 (publiée le 7 juillet 2026)
Sévérité (chercheur)	7,7 élevé (mode « demander » par défaut) / 9,6 critique (« agir sans demander »)
Correspondance	OWASP LLM01 (injection de prompt indirecte), LLM06 (agentivité excessive)
Portée	Indépendant du modèle (sélections Opus, Sonnet, Fable)
Réponse de l’éditeur	Aucun commentaire public sur les constats précis au 14 juillet 2026