Chrome CVE-2026-7910 : use-after-free dans Views (site isolation bypass)

CVE-2026-7910 (CVSS 9.6) est un use-after-free dans le composant Views de Chrome, identifié comme une vulnérabilité de sécurité HIGH par l'équipe Chromium et exploitable depuis un renderer compromis pour bypasser la site isolation — la barrière de sécurité fondamentale qui empêche un site malveillant d'accéder aux données d'un autre site dans le navigateur.

Pour les organisations qui déploient Chrome sur un parc, c'est une mise à jour à pousser rapidement : un site malveillant capable d'exploiter cette CVE peut potentiellement voler les sessions, cookies, mots de passe enregistrés et données d'authentification de tous les autres onglets ouverts.

Détails techniques

Le composant Views

Views est la bibliothèque UI native de Chrome utilisée pour rendre les composants d'interface (barres d'onglets, menus, boîtes de dialogue, popups, omnibox). Elle s'exécute dans le processus principal du navigateur — le processus le plus privilégié, qui orchestre les renderers (un par site selon la site isolation).

Le bug

Un use-after-free signifie qu'un objet est libéré de la mémoire pendant qu'au moins un pointeur sur lui reste actif. Une utilisation ultérieure du pointeur dangling :

• En lecture : information disclosure (lit de la mémoire potentiellement réutilisée pour d'autres données)
• En écriture : corruption mémoire, contrôle possible du flow d'exécution
• Avec gadget de réallocation : exécution de code arbitraire

Dans le cas de CVE-2026-7910, l'exploitation présuppose un renderer déjà compromis — l'attaquant a déjà obtenu une exécution dans le sandbox renderer (par exemple via un autre exploit V8 ou Blink). Depuis ce renderer, l'attaquant peut envoyer des messages IPC malveillants au processus browser, déclencher le UAF dans Views, et obtenir l'exécution dans le processus browser non sandboxé.

Conséquence : site isolation bypass

La site isolation garantit que :

• Chaque site (origine) tourne dans son propre processus renderer sandboxé
• Un site ne peut pas lire la mémoire d'un autre site, même si son renderer est compromis

CVE-2026-7910 brise cette garantie : depuis un renderer compromis, l'attaquant escape vers le processus browser, qui voit toutes les données de tous les sites ouverts. Sessions de banque, mots de passe stockés, cookies authentifiés — tout devient accessible.

Caractéristiques

Produits et versions affectés

Tous les navigateurs basés sur Chromium sont potentiellement affectés. Microsoft Edge, Brave, Opera, Vivaldi, Arc — tous embarquent Chromium et héritent de la vulnérabilité jusqu'à ce qu'ils intègrent le correctif upstream.

Vérifier sa version

chrome://settings/help

Chrome se met à jour automatiquement par défaut, mais le déclencheur effectif demande un redémarrage du navigateur. Sur un parc d'entreprise sans politique GPO de redémarrage forcé, des centaines de postes peuvent tourner sur une version vulnérable pendant des jours.

Exploitation et impact

Scénario d'attaque réaliste

1. Compromission initiale du renderer : l'attaquant héberge une page qui exploite une autre CVE Chrome (V8, Blink, WebAssembly) pour obtenir une exécution dans le renderer sandbox. Ces CVE existent régulièrement (plusieurs par mois en moyenne).
2. Chaîne avec CVE-2026-7910 : depuis le renderer compromis, l'attaquant envoie des messages IPC malveillants qui déclenchent le UAF dans Views.
3. Escape du sandbox : exécution dans le processus browser, qui n'est pas sandboxé.
4. Vol massif de données : lecture des cookies de session de tous les sites, des mots de passe enregistrés, des fichiers de profil Chrome, des tokens d'authentification.
5. Persistance : modification de la configuration Chrome, installation d'extensions invisibles, capture du clavier via APIs natives.

Pourquoi le score 9.6 et pas 10

Le score CVSS est légèrement abaissé par :

• UI:R (User interaction required) — l'utilisateur doit visiter une page malveillante
• S:C (Scope changed) — l'exploit traverse la barrière de sandbox vers d'autres composants

Mais en pratique, une visite suffit : tout site, même une publicité injectée sur un site légitime via une régie publicitaire compromise, peut servir d'initial access.

Détection et IOC

Sur les endpoints

• Vérifier la version Chrome déployée sur le parc :

# Windows — via PowerShell
Get-Item "C:\Program Files\Google\Chrome\Application\chrome.exe" | \
  Select-Object @{N='Version';E={$_.VersionInfo.ProductVersion}}

# macOS
mdls -name kMDItemVersion "/Applications/Google Chrome.app"

# Linux
google-chrome --version

Logs réseau

• Trafic depuis Chrome vers des CDN/sites de tracking non habituels
• Connexions HTTPS sortantes anormales après visite de certaines pages (pattern : visite → 10 min → exfiltration de gros volumes vers IP exotique)

Indicateurs de compromission

• Cookies de session valides utilisés depuis des IPs/agents non habituels (vu côté serveur de l'application impactée)
• Extensions Chrome inattendues apparues sans intervention utilisateur
• Profils Chrome modifiés (nouvelle signature dans Local State ou Preferences)

Mitigation et patch

Pour les utilisateurs individuels

1. Forcer la mise à jour : chrome://settings/help → attendre la fin du téléchargement → cliquer Redémarrer
2. Redémarrer Chrome complètement (pas juste fermer la fenêtre) pour que la mise à jour soit effective

Pour les administrateurs IT — déploiement parc

Windows (GPO + auto-update)

# Vérifier que les mises à jour automatiques sont actives
Get-ItemProperty "HKLM:\SOFTWARE\Policies\Google\Update" -Name UpdateDefault

# Forcer un redémarrage planifié de Chrome via GPO
# Computer Configuration → Administrative Templates → Google → Google Chrome → Restart...

macOS

# Vérifier la version sur tout le parc via MDM (Jamf, Kandji, Intune)
# Politique de force-quit + relaunch après mise à jour critique

Linux

# Debian/Ubuntu
sudo apt update && sudo apt upgrade google-chrome-stable

# RHEL/Fedora
sudo dnf upgrade google-chrome-stable

Workaround temporaire (si pas de mise à jour immédiate)

• Désactiver JavaScript sur les sites non essentiels (impact UX majeur, peu réaliste)
• Utiliser un autre navigateur déjà patché en attendant
• Restreindre l'accès web aux seuls sites whitelistés sur les postes sensibles

Pourquoi surveiller en continu vos navigateurs et endpoints

Les navigateurs sont la première porte d'entrée des attaques sur les utilisateurs finaux : 90% des malwares passent par le web. Chrome reçoit en moyenne 2 à 4 CVE CRITICAL ou HIGH par mois, et la fenêtre entre la divulgation et l'exploitation publique se mesure en jours. Un parc dont 30% des postes tournent encore sur une version Chrome non patchée est une cible immédiate.

Avec cveo.tech, inventoriez les navigateurs déployés sur votre parc (Chrome, Edge, Firefox, Safari) et soyez alerté automatiquement dès qu'une CVE critique cible une de vos versions exactes — pour pousser les mises à jour via GPO/MDM avant que les exploits ne soient utilisés massivement.