CVE-2026-0628 : extension WebView Gemini

CVE-2026-0628 permettait à une extension Chrome d’agir sur le WebView privilégié de Gemini via DNR ; passez à la version 143.0.7499.192 ou ultérieure.^{[1], [3], [5]}

Vecteur CVSS

CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H^[3]

💡 Explication en Langage Simple (ELI5)

Imaginez Gemini Live comme un comptoir d’accueil dans une bibliothèque, avec une porte réservée au personnel derrière. Chrome empêchait les extensions de franchir cette porte, mais une règle de redirection des livraisons pouvait encore remplacer un script au comptoir Gemini. Le script s’exécutait à ce comptoir intégré, qui disposait d’un guichet de service pour demander des capacités du navigateur. CVE-2026-0628 était le contrôle manquant sur cette voie de livraison.^{[2], [5]}

Concepts Clés et Termes

WebView privilégié: Page intégrée dans une surface contrôlée par le navigateur et capable de communiquer avec des fonctions interdites aux sites ordinaires.^{[2], [5]}
declarativeNetRequest (DNR): API d’extension Chrome qui applique des règles déclaratives aux requêtes réseau correspondantes, notamment les redirections et modifications d’en-têtes.^{[2], [6]}
CVE-2026-0628: Faille Chrome de haute gravité décrite par Google comme une application insuffisante des règles dans la balise WebView avant Chrome 143.0.7499.192.^{[3], [4]}
BragJack / prompt forcing: Publication de recherche de septembre 2026 décrivant le contrôle d’agents de navigateur par des extensions. C’est un nom de recherche, pas une autre CVE Chrome.^{[2], [4]}

Correspondances de référentiels

Référence CWE pour la faiblesse décrite dans ce guide : CWE-862

Analyse de Cause Racine

Google décrit CVE-2026-0628 comme une application insuffisante des règles dans la balise WebView de Chrome. L’analyse technique de Forever Security indique que Gemini Live utilisait la page contrôlée par le navigateur chrome://glic, qui intégrait gemini.google.com dans un WebView. Chromium bloquait l’interaction des extensions avec la page privilégiée, mais la faille décrite permettait à une extension dotée de declarativeNetRequest (DNR) d’influencer les requêtes HTTPS correspondantes de la page intégrée. Le chercheur décrit la modification des en-têtes de réponse et le remplacement d’un script afin d’exécuter du code dans l’origine Gemini intégrée et de communiquer avec le pont de l’agent du navigateur. Cela pouvait franchir la frontière entre les permissions ordinaires d’une extension et les fonctions exposées au panneau privilégié. Le rapport démontre l’accès au contexte de la page, au contenu de fichiers locaux et à des captures d’écran ; il évoque aussi un accès possible à la caméra/au micro. Il s’agit d’impacts rapportés par le chercheur, pas de preuves d’exploitation réelle. La CVE suppose que l’utilisateur installe une extension malveillante. Google a corrigé la frontière WebView dans Chrome 143.0.7499.192/.193 pour Windows/macOS et .192 pour Linux. Le correctif public de Chromium confirme la frontière : RulesetManager renvoie false lorsque request.is_web_view vaut true, avant la décision d’autorisation existante. Chromium a ajouté ChromeSignInWebViewTest.DeclarativeNetRequestRulesNotMatched ; le test ignore MPArch, cette architecture n’est donc pas couverte par ce test de régression.^{[3], [2], [5], [4]}

Déroulement de l'Attaque Étape par Étape

Étape 1

Vérifier les conditions

Le chemin décrit exige une version Chrome vulnérable et une extension malveillante ou compromise installée par l’utilisateur, avec DNR et des permissions d’hôte correspondantes. Ce n’est pas une attaque drive-by par une page web.^{[3], [2], [6]}

Étape 2

Ouvrir la surface de l’agent

Gemini Live utilise la page navigateur chrome://glic et intègre l’application web Gemini dans un WebView. Cette page peut appeler des fonctions indisponibles aux sites ordinaires.^[2]

Étape 3

Franchir la frontière des requêtes WebView

Selon le chercheur, les règles DNR pouvaient agir sur les ressources HTTPS chargées dans le WebView intégré malgré les restrictions d’interaction avec la surface privilégiée.^{[2], [5]}

Étape 4

Atteindre le comportement privilégié

En modifiant la politique de réponse et le code chargé depuis l’origine Gemini, la chaîne démontrée pouvait communiquer avec le pont de l’agent. Le chercheur rapporte l’accès à des fichiers locaux et à des captures ; aucune exploitation réelle n’est publiquement établie.^{[2], [3]}

Étape 5

Corriger et réduire l’exposition

Le correctif Google est inclus dans Chrome 143.0.7499.192/.193 selon la plateforme. Passez à la version stable actuelle et limitez les extensions ayant de larges permissions d’hôte et DNR.^{[1], [3], [5]}

Code Source : Vulnérable vs Sécurisé

Il s’agit du changement C++ amont de Chromium, et non d’une reconstitution d’exploit. Il refuse les requêtes provenant d’un WebView avant la décision d’autorisation existante, afin que les règles Declarative Net Request ne s’y appliquent pas. Chromium a aussi ajouté ChromeSignInWebViewTest.DeclarativeNetRequestRulesNotMatched ; ce test de navigateur ignore MPArch et ne démontre donc pas la couverture de cette architecture.^[5]

IMPLÉMENTATION VULNÉRABLE

// Extrait : extensions/browser/api/declarative_net_request/ruleset_manager.cc
// Avant la correction, cette décision finale ne vérifiait pas si l’origine était une WebView.
return true;

PATCH SÉCURISÉ ET ROBUSTE

// Extrait : extensions/browser/api/declarative_net_request/ruleset_manager.cc
// Modification Chromium 9722f06a, avant l’autorisation finale existante :
// Les règles Declarative Net Request ne doivent pas être appliquées aux requêtes
// provenant de WebViews.
if (request.is_web_view) {
  return false;
}
return true;

Liste de Contrôle de Sécurité pour l'Ingénierie

✓Mettez à jour tous les canaux et systèmes Chrome gérés vers une version stable actuelle ; Google cite 143.0.7499.192/.193 comme première version corrigée.^{[1], [3]}
✓Inventoriez les extensions ayant declarativeNetRequest et de larges permissions d’hôte ; supprimez celles qui ne sont pas approuvées ou utilisées et préférez des listes d’autorisation gérées.^{[6], [2]}
✓Ne considérez pas l’URL d’une page privilégiée comme une isolation suffisante lorsqu’elle intègre d’autres origines ; appliquez la politique d’extension au contexte complet de la requête intégrée.^{[2], [5]}
✓Ajoutez des tests navigateur vérifiant que les redirections et modifications d’en-têtes d’extensions n’affectent pas les ressources des WebView privilégiés du navigateur.^[5]
✓Comme règle de défense en profondeur pour les intégrations d’agents de navigateur, gardez les opérations privilégiées derrière une interface du navigateur liée à l’origine ; vérifiez la source du message, l’identité du frame, le type de requête et l’état du consentement de l’utilisateur pour chaque opération.^[2]
✓Distinguez la CVE de la recherche BragJack ultérieure : les constats plus larges sur d’autres navigateurs ne signifient pas qu’ils partagent cette CVE.^{[2], [4]}