BragJack : une extension de navigateur détourne les agents IA de cinq navigateurs majeurs

Le 16 septembre 2026, Gal Weizman, chercheur en sécurité chez Forever Security, a publié BragJack : une preuve de concept dans laquelle une extension de navigateur ordinaire — aucun zero-day, aucun modèle jailbreaké, aucun serveur de fournisseur compromis — a pris le contrôle des agents d'IA intégrés à cinq produits basés sur Chromium : Gemini Live dans Google Chrome, Copilot dans Microsoft Edge, Opera Neon, Perplexity Comet et Claude in Chrome. L'extension ne demandait rien d'exotique. Elle utilisait des scripts de contenu et l'API declarativeNetRequest de Chromium, les deux mêmes autorisations que l'on trouve dans la plupart des bloqueurs de publicité, pour atteindre le canal privé que le site propre à chaque fournisseur utilise pour envoyer des instructions à son agent. Weizman rapporte que Comet a constitué la compromission la plus étendue, que Google et Microsoft ont publié des correctifs et attribué les identifiants CVE-2026-0628 et CVE-2026-55945, et qu'aucune attaque dans la nature n'a été observée. Il est répertorié comme vulnérabilité, de gravité élevée, dans l'archive des incidents d'IA, où chaque fiche comporte ses sources, sa note de confiance et son indicateur de contestation.

L'extension n'a pas cassé le modèle. Elle a cassé le canal.

Chacun des cinq produits est construit de la même manière, selon le document technique d’accompagnement que Forever Security a publié le même jour. Chacun possède un « corps » à l’intérieur du navigateur qui peut ouvrir des onglets, lire des fichiers locaux, prendre des captures d’écran et cliquer sur des pages, et un « cerveau » à l’extérieur du navigateur qui décide de ce que le corps doit faire — les serveurs Gemini de Google pour Chrome, l’application web perplexity.ai pour Comet, copilot.microsoft.com pour Edge, le backend d’Anthropic pour Claude in Chrome. Le corps est conçu pour accepter des instructions provenant d’exactement une origine : le site web du fournisseur lui-même. Cette unique origine de confiance constitue tout le modèle de sécurité. C’est aussi l’élément qu’une extension de navigateur est autorisée à toucher.

Chromium accorde à toute extension installée deux pouvoirs quasi universels. Un script de contenu lui permet d’exécuter du JavaScript dans une page. L’API declarativeNetRequest, ou DNR, lui permet de réécrire le trafic réseau — supprimer un en-tête de réponse, rediriger une requête de script vers un autre serveur. Les navigateurs déploient de réels efforts pour tenir ces deux pouvoirs à l’écart des surfaces privilégiées, et quatre des cinq fournisseurs avaient accompli une partie de ce travail. Ce que Weizman a trouvé, dans chaque cas, était une faille dans la partie qu’ils avaient laissée ouverte.

Il appelle cette technique générale DinNeR Serving : utiliser DNR pour affaiblir les en-têtes de sécurité d’une page de confiance, puis utiliser de nouveau DNR pour rediriger l’une des requêtes de script de cette page vers un serveur contrôlé par l’attaquant. La page exécute désormais du code de l’attaquant, mais elle croit toujours être la page du fournisseur, et l’agent croit toujours recevoir des informations du fournisseur. Dans Chrome, Weizman rapporte que les extensions ont été correctement empêchées d’attacher un script de contenu ou un débogueur à l’application Gemini intégrée, et que DNR était le seul mécanisme pour lequel Chromium n’avait pas étendu la même protection à l’intérieur d’un WebView. Supprimer la Content-Security-Policy et assouplir la politique d’isolation des documents a suffi pour remplacer un script servi depuis gstatic.com par le sien, et depuis chrome://glic, il pouvait ensuite publier directement les propres types de messages de l’agent du navigateur — créer un onglet à une adresse file:///, le lire sous forme de texte, de PDF ou de capture d’écran, et récupérer l’adresse e-mail et la photo du profil connecté.

Ce que la même extension a fait, navigateur par navigateur

L’extension ne consistait pas en cinq outils. C’était un seul manifeste qui demandait declarativeNetRequest et un accès large aux hôtes, plus un fichier de règles distinct pour chaque cible ; seules les règles changeaient d’une attaque à l’autre. Le tableau de Forever Security est le résumé le plus clair de ce que chaque chaîne atteignait, et il est reproduit ci-dessous. La ligne qui compte le plus est Agent hijack : dans quatre des cinq cas, le résultat démontré n’était pas le vol de données mais le contrôle d’un agent capable d’agir au nom de l’utilisateur dans des sessions connectées.

Ces chaînes par navigateur sont la partie de BragJack que personne d'autre n'a vérifiée. BleepingComputer, Cyber Security News, la Cloud Security Alliance et le CERT national de Thaïlande ont tous relayé la divulgation, et tous décrivent les mécanismes de la même manière, mais chacun décrit le rapport de Forever Security plutôt que de le tester. L'avis de ThaiCERT du 21 septembre 2026 cite BleepingComputer comme source. Ce qui suit est donc le compte rendu par Weizman de sa propre preuve de concept, ce qu'est une divulgation, et non un résultat reproduit indépendamment.

Perplexity Comet : un domaine de test toujours sur la liste de confiance

Comet était le pire des cinq selon le propre classement du chercheur, et la raison est structurelle plutôt qu’une erreur de codage. Perplexity a conçu un navigateur dans lequel l’agent détient les propres autorisations du navigateur, si bien qu’un agent détourné hérite de toutes. Perplexity avait aussi fait le travail défensif que les autres avaient négligé : les extensions sont totalement empêchées de s’exécuter sur perplexity.ai, ce qui explique pourquoi Weizman affirme que les bloqueurs de publicités n’y fonctionnent pas.

La faille se situait dans la liste des origines à partir desquelles l’extension de l’agent acceptait les commandes. Selon l’analyse technique, cette liste comptait dix entrées, et non une seule — perplexity.ai et sa variante www, ainsi que des hôtes testing, staging et preview sur perplexity.com et perplexity.ai. Seuls les hôtes de production avaient été durcis. testing.perplexity.com acceptait encore les scripts de contenu. L’obstacle restant était que chacun de ces domaines répondait par une redirection 302 vers perplexity.ai, de sorte que le navigateur n’atteignait jamais la page de test assez longtemps pour qu’un script puisse s’y attacher. Une règle DNR qui supprime l’en-tête Location élimine cet obstacle, et le script de contenu peut alors s’adresser directement à l’extension de l’agent via le canal de messagerie runtime qu’elle expose.

Ce que l’agent faisait sur demande, selon Weizman, était de lister l’historique de navigation, d’ouvrir des URL arbitraires, y compris des chemins file:///, et de prendre des captures d’écran des onglets visibles — puis, au moyen d’une commande qui lance une exécution d’agent à partir d’un prompt fourni, de faire presque tout ce qu’un utilisateur pourrait faire. Son prompt de démonstration demandait à Comet de visiter perplexity.ai, de résumer les cinq derniers courriels et d’envoyer le résumé à une seconde adresse. Il rapporte également que l’accès file:/// avait été traité dans une précédente divulgation Comet, mais que le correctif était sensible à la casse, de sorte que FiLe:///etc/hosts fonctionnait encore. Rien de tout cela n’apparaît dans aucun avis Perplexity ; l’entreprise a versé une prime et, selon Forever Security, a corrigé le comportement qui lui avait été montré.

Microsoft Edge : une page marketing, un clic synthétique et une course

Edge a été la seule cible à résister, et c’est la plus instructive des cinq. Microsoft avait scindé son agent en un mode « Think » qui accepte les prompts et un mode « Do » qui agit sur les pages, les deux ne pouvant délibérément pas fonctionner en même temps — un véritable mécanisme de sécurité, et qui empêche par construction le forçage de prompt. Microsoft avait également durci la page marketing à microsoft.com/edge qui fait la démonstration de l’agent, en conditionnant sa fonction privilégiée d’envoi de prompts à trois conditions distinctes : une Content-Security-Policy qui ne pouvait pas être simplement supprimée, car l’objet privilégié n’est jamais créé lorsque l’en-tête est absent, un jeton de geste utilisateur récent, et une fonction qui remplit la zone de prompt plutôt que de l’envoyer.

D'après Weizman, chaque condition a été contournée par une astuce différente. Au lieu de supprimer la CSP, il a élargi sa directive frame-ancestors pour autoriser l'intégration par n'importe quel site en .com. Pour le jeton de geste, il a ajouté l'autorisation debugger au manifeste et déclenché un clic synthétique, que Chromium accepte comme un geste organique. Pour la condition de concurrence, il a désactivé l'indicateur des outils d'agent, appelé la fonction d'envoi d'invite, puis réactivé l'indicateur alors que l'agent décidait encore s'il était autorisé à agir. Le paramètre était désactivé au moment où l'invite a été forcée et activé au moment où la vérification des autorisations s'est exécutée. C'est ce à quoi Microsoft a attribué CVE-2026-55945.

La somme correspond au travail : Forever Security enregistre 3 000 $ pour la découverte dans Edge Chromium et 2 000 $ pour la condition de concurrence, soit 5 000 $ au total — troisième des cinq, derrière les 7 000 $ chacun de Google et Perplexity.

Opera Neon et Claude dans Chrome : les deux plus faciles

Opera Neon a nécessité le moins d’efforts des cinq. Son agent reçoit ses ordres de opera.com et, contrairement à Google et Perplexity, qui ont tous deux empêché les extensions d’attacher des scripts de contenu à l’origine de confiance de leur agent, Opera n’avait pas empêché les extensions d’attacher un script de contenu à ce domaine ; l’extension de Weizman pouvait donc y injecter un script et appeler directement le canal de messagerie de l’agent avec le prompt de son choix. La suppression de la CSP rendait la même attaque intégrable dans un cadre invisible sur n’importe quelle page. Son article ajoute un détail absent de tous les autres articles : Opera lui a dit avoir découvert la faille indépendamment à peu près au même moment, et lui avoir tout de même versé la prime de 900 $. Il s’agit d’une affirmation du fournisseur rapportée par le chercheur, et non d’une conclusion pour laquelle l’une ou l’autre partie aurait publié des preuves.

Claude in Chrome est le cas particulier, car il s’agit d’une extension et non d’un navigateur, et Forever Security le dit clairement : une extension qui en exploite une autre présente un risque moindre qu’une extension qui exploite le navigateur dans lequel elle s’exécute. Le mécanisme reposait sur une page marketing sur claude.ai capable de transmettre des prompts arbitraires au panneau latéral, combinée à un script de contenu qui se déclenchait lors de clics sur un bouton d’intégration et lisait le prompt dans un attribut de données. Weizman a lui-même défini l’id et l’attribut du body de la page, envoyé un clic synthétique via la permission de débogueur, et le panneau latéral s’est ouvert avec son prompt à l’intérieur. Anthropic l’a classée en gravité moyenne, a versé une prime et, selon Forever Security, a reconnu la société comme la première à avoir signalé cette découverte précise. Les deux publications de Forever Security divergent légèrement sur le montant : 600 $ dans le tableau principal, 500 $ dans l’article technique complémentaire.

Ce que disent vraiment les dossiers des fournisseurs eux-mêmes

Seuls deux des cinq ont donné lieu à un enregistrement public de vulnérabilité, et tous deux sont antérieurs de plusieurs mois à l’article BragJack. La note de version du canal stable de Google du 6 janvier 2026 indique « High CVE-2026-0628: Insufficient policy enforcement in WebView tag. Reported by Gal Weizman on 2025-11-23 », et mentionne 143.0.7499.192/.193 pour Windows et Mac, ainsi que 143.0.7499.192 pour Linux. L’entrée du National Vulnerability Database, publiée le 7 janvier 2026, décrit la faille comme permettant à un attaquant « qui a convaincu un utilisateur d’installer une extension malveillante d’injecter des scripts ou du HTML dans une page privilégiée au moyen d’une extension Chrome conçue à cet effet », la classe comme CWE-862, absence d’autorisation, et porte un score CVSS 3.1 de 8,8. Ce score n’est pas celui de Google : il provient de l’enrichissement de l’enregistrement par la CISA, comme l’a noté The Hacker News, et la note de Google elle-même attribue au problème une gravité élevée.

Le dossier de Microsoft est encore plus restreint. CVE-2026-55945, publié le 3 juillet 2026, est une condition de concurrence CWE-362 avec un score CVSS 3.1 de 4,2, gravité Modérée. La déclaration d’impact de Microsoft est « Information Disclosure », et sa propre FAQ indique que les informations divulguées sont le contenu de fichiers. La version corrigée est 150.0.4078.48, publiée le même jour, et le statut d’exploitation du dossier indique « Publicly Disclosed: No; Exploited: No ». Rien dans ce document ne décrit un agent piloté à travers des sites web arbitraires, ce qui est l’impact rapporté par Weizman. Les deux affirmations peuvent être vraies en même temps — la CVE couvre la condition de concurrence, tandis que la capacité évoquée sur la page marketing était une seconde découverte rémunérée séparément — mais aucun document du fournisseur publié à ce jour ne décrit la chaîne de bout en bout.

« Zéro clic » signifie une fois l'extension installée

La formulation dans le tableau de Forever Security est exacte et facile à mal interpréter. BragJack n'est pas une attaque drive-by. BleepingComputer, la Cloud Security Alliance et ThaiCERT commencent tous par la même condition préalable : l'extension malveillante doit déjà être installée. Ce que montre la recherche, c'est qu'une fois qu'elle l'est, aucun clic supplémentaire n'est nécessaire — l'extension atteint l'agent sur la page où se trouve l'utilisateur, sans rien afficher. Pour Comet et Opera Neon, cela ne nécessitait aucune interaction ; pour Edge et Claude in Chrome, le clic exigé par l'agent était synthétisé par l'extension via l'autorisation de débogage, donc l'utilisateur ne l'a pas fourni non plus.

Cette distinction détermine l’exposition dans le monde réel. L’attaque nécessite soit un utilisateur qui installe quelque chose de malveillant, soit une extension déjà reconnue dans la boutique qui devient malveillante plus tard, et ni l’un ni l’autre ne constitue un seuil élevé — c’est pourquoi les recommandations de CSA portent sur l’inventaire des extensions et sur le fait de considérer les autorisations declarativeNetRequest et debugger comme privilégiées. C’est aussi pourquoi personne n’a signalé d’attaque : une preuve de concept qui nécessite l’installation d’une extension hostile est une démonstration de capacité, pas une campagne.

Forçage de prompt, et l’argumentaire commercial qui y est attaché

La terminologie compte parce qu’elle décrit où se situaient les défenses. L’injection de prompt dissimule des instructions dans un contenu que le modèle est déjà en train de lire ; l’entraînement et les filtres du modèle constituent le filet de sécurité prévu. Ce que Weizman a fait, c’est rédiger l’intégralité du prompt, choisir le moment où il arrivait et continuer à envoyer des relances — depuis une origine à laquelle l’agent était conçu pour faire confiance. Le filtrage de sécurité au niveau du modèle n’entre jamais en jeu, car rien dans l’échange ne ressemble à une attaque. Forever Security appelle cela le prompt forcing.

Le corollaire que l’entreprise en tire est que la détection sur les points de terminaison ne peut pas non plus le voir, puisque aucun code malveillant ne s’exécute : on demande à un logiciel légitime de faire quelque chose qu’il est autorisé à faire. Cette affirmation est accompagnée d’un argumentaire produit — Forever Security vend un agent de point de terminaison natif IA, et les deux articles se concluent en le recommandant. L’observation selon laquelle un agent détourné ne produit aucune signature de malware ne dépend pas de l’achat de quoi que ce soit, mais il s’agit de l’argument du chercheur plutôt que d’un résultat mesuré, et aucune partie indépendante n’a testé si un produit de point de terminaison, quel qu’il soit, détecte ces chaînes.

Qu’est-ce qui est établi, et qu’est-ce qui repose sur un seul chercheur ?

L’archive classe cette entrée comme une vulnérabilité, gravité élevée, région mondiale, confiance B — documentée, mais provenant d’une source unique ou secondaire — non contestée, sans dommage réel enregistré. Cette note décrit les preuves plutôt que la gravité des bogues, et cette distinction traverse nettement le récit.

Établi, au sens où un fournisseur ou un document de première partie l'affirme :

• Google a publié un correctif Chrome le 6 janvier 2026 dans les versions 143.0.7499.192 et .193, et a attribué à Gal Weizman un rapport daté du 23 novembre 2025. Cela figure dans la note de version de Google elle-même, et non dans le récit qu’en fait le chercheur.

• La CVE-2026-0628 existe, est notée High par Google et 8,8 par l’enrichissement de la CISA dans l’enregistrement NVD, et est classée comme une application insuffisante des politiques dans une balise WebView.

• Microsoft a publié CVE-2026-55945 le 3 juillet 2026 comme une condition de concurrence de gravité modérée (4.2) entraînant une divulgation d’informations, corrigée dans Edge 150.0.4078.48, aucune exploitation n’ayant été enregistrée.

• Les évaluations SSVC de la CISA dans les deux enregistrements NVD indiquent « exploitation: none », et personne — ni fournisseur, ni chercheur, ni journaliste — n’a revendiqué une attaque en conditions réelles. C’est une absence de signalements, ce qui n’est pas la même chose qu’une preuve d’absence, mais c’est l’état du dossier six semaines après la publication.

Reposant uniquement sur le compte de Forever Security :

• Chaque chaîne d'exploitation propre à chaque navigateur, y compris les ensembles de règles DNR, la suppression de la redirection testing.perplexity.com, la séquence de la page marketing d'Edge et le clic sur le bouton d'accueil de Claude. Les CVE décrivent deux mécanismes ; elles ne décrivent pas ces chaînes.

• La liste complète des impacts pour Comet — historique de navigation, lectures de fichiers locaux, données de profil, captures d’écran — et l’affirmation spécifique selon laquelle un agent Comet détourné pourrait recevoir, en anglais simple, l’instruction de résumer et de transférer des e-mails. BleepingComputer le rapporte comme la démonstration du chercheur ; aucune déclaration de Perplexity ne le confirme ni ne le conteste.

• L'accès à la caméra et au microphone de Chrome, que BleepingComputer décrit comme « potentiellement » accessible et que le tableau Forever répertorie comme atteint.

• Le total des primes. Forever Security indique environ 20 000 $ répartis entre cinq fournisseurs ; ses propres chiffres par produit totalisent 20 500 $, un point arithmétique que The Hacker News a également soulevé. Le chiffre pour Claude in Chrome diffère entre les deux publications de l'entreprise. Le « plus de 20 000 $ » de BleepingComputer est compatible avec l'une ou l'autre lecture.

• Que le prompt forcing constitue une nouvelle classe d’attaque plutôt qu’un nom pour une famille de bugs d’autorisation. Il s’agit là d’une affirmation de cadrage, et la Cloud Security Alliance — qui l’a adoptée — décrit le schéma sous-jacent comme une lacune architecturale commune à plusieurs fournisseurs, et non comme une nouvelle technique dotée de sa propre mécanique.

Trois des cinq fournisseurs n’ont jamais publié le moindre avis de vulnérabilité. CSA note que Perplexity, Opera et Anthropic ont reconnu et corrigé la preuve de concept spécifique sans publier d’avis comparables à ceux de Google et Microsoft, et Forever Security ne donne aucune date de correction pour ces trois-là. Aucune reproduction indépendante d’une chaîne BragJack n’a été publiée ; Cyber Security News et ThaiCERT reprennent tous deux la divulgation, et ThaiCERT cite BleepingComputer.

Qu’est-ce qui a changé après la divulgation

Pour les utilisateurs de Chrome et d’Edge, la réponse pratique est que rien n’avait besoin de changer le 16 septembre : les correctifs ont été déployés en janvier et en juillet, et toute personne utilisant Chrome 143.0.7499.192 ou une version ultérieure, ou Edge 150.0.4078.48 ou une version ultérieure, était déjà protégée. Ce calendrier mérite qu’on s’y arrête. Les failles ont été corrigées des mois avant que la technique qui les reliait ait un nom, ce qui correspond à la forme habituelle de la divulgation coordonnée et explique aussi pourquoi le titre est plus alarmant que l’état réel des correctifs.

Pour Comet, Opera Neon et Claude in Chrome, la situation est moins claire. Chaque fournisseur a versé une prime et, selon Forever Security et CSA, a traité le comportement démontré. Aucun n’a publié d’avis épinglé à une version ni de date, donc il n’existe aucun numéro de build que l’utilisateur puisse vérifier, seulement l’instruction générale de rester à jour. Les recommandations de CSA pour les organisations sont d’inventorier les extensions disposant des autorisations declarativeNetRequest ou debugger, de restreindre les navigateurs agentiques à des profils sans sessions authentifiées sur la messagerie, le code ou la finance, et de demander aux fournisseurs comment ils distinguent les entrées synthétiques des véritables entrées utilisateur. Le conseil de BleepingComputer aux particuliers est plus simple : gardez le navigateur à jour, supprimez les extensions que vous ne reconnaissez pas et traitez « lire et modifier toutes vos données sur tous les sites web » comme l’avertissement qu’il représente.

La question non résolue n'est pas de savoir si cinq bugs ont été corrigés. C'est de savoir si l'hypothèse de conception qui les sous-tend l'a été. Chacun de ces produits considérait une origine web first-party comme un endroit digne de confiance où un agent local privilégié pouvait recevoir des ordres, dans un navigateur où n'importe quelle extension installée peut réécrire ce que déclare cette origine. Forever Security soutient que la solution réside dans une surveillance au niveau du point de terminaison ; CSA plaide pour la validation de l'origine, le moindre privilège, des canaux de commande isolés et une provenance des entrées infalsifiable. Aucun des cinq fournisseurs n'a déclaré publiquement, dans aucun document examiné pour cet article, avoir modifié l'architecture plutôt que le chemin précis emprunté par Weizman.

La date du dossier est celle de l’explication, pas celle des bugs — et cet écart est toute l’histoire. Une seule extension, deux autorisations que les bloqueurs de publicités détiennent depuis des années, et cinq fournisseurs qui croyaient chacun que leur propre site web était le seul endroit où un attaquant ne pouvait pas se trouver.