Aller au contenu principal

ClaudeBleed rouvert — quand « résolu » ne veut pas dire corrigé

Avancé
What you'll learn
  • Comprendre les deux contournements dans Claude for Chrome — un contrôle event.isTrusted manquant et un paramètre d'URL qui auto-élève le panneau latéral
  • Voir pourquoi le fait qu'Anthropic ait marqué le ticket « Résolu » avant le 9 juin, puis ait publié huit versions supplémentaires (v1.0.73 → v1.0.80) sans changement, est la vraie histoire ici
  • Apprendre le modèle défensif général : les allowlists côté client uniquement ne constituent pas une frontière de sécurité quand une autre extension partage votre origine
  • Appliquer trois mesures d'atténuation concrètes en moins de deux minutes dès maintenant

Le 7 juillet 2026, Anthropic a publié Claude for Chrome v1.0.80. Manifold Security l'a testé le jour même et a constaté que leurs deux rapports de bugs de mai étaient toujours reproductibles octet par octet depuis la v1.0.72. Toute autre extension de votre navigateur disposant d'un accès script sur claude.ai — une permission demandée par des milliers d'extensions Chrome — peut silencieusement demander à Claude d'ouvrir Gmail, de lire un message et d'agir en conséquence. Aucun dialogue d'approbation. Aucun geste de l'utilisateur.

L'histoire n'est pas « une extension avait un bug ». Les extensions Chrome publient des bugs en permanence. L'histoire, c'est qu'un produit de navigateur agentique déjà en production, après neuf mois de scrutin et un incident public « ClaudeBleed » derrière lui, applique encore son modèle de permissions à un endroit qu'un attaquant contrôle totalement — le client — et marque le ticket de suivi Résolu sans que le code n'ait changé.

Les deux failles en une seule image​

Deux bugs indépendants. L'un ou l'autre à lui seul suffit à déclencher toutes les tâches en dur. Ensemble, l'un vous donne le déclencheur (faux clic) et l'autre vous donne l'exécution silencieuse (auto-élévation).

Faille n°1 — le contrôle isTrusted manquant​

Chaque événement qu'un navigateur envoie possède un booléen isTrusted. Les vraies actions utilisateur — un clic physique, une frappe au clavier, un toucher — arrivent avec isTrusted: true. Tout ce que JavaScript synthétise via dispatchEvent(new MouseEvent(...)) arrive avec isTrusted: false. C'est le seul signal fiable du navigateur pour distinguer l'utilisateur du code, et il existe précisément pour que les gestionnaires sensibles à la sécurité puissent les différencier.

Le script de contenu de Claude for Chrome écoute les clics sur l'élément d'id #claude-onboarding-button et, si le clic correspond à l'un des neuf ID de tâches autorisés (usecase-gmail, usecase-gdocs, usecase-calendar, usecase-salesforce, plus DoorDash, Zillow et trois défis d'onboarding), transmet le prompt correspondant au panneau latéral de Claude pour exécution.

Le gestionnaire ne vérifie jamais event.isTrusted. Selon les mots des chercheurs : du point de vue de l'extension, un faux clic et un vrai clic sont indiscernables.

Cela compte à cause d'un point architectural facile à manquer : toute autre extension Chrome que vous avez installée avec des content_scripts correspondant à https://claude.ai/* partage l'origine de Claude du point de vue de Chrome, et peut injecter un script dans la page. Cette permission n'a rien d'exotique — gestionnaires de mots de passe, découpeurs de notes, outils de traduction, bloqueurs de publicité et d'innombrables extensions de « productivité » la demandent par principe. Une fois qu'un script tourne dans cette page, dispatcher un clic synthétique sur #claude-onboarding-button représente environ six lignes de code. Le rapport de Manifold rappelle précisément cette taille pour souligner un point : le correctif tient en une instruction if, et l'exploit en un seul appel dispatch.

L'allowlist de neuf prompts était l'atténuation précédente d'Anthropic pour ClaudeBleed — l'idée étant « même si un clic est falsifié, seule une liste fixe de tâches sûres peut s'exécuter ». Ce modèle s'effondre dès que « exécuter l'intégration Gmail » figure sur la liste. Lire Gmail et agir en son nom n'est pas une tâche sûre.

Pro tip
  • La leçon n'est pas « ajoutez isTrusted » — c'est la leçon en dessous : une allowlist de tâches d'agent « sûres » n'est aussi sûre que la tâche la moins sûre qui y figure. Un consentement utilisateur fin, par intégration, doit accompagner chacun de ces déclencheurs, pas seulement les déclencheurs libres non fiables.

Faille n°2 — ?skipPermissions=true dans l'URL du panneau​

Les panneaux latéraux d'extension Chrome ont leur propre URL, et la chaîne de requête de cette URL est lisible dans le panneau via window.location.search. Le panneau latéral de Claude lit un paramètre skipPermissions. S'il vaut "true", le panneau s'initialise avec permissionMode = "skip_all_permission_checks" — le même mode interne que lorsqu'un utilisateur active manuellement Agir sans demander.

C'est une escalade de privilèges côté client, en libre-service. Le panneau se demande à lui-même la permission et se répond oui sur la base d'une valeur que le panneau lui-même a reçue dans son URL — que tout ce qui peut faire chrome.sidePanel.open({...}) ou naviguer sur le panneau peut fournir.

Manifold classe ce scénario CVSS 9,6 Critique, car dans ce mode il n'y a aucune boîte d'approbation : les neuf prompts autorisés s'exécutent silencieusement. La faille du clic synthétique seule (avec la boîte d'approbation normale encore visible) est classée 7,7 Élevée, car un utilisateur pourrait en principe remarquer le dialogue avant d'appuyer sur Entrée.

La bonne forme du correctif n'est pas « assainir le paramètre d'URL ». C'est que les transitions entre modes de permission devraient exiger un geste utilisateur explicite et isTrusted sur un vrai contrôle d'interface après le chargement du panneau — jamais une valeur que le panneau lit dans sa propre URL, son propre stockage ou un canal de messages sur lequel une autre extension peut publier. C'est la même contrainte architecturale que les navigateurs appliquent déjà aux permissions plein écran, caméra et presse-papiers, et pour la même raison.

Pourquoi « Résolu » ≠ corrigé — l'échec de processus​

La chronologie est ce qui fait de cela une histoire de gouvernance, et pas seulement une histoire de code :

Guided walkthrough1 of 5
  1. Deux rapports de bugs distincts déposés chez Anthropic contre la v1.0.72.

Deux modes d'échec à intérioriser, car ils sont fréquents hors de cette histoire :

  1. Effondrement d'atténuation. Une atténuation qui change la forme d'un exploit (« il faut maintenant cliquer sur l'un des neuf boutons ») est traitée comme un correctif. Quand le déclencheur de ces boutons est lui-même falsifiable, l'atténuation n'ajoute aucune sécurité — elle ne fait que modifier la recette de l'attaque.
  2. Dérive du « résolu par conception ». Le bug n°2 a été clos sur la théorie que seule l'extension elle-même définit skipPermissions. C'est une description de l'intention, pas de l'application réelle par le navigateur. Tout ce qui a accès à sidePanel ou une redirection via l'URL du panneau peut aussi le définir.

Les deux motifs figurent sur les listes d'anti-patterns de revue de sécurité pour une raison. Guettez-les dans votre propre code.

Ce qui s'exécute, et à quelles données cela peut accéder​

Les neuf ID de tâches en dur, d'après le rapport de Manifold :

CatégorieID de tâchesCe que le prompt demande à peu près à Claude de faire
Googleusecase-gmail, usecase-gdocs, usecase-calendarLire Gmail (y compris un flux « se désabonner des e-mails promotionnels » qui itère sur la boîte de réception), lire les commentaires Google Docs, lire les disponibilités Calendar et créer des réunions
CRM / commerceusecase-salesforce, usecase-doordash, usecase-zillowLire les leads Salesforce et les convertir en opportunités ; parcourir les flux DoorDash / Zillow
Onboardingtrois défis d'onboardingPrompts de visite guidée

La portée dépend des connecteurs que la victime a activés. Si Gmail est connecté, usecase-gmail lit Gmail. Si Salesforce est connecté, usecase-salesforce touche le CRM. Le panneau fait ce qu'un utilisateur lui a demandé de faire — juste pas cet utilisateur, et pas maintenant.

Watch out
  • « Agir sans demander » n'est pas un mode développeur spécial. C'est une case à cocher dans les paramètres de Claude for Chrome. Si elle est activée, la faille n°1 seule déclenche de vraies lectures Gmail / Docs / Calendar / Salesforce. Si elle est désactivée, la faille n°2 (?skipPermissions=true) peut la réactiver silencieusement pour la durée de vie du panneau.

Trois choses à faire maintenant (deux minutes)​

Guided walkthrough1 of 3
  1. Paramètres Claude for Chrome → désactivez « Agir sans demander ». Les invites d'approbation sont pénibles, mais elles sont le seul signal visible pour l'utilisateur que la faille n°1 seule vous laisse.

Si vous gérez des extensions agentiques pour toute une équipe, ajoutez un quatrième point : observation en temps réel de ce que les agents exécutent réellement — pas seulement des permissions qu'ils détiennent. Les deux failles passent un audit de permissions et échouent à une observation comportementale, parce qu'elles amènent l'agent à faire des choses que l'utilisateur n'a jamais demandées. C'est dans cet écart que se situe la propre recommandation de Manifold, et elle se généralise bien au-delà de ce seul produit.

Prompt d'audit d'extensions Chrome pour Claude

Here is my current chrome://extensions export (or a list I'll paste): {LIST}.

For each extension:
1. Is its "site access" set to "All sites" or does it match claude.ai? Flag those.
2. From its Chrome Web Store description, what content_scripts permissions does it plausibly require? Is claude.ai a required domain for its stated function?
3. Rate each on a "trust to run a script inside my Claude tab" scale from 1 (dedicated password manager from a known vendor) to 5 (random productivity extension with <10k installs).
4. Give me a two-column recommendation: KEEP AS-IS / RESTRICT TO SPECIFIC SITES / REMOVE — with a one-line reason per row.

Do not soften. If something looks sketchy, say sketchy.

Le motif plus large — allowlists côté client uniquement, portée agentique​

Prenez du recul par rapport à Claude for Chrome. La même forme apparaît dans un nombre croissant de produits agentiques :

  • Une UI de confiance (extension, application de bureau, plugin d'IDE) expose un agent qui peut effectuer de vraies actions sur les données utilisateur.
  • Pour limiter le risque, le fournisseur ajoute une allowlist de tâches/prompts/outils que l'agent peut exécuter sans approbation.
  • Le déclencheur des entrées de l'allowlist reste à l'intérieur du client — un clic, une URL, un paramètre stocké, un message sur un canal partagé par d'autres composants.
  • Tout autre code dans la même zone de confiance (même hôte d'extension, même origine, même bus IPC) peut falsifier le déclencheur.

La leçon que chaque tour enseigne est la même. Cf. également docs/security/agentic-browsers-same-origin.mdx (l'agent lit au-dessus de la SOP), docs/security/coding-agents-under-attack.mdx (l'auto-approbation est la nouvelle surface d'attaque) et docs/security/prompt-injection.mdx (un contenu non fiable devient des instructions non fiables). Chacun de ces cas illustre une frontière tracée là où l'attaquant se tient déjà.

Deux invariants à écrire sur un post-it :

  1. Un contrôle de permission que l'attaquant peut appeler n'est pas un contrôle de permission. Si « n'importe quel script sur cette page », « n'importe quel paramètre d'URL », « n'importe quelle valeur de stockage » ou « n'importe quel postMessage d'origine inconnue » peut faire basculer votre agent de demander à agir, ce basculement doit se trouver derrière un geste isTrusted sur un vrai élément DOM que vous avez rendu.
  2. Les allowlists ne sont pas un substitut au consentement. Si une seule tâche de la liste surprendrait l'utilisateur si elle était exécutée sans invite (lire mon Gmail en fait partie), l'allowlist réduit le choix de l'attaquant mais pas son impact.

Vérification rapide​

Check yourself

0/4
  1. Dans Claude for Chrome v1.0.80, pourquoi une extension Chrome ordinaire disposant d'un accès script à claude.ai suffit-elle à déclencher les neuf tâches autorisées ?
  2. Quel est le mécanisme réel du contournement ?skipPermissions=true ?
  3. Anthropic a marqué le ticket sous-jacent « Résolu » avant le 9 juin 2026, or la v1.0.80 (7 juillet) est identique octet pour octet à la v1.0.72. Quel mode d'échec cela illustre-t-il le mieux ?
  4. Laquelle de ces mesures est la plus forte, appliquée seule, qu'un utilisateur de Claude for Chrome peut mettre en œuvre dès maintenant ?
Key takeaways
  • La v1.0.80 de Claude for Chrome (7 juillet 2026) reste vulnérable aux deux bugs de Manifold initialement signalés sur la v1.0.72 en mai — contournement par clic synthétique de l'allowlist de neuf prompts, et auto-élévation via ?skipPermissions=true dans l'URL du panneau.
  • Les deux bugs sont des contrôles de permission côté client uniquement. « Résolu » dans le ticket faisait référence à une atténuation (l'allowlist), pas aux lacunes d'application sous-jacentes.
  • Dès maintenant : désactivez Agir sans demander, auditez quelles autres extensions Chrome peuvent injecter des scripts dans claude.ai, et déconnectez les connecteurs que vous n'utilisez pas.
  • Règle générale : un contrôle de permission que n'importe quel script sur la page peut appeler n'est pas un contrôle de permission. Les transitions de mode doivent reposer sur un geste isTrusted sur un vrai élément d'interface, pas sur une valeur d'URL / de stockage / de message.

Sources et lectures complémentaires​