ClaudeBleed : quand un agent navigateur fait confiance à la mauvaise extension

De quoi s’agit-il ?

ClaudeBleed est le nom donné par LayerX Security à une vulnérabilité de frontière de confiance dans l’extension de navigateur Claude in Chrome. LayerX l’a divulguée à Anthropic le 27 avril 2026 ; Anthropic a publié la version 1.0.70 de l’extension le 6 mai 2026, et LayerX a publié son analyse la même semaine. La faille permettait à n’importe quelle autre extension Chrome — y compris une installée avec zéro permission particulière — d’envoyer des commandes à l’extension Claude et de les faire exécuter : lire l’onglet actif, naviguer à la place de l’utilisateur et atteindre des surfaces connectées comme Gmail, Google Drive et GitHub.

Il ne s’agit pas d’un jailbreak du modèle. Le modèle de langage s’est comporté exactement comme prévu. Le bug se situait dans la tuyauterie autour de l’agent : la manière dont l’extension décidait à quels messages se fier. Nous le couvrons parce qu’il illustre, de façon nette, récente et publiquement documentée, une classe de défaillance qui se reproduira dans chaque agent IA résidant dans le navigateur — et parce que le premier correctif aurait été contourné en quelques heures, ce qui constitue en soi une leçon utile.

Comment ça marche

Les extensions Chrome peuvent déclarer une clé de manifeste externally_connectable. Elle liste les origines web (et éventuellement d’autres ID d’extension) autorisées à ouvrir un canal de messages vers le service worker d’arrière-plan de l’extension. C’est un mécanisme légitime — c’est ainsi que l’application web d’un éditeur dialogue avec sa propre extension.

L’extension Claude autorisait les messages provenant de scripts s’exécutant sous l’origine claude.ai afin que l’application web Claude puisse se coordonner avec l’extension. Le défaut, tel que décrit par LayerX, est que le gestionnaire de messages faisait confiance à l’origine mais ne vérifiait jamais l’expéditeur :

Design intent:   claude.ai web app  ──(trusted channel)──▶  Claude extension
Reality:         ANY script running in a claude.ai tab  ──▶  Claude extension
                 (including code injected by a second, unrelated extension)

N’importe quelle extension peut injecter un script de contenu dans les pages que l’utilisateur visite. Un script de contenu s’exécutant dans un onglet claude.ai ouvert s’exécute sous l’origine claude.ai. Comme le gestionnaire fondait sa décision de confiance sur l’origine plutôt que sur une identité d’expéditeur authentifiée et vérifiée, un script de contenu déposé par l’Extension B était indiscernable de l’application web d’Anthropic aux yeux de l’Extension A (Claude). L’Extension B pouvait donc émettre les mêmes messages de commande que l’interface de Claude — et Claude les exécutait avec les sessions authentifiées de l’utilisateur.

L’impact rapporté découle directement de la triade létale : l’agent a accès à des données privées (les Gmail, Drive, GitHub où l’utilisateur est connecté), il peut recevoir des instructions non fiables (de l’extension qui le détourne) et il dispose d’une voie d’exfiltration (il peut naviguer et envoyer). Combinez le tout et une extension sans aucune permission peut lire des courriels, extraire le contenu de dépôts privés et faire sortir des données — sans la demande de permission qui alerterait l’utilisateur.

Aucun payload fonctionnel n’est reproduit ici. Le mécanisme — confiance fondée sur l’origine sans authentification de l’expéditeur — est tout l’enjeu, et il est déjà public.

Le premier correctif incomplet

La version 1.0.70 n’a pas supprimé le gestionnaire externally_connectable. À la place, selon LayerX et le compte-rendu de Business Standard, Anthropic a ajouté un flux d’approbation afin que les extensions opérant en mode « standard » ne puissent pas exécuter silencieusement des commandes distantes privilégiées. LayerX a rapporté que cette couche pouvait être contournée : en abusant du flux d’initialisation du panneau latéral, un attaquant pouvait créer un contexte d’exécution « privilégié » / « agir sans demander » qui échappait à la nouvelle vérification, restaurant la capacité d’origine. Cybernews a rapporté le contournement du correctif quelques heures après sa sortie. La leçon est architecturale : greffer une invite d’approbation au niveau de l’interface sur un gestionnaire dont la décision de confiance reste fondée sur l’origine ne ferme pas la frontière — cela ajoute simplement une étape à contourner.

Pourquoi c’est important

Les agents résidant dans le navigateur sont une surface de déploiement en pleine croissance, et ils concentrent précisément les actifs que recherchent les attaquants. Un navigateur connecté est un contexte unique qui contient courriels, fichiers, code source et cookies de session pour des dizaines de services. Un agent capable d’agir dans ce contexte est, par construction, une cible de grande valeur.

Trois points se généralisent au-delà de cette seule extension :

La frontière de confiance se situe entre les extensions, pas seulement entre les pages web et l’agent. La plupart des modèles de menace pour les agents navigateur se concentrent sur le contenu des pages que l’agent lit (injection de prompt indirecte). ClaudeBleed rappelle que les extensions voisines partageant le même onglet font aussi partie du modèle de menace. La vérification d’origine de externally_connectable est un instrument grossier : une origine n’est pas une identité.

Les demandes de permission ne remplacent pas une frontière correcte. L’utilisateur a installé Claude et lui a accordé un accès ; il n’a pas sciemment accordé à une seconde extension quelconque le droit de piloter Claude. Quand la frontière est mauvaise, le consentement donné à un composant s’étend silencieusement à un autre.

Les modes « agir sans demander » sont porteurs pour la sécurité, pas seulement pour le confort. La voie de contournement passait précisément par un chemin d’exécution privilégié, sans confirmation. Les réglages d’autonomie qui suppriment les invites de confirmation retirent le dernier point de contrôle humain juste au moment où un attaquant a le plus besoin qu’il soit retiré.

Défenses

Pour les utilisateurs et administrateurs d’agents IA dans le navigateur :

1. Mettez à jour immédiatement, puis restez vigilant. Assurez-vous que Claude in Chrome est dans sa dernière version (1.0.70 ou ultérieure). Le premier correctif ayant été rapporté comme contournable, considérez « corrigé » comme provisoire et suivez les versions et avis ultérieurs de l’éditeur plutôt que de supposer qu’une seule mise à jour a clos le problème.

2. Réduisez le rayon d’impact des extensions. L’attaque requiert une seconde extension dans le même profil de navigateur. Auditez les extensions installées, supprimez celles que vous n’utilisez pas activement, et préférez un profil de navigateur dédié au travail avec l’agent IA, ne contenant que l’extension de l’agent. Moins d’extensions cohabitent, plus la surface d’attaque est réduite.

3. Désactivez le mode « agir sans demander » / l’autonomie privilégiée. Faites tourner l’agent dans son mode le plus exigeant en confirmations. Exigez une approbation humaine explicite pour toute action qui lit des données privées ou émet une requête sortante. C’est le point de contrôle que le contournement était conçu pour sauter.

4. Utilisez une liste blanche d’extensions en entreprise. Les politiques Chrome Enterprise (ExtensionInstallAllowlist / ExtensionInstallBlocklist) permettent de forcer le blocage des extensions non gérées. Si seules des extensions validées peuvent être installées, la prémisse « n’importe quelle extension peut la détourner » disparaît largement pour les flottes gérées.

5. Cloisonnez les sessions sensibles à l’écart de l’agent. Ne conservez pas l’extension de l’agent dans le même profil où vous restez connecté à vos services les plus sensibles (finance, consoles d’administration, gestion de code avec des portées larges). Des profils de navigateur séparés créent une frontière dure que l’extension ne peut franchir.

Pour les développeurs d’extensions ou d’agents de navigateur :

6. Authentifiez l’expéditeur, ne faites pas confiance à l’origine. externally_connectable filtre quelles origines peuvent se connecter, mais une origine est partagée par tous les scripts de l’onglet. Si votre gestionnaire effectue des actions privilégiées, exigez un secret par session vérifié ou une poignée de main authentifiée cryptographiquement que les scripts de contenu injectés ne peuvent falsifier — pas une simple vérification de sender.origin.

7. Adoptez par défaut le moindre privilège et la confirmation explicite. Les modes d’exécution privilégiés doivent échouer en mode fermé : aucun chemin silencieux ne doit échapper au flux d’approbation. Traitez tout mode « agir sans demander » comme une fonctionnalité de sécurité et modélisez les menaces des voies qui peuvent y mener.

8. Modélisez la menace des extensions cohabitantes. Ajoutez « une extension voisine malveillante partage cet onglet » à vos hypothèses de conception. Testez avec une seconde extension délibérément hostile installée.

Statut

Élément	Référence	Date	Notes
Divulgation responsable à Anthropic	LayerX Security	2026-04-27	Faille de frontière de confiance dans Claude in Chrome
Correctif publié — extension v1.0.70	Anthropic	2026-05-06	Ajout d’un flux d’approbation ; gestionnaire externally_connectable conservé
Publication publique « ClaudeBleed »	LayerX Security	2026-05-06	Origine de confiance sans vérification de l’expéditeur
Contournement du premier correctif rapporté	Cybernews / Business Standard	~2026-05-11	Le chemin privilégié « agir sans demander » contourne la nouvelle vérification

Dates clés : divulgation le 2026-04-27, correctif le 2026-05-06, contournement rapporté les jours suivants. Le cadrage défensif est le plus durable : un agent IA dans le navigateur hérite des frontières de confiance du navigateur qui l’entoure, et une vérification d’origine n’est pas une vérification d’identité. L’autonomie privilégiée sans confirmation est l’endroit où cet écart se transforme en exfiltration de données — la mitigation la moins coûteuse aujourd’hui est donc de désactiver cette autonomie et de réduire l’ensemble des extensions partageant le profil de l’agent.

---

Cet article est éducatif et défensif. Il décrit une vulnérabilité publiquement divulguée et corrigée par l’éditeur, et ne reproduit aucun exploit fonctionnel. Les détails de comportement et de version reflètent les informations disponibles fin mai 2026 ; vérifiez auprès des avis actuels de l’éditeur.