Menu

Claude in Chrome : 6 risques à modéliser avant de déployer, et 3 incidents qui prouvent que la liste est juste

Catégories

Tags

🔍 Licence d'Utilisation 🔍

Sauf mention contraire, le contenu de ce blog est sous licence CC BY-NC-ND 4.0.

© 2025 à 2042 Sébastien Gioria. Tous droits réservés.

⏱️
Temps de lecture estimé
12 min de lecture
⏱️
Temps de lecture estimé
~11 minutes

La CSA publie une liste de 6 risques à modéliser avant de déployer Claude in Chrome en entreprise. Ce qui rend cette liste crédible, ce n’est pas sa rédaction ; ce sont les trois incidents publics qui l’ont précédée en neuf mois.

Trois incidents en neuf mois, et la même racine à chaque fois

Décembre 2025 : un chercheur de Koi Security signale à Anthropic qu’une page web quelconque peut injecter un prompt dans l’extension Claude comme si l’utilisateur l’avait tapé lui-même. Zéro clic, zéro dialogue de permission. C’est ShadowPrompt, corrigé en janvier 2026 dans la version 1.0.41.

Mai 2026 : LayerX publie ClaudeBleed. Cette fois c’est une extension Chrome sans aucune permission déclarée qui pilote Claude, lit Gmail, exfiltre du code depuis un dépôt GitHub privé et partage des fichiers Drive. Anthropic corrige partiellement en 1.0.70 ; LayerX contourne le correctif en basculant l’extension en mode privilégié, ce qui ne déclenche ni notification ni approbation.

Août 2026 : Zenity présente PleaseFix, une classe d’exploitation zéro clic qui touche cinq navigateurs agentiques. Contre Claude in Chrome, une seule demande de résumé de boîte mail suffit à exfiltrer Gmail, partager le Drive de la victime et prendre le contrôle de ses comptes Slack et X en récupérant les codes de vérification au passage.

Koi Security, LayerX, Zenity : trois équipes qui ne travaillent pas ensemble, sur trois mécanismes techniques sans rapport les uns avec les autres. Et le même résultat à chaque fois, un agent qui agit avec l’identité complète de l’utilisateur sur tout ce que celui-ci a laissé ouvert. C’est pour ça que la liste de la CSA m’intéresse, malgré mon allergie habituelle aux listicles écrits par des vendeurs.

Le correctif ferme le bug. Il ne réduit jamais le périmètre.

Les 6 risques, et ce que qu’il faut en retenir vraiment

La CSA a fait un choix éditorial interessant : aucun des six risques listés n’est une CVE. Ce sont des propriétés d’architecture, donc des choses qui restent vraies le lendemain du patch. Je les reprends dans l’ordre, avec quelques ajouts

1. Injection de prompt indirecte

L’attaquant place ses instructions dans du contenu que l’agent va lire de toute façon : texte invisible dans une page(blanc sur blanc), commentaire HTML, métadonnée d’image, corps d’un mail. Le modèle ne dispose d’aucun mécanisme fiable pour séparer « données à traiter » de « instructions à suivre ». C’est le point 1 du Top 10 OWASP pour les LLM depuis deux éditions, et j’ai déjà détaillé la taxonomie complète de ces techniques : plus de 200 variantes cataloguées, aucun correctif complet.

Anthropic communique honnêtement sur le sujet : sans mitigation, 23,6 % de taux de succès sur leurs tests d’attaque ciblée, ramené à 11,2 % avec les classifieurs et les confirmations d’action. Onze pour cent, ce n’est pas une note de sécurité. C’est une probabilité de compromission par tentative.

2. Héritage d’identité

L’agent n’a pas de credentials à lui. Il travaille dans vos sessions ouvertes : votre webmail, votre console cloud, votre forge, votre outil de ticketing, tous authentifiés simultanément dans le même profil Chrome. Aucun vol d’identifiant n’est nécessaire pour agir en votre nom ; il suffit de faire agir l’agent.

ClaudeBleed est la démonstration littérale de ce risque. Une extension à zéro permission déclarée n’avait besoin d’aucun token : elle envoyait des commandes, et Claude les exécutait avec les cookies de session déjà présents. Le sujet rejoint directement les 8 risques d’identité d’agent listés par la CSA en juillet ; en particulier le risque de combinaison toxique, où plusieurs faiblesses moyennes s’additionnent de façon exponentielle.

Note du PandaRedacteur : on a passé quinze ans à expliquer qu’un compte de service partagé, c’était mal. On vient de réinventer le concept, avec un LLM aux commandes et le profil Chrome de la DSI comme périmètre.

3. Autorité cross-origin

Aucune frontière n’a été franchie ici, contrairement au risque précédent ; c’est bien pire, elle n’existe simplement pas à cet endroit. La same-origin policy repose sur une hypothèse implicite jamais écrite dans la spec : c’est un humain qui décide de passer d’un domaine à l’autre, et cet humain a un contexte. Un agent lit une page sur un domaine et agit sur un autre dans le même tour de raisonnement, sans que rien dans le modèle de sécurité du navigateur ne s’y oppose. Personne n’a contourné quoi que ce soit ; le produit fait exactement ce pour quoi il a été conçu.

Il n’y a donc rien à réparer, dans un sens strict : la fonctionnalité consiste précisément à traverser cette frontière.

4. Fatigue d’approbation et dérive de plan

Les modes restrictifs se dégradent à l’usage. L’utilisateur bascule en mode permissif parce que les confirmations cassent son flux, l’agent navigue vers un domaine non approuvé, et le spam programmatique d’approbations finit d’user la vigilance. LayerX a documenté les deux techniques opérationnelles sur ClaudeBleed : l’approval looping, qui envoie la commande de confirmation en boucle, et la manipulation du DOM, qui renomme le bouton sensible pour que la victime approuve autre chose que ce qu’elle croit.

C’est le même mécanisme que celui qui m’a fait écrire sur le mode YOLO des agents IA, et qu’Amazon appelle sans détour la normalisation de la déviance quand ils expliquent pourquoi ils refusent de faire du human-in-the-loop leur contrôle principal. Un contrôle dont l’efficacité décroît à mesure qu’on l’utilise finit toujours par se transformer en rituel, et un rituel ne bloque rien.

5. Capacité excessive

La CSA a une formule que je reprends volontiers pour ce risque : des frontières molles, des garde-fous que le modèle suit. Concrètement, ça recouvre la lecture du trafic réseau et l’exécution de JavaScript arbitraire dans la page ; deux capacités de développeur, activées dans un contexte authentifié en continu. Anthropic bloque certaines catégories de sites (services financiers, contenu adulte, contenus piratés) et fait tourner des classifieurs sur les motifs d’instruction suspects.

Le verbe compte : le modèle suit ces garde-fous. Il ne s’y heurte pas. En sécurité, on appelle ça une préférence, pas un contrôle d’accès.

6. Confiance héritée

Ce sixième risque est celui qui est le moins souvent formalisé, et c’est aussi le plus élégant techniquement. La confiance ne s’arrête pas au code de l’éditeur : elle s’étend à tout ce qui tourne sur un sous-domaine considéré comme de confiance, y compris les composants tiers.

ShadowPrompt est exactement ça. Deux défauts ordinaires, chacun peu spectaculaire pris isolément :

  • une allowlist d’origines trop permissive dans l’extension, qui acceptait n’importe quel sous-domaine *.claude.ai pour un message porteur de prompt ;
  • une XSS DOM-based dans un composant CAPTCHA Arkose Labs hébergé sur a-cdn.claude.ai, qui rendait un champ contrôlé par l’attaquant via dangerouslySetInnerHTML sans assainissement.

Chaînés, ils donnent une injection de prompt zéro clic déclenchée par la simple visite d’une page, sur une base de plus de trois millions d’utilisateurs. Le composant fautif n’était même pas du code Anthropic. Je retrouve là exactement la logique des 77 extensions Open VSX malveillantes : la surface d’attaque d’une extension, c’est l’union de tout ce à quoi elle fait confiance.

Analyse STRIDE

Je place la frontière de confiance à l’endroit qui compte : entre le contenu web arbitraire lu par l’agent et les sessions authentifiées auxquelles il a accès. Tout ce qui traverse cette frontière sans validation est le sujet.

Catégorie STRIDEApplicableExplication
Spoofing Critique ShadowPrompt et ClaudeBleed reposent tous deux sur une usurpation d'origine : un sous-domaine tiers ou une extension quelconque se fait passer pour un émetteur légitime de commandes. L'extension authentifiait l'origine du message, jamais le contexte d'exécution qui l'avait produit.
Tampering Élevé La manipulation du DOM pour renommer un bouton d'approbation altère la représentation même du consentement. L'utilisateur valide une action différente de celle qui lui est décrite à l'écran.
Repudiation Élevé Les actions sont émises depuis les sessions légitimes de l'utilisateur, avec ses cookies et son adresse IP. Sans journalisation au niveau de l'agent, rien ne distingue un mail envoyé par la victime d'un mail envoyé par l'injection ; les logs applicatifs côté Gmail ou GitHub sont identiques.
Information Disclosure Critique C'est l'impact démontré à chaque incident : contenus Gmail, fichiers Drive, code source de dépôts privés, historique de conversation, jetons d'accès. PleaseFix va jusqu'à l'interception des codes de vérification pour enchaîner sur d'autres comptes.
Denial of Service Faible Peu pertinent ici. Un attaquant qui obtient l'exécution d'actions authentifiées a bien plus intéressant à faire que d'interrompre le service ; la suppression de données reste possible, mais elle relève de l'intégrité plus que de la disponibilité.
Elevation of Privilege Critique Le cœur du problème. Une extension à zéro permission déclarée atteint le niveau de privilège cumulé de toutes les sessions ouvertes de l'utilisateur. Et le passage en mode privilégié, qui neutralise les vérifications ajoutées en 1.0.70, ne demande ni approbation ni notification.

Impact potentiel

Dimension Niveau Conséquence concrète
Confidentialité Critique Boîte mail, fichiers Drive partagés vers un compte attaquant, code source de dépôts privés, historique de conversation avec l'agent, jetons d'accès. Le tout depuis une session légitime.
Intégrité Critique Envoi de mails au nom de la victime, modification de partages, suppression de données, commits sur une forge. L'approval looping et le renommage de bouton permettent d'obtenir une validation formellement valide.
Disponibilité Modéré Pas un objectif d'attaque en soi, mais la suppression de mails ou de fichiers reste dans les capacités démontrées, et la restauration n'est pas toujours possible.
Réputation Élevé Prise de contrôle de comptes Slack et X via les codes de vérification interceptés dans la boîte mail. Le rebond depuis un compte collaborateur légitime vers le reste de l'organisation est trivial.

Exemple concret : une demande de résumé, et cinq comptes qui tombent

Je reprends ici le scénario PleaseFix contre Claude in Chrome, parce qu’il n’exige aucune sophistication de la part de la victime, et surtout aucune erreur de sa part.

  1. L’attaquant envoie un mail parfaitement ordinaire à la cible. Pas de pièce jointe, aucun lien à cliquer, rien qui déclenche un réflexe. Le mail contient simplement des instructions structurées à destination d’un agent, invisibles à la lecture humaine.
  2. La cible ouvre sa boîte mail le matin et demande à Claude : « résume-moi mes mails d’hier soir ». Une demande que je fais moi-même, sans y penser, plusieurs fois par semaine.
  3. L’agent lit les mails. Le corps du message piégé entre dans son contexte de travail avec exactement le même statut que la demande de l’utilisateur. Le modèle n’a aucun moyen structurel de distinguer les deux.
  4. Les instructions injectées poussent l’agent à charger un paquet NPM hébergé sur un CDN contrôlé par l’attaquant, ce qui contourne les mécanismes de sécurité qui filtraient les motifs connus.
  5. Le script s’exécute dans la session active de la victime. Il lit et exfiltre le contenu de Gmail, puis partage les fichiers Google Drive avec un compte attaquant.
  6. Il surveille ensuite la boîte mail pour intercepter les codes de vérification, et s’en sert pour prendre le contrôle des comptes Slack et X associés à cette adresse.

À aucun moment la victime ne clique, ne télécharge quoi que ce soit ou ne saisit un mot de passe. Sa seule action, dans toute la chaîne, c’est d’avoir demandé un résumé.

Note du PandaRedacteur : la phrase « l’utilisateur doit rester vigilant » n’a plus aucun sens ici. Vigilant devant quoi ? Le mail est invisible, l’action est légitime, et la victime lit un résumé parfaitement correct pendant que son Drive part en partage public.

C’est structurellement la même histoire que NemoClaw, où une page web piégée suffit à prendre le contrôle d’un agent Ollama local. Le contenu lu par un agent est du code exécutable, tant qu’on n’a pas prouvé le contraire.

Ce qu’il faut mettre en place avant d’autoriser le déploiement

Ces mesures se rangent en deux familles : celles qui réduisent le périmètre, et celles qui restaurent la traçabilité. Les deux sont nécessaires, et aucune ne relève du correctif éditeur ; je détaille les deux familles complètes, avec les commandes et les points de contrôle précis, dans la version longue envoyée d’abord à mes abonnés payants.

Au Menu, vous retrouvez la suite :

  • les 4 mesures concrètes pour réduire le périmètre (profil navigateur dédié, séparation des identités, interdiction du mode autonome, allowlist explicite par site) ;
  • les 4 mesures pour restaurer la traçabilité (journalisation au niveau agent, détection du motif cross-origin, ré-authentification pas à pas, tests continus des chemins d’injection) ;
  • mes deux notes sur ce qui se détecte réellement, et ce qui ne se détecte pas ;
📬 Mitigations complètes réservées aux abonnés payants
La liste complète des mitigations part d'abord aux abonnés payants de ma newsletter Substack, avant d'être publiée intégralement ici.

📚 Quelques références pour aller plus loin

À retenir 📌

  • ✓ Aucun des six risques de la CSA n'est une CVE : ce sont des propriétés d'architecture, qui restent vraies le lendemain du correctif.
  • ✓ L'héritage d'identité est le vrai multiplicateur : l'agent n'a pas de credentials à lui, il utilise toutes vos sessions ouvertes en même temps.
  • ✓ 11,2 % de taux d'attaque résiduel après mitigations, chiffre publié par Anthropic lui-même : une probabilité de compromission par tentative, pas une note de sécurité.
  • ✓ Les approbations humaines se dégradent à l'usage : approval looping, renommage de bouton, bascule silencieuse en mode privilégié. Ne les comptez pas comme votre contrôle principal.
  • ✓ Votre surface d'attaque inclut vos dépendances tierces : ShadowPrompt a transité par un composant CAPTCHA qui n'appartenait pas à Anthropic, sur un sous-domaine de confiance.
  • ✓ Profil navigateur dédié, identités séparées, mode autonome interdit, journalisation au niveau de l'agent : quatre mesures qui réduisent le périmètre sans dépendre du prochain patch.
LinkedIn Reddit Substack