Chrome corrige CVE-2026-85046 : l’exploitation avait déjà commencé

9 septembre 2026 à 03:00|Auteur: Équipe éditoriale de QUASA|5 min de lecture| 9

Google a publié le 3 septembre 2026 une mise à jour de Chrome pour ordinateur qui corrige CVE-2026-85046, alors que la faille était déjà exploitée activement. Dans son bulletin du canal Stable, l’éditeur distribue les builds 152.0.7977.82/.83 pour Windows et Mac et 152.0.7977.82 pour Linux, classe cette confusion de types dans V8 parmi les vulnérabilités de sévérité élevée et confirme qu’un exploit existe dans la nature.

Pour déterminer si une installation reste vulnérable, il faut comparer son numéro complet au seuil correspondant à son système. Selon l’avis du CERT-FR du 4 septembre, les versions antérieures à 152.0.7977.82 sous Linux et Windows et à 152.0.7977.83 sous macOS sont affectées.

Une matrice différente pour Linux, Windows et macOS

Comparaison des versions minimales corrigées de Google Chrome sous Linux, Windows et macOS.

Le numéro majeur « Chrome 152 » ne suffit pas pour conclure. La comparaison doit porter sur les quatre composantes de la version installée, avec un seuil distinct pour macOS.

Linux : 152.0.7977.82 ou version ultérieure.
Windows : 152.0.7977.82 ou version ultérieure.
macOS : 152.0.7977.83 ou version ultérieure.

Le bulletin de publication regroupe Windows et Mac sous la notation 152.0.7977.82/.83, sans attribuer séparément chaque build dans cette phrase. Le CERT-FR lève cette ambiguïté dans sa liste des systèmes affectés : il fixe le seuil à .82 pour Windows et à .83 pour Mac. Une installation 152.0.7977.82 sous macOS doit donc encore être considérée comme inférieure au seuil documenté.

Ces numéros concernent le canal Stable de Chrome pour ordinateur. Ils ne doivent pas être transposés à ChromeOS, Android, iOS, Chromium ou à un autre navigateur fondé sur Chromium sans consulter le bulletin propre au produit et à son mode de distribution.

Vérifier la version active après le redémarrage

Contrôle de la version active de Google Chrome après la mise à jour et le redémarrage.

Sur un poste de travail, la page « À propos de Google Chrome », également accessible par chrome://settings/help, affiche le numéro courant et recherche les mises à jour. L’aide officielle de Chrome précise qu’une mise à jour disponible s’applique après avoir sélectionné « Relancer » ; sous Linux, l’installation passe par le gestionnaire de paquets.

Identifier le système d’exploitation et relever le numéro complet affiché.
Comparer ce numéro au seuil de la matrice, sans se limiter à la branche 152.
Laisser l’installation se terminer, puis fermer et relancer Chrome lorsque cette action est demandée.
Retourner sur la page de version afin de vérifier la build effectivement exécutée.

Ainsi, 152.0.7977.75 reste vulnérable sur les trois systèmes, même si le navigateur appartient déjà à la branche 152. De même, le téléchargement du correctif ou son approbation dans un outil d’administration ne démontre pas que les processus encore ouverts utilisent les nouveaux fichiers : c’est le numéro observé après relance qui tranche.

Les flottes et les navigateurs automatisés exigent leur propre inventaire

Inventaire des installations Chrome gérées et headless avec vérification de chaque exécutable actif.

Dans une organisation, le contrôle doit couvrir chaque exécutable Chrome susceptible d’être lancé, pas uniquement les postes des utilisateurs connectés au moment du déploiement. Cela inclut les machines rarement en ligne, les postes virtuels, les serveurs de test et les images servant à créer de nouveaux environnements.

Le même raisonnement vaut pour Chrome en mode headless dans une chaîne Selenium, Puppeteer ou une autre automatisation. La version de la bibliothèque de pilotage ne prouve pas celle du navigateur lancé : le binaire peut provenir d’une image de conteneur ancienne, d’un cache de pipeline ou d’un chemin configuré manuellement. Il faut interroger cet exécutable précis, par exemple avec son option --version dans l’environnement où la tâche s’exécute.

Un inventaire exploitable associe au minimum le système, la version complète, le chemin de l’exécutable et l’état de la relance. Pour les conteneurs et les images de machines virtuelles, corriger une instance en cours ne suffit pas si le modèle de base reste ancien : les prochains déploiements pourraient réintroduire une version inférieure au seuil.

Les consoles de gestion peuvent également signaler qu’une campagne est lancée sans garantir que chaque appareil a reçu puis activé la build corrigée. Les postes hors ligne, les déploiements échelonnés et les sessions Chrome restées ouvertes doivent donc demeurer non conformes jusqu’à la remontée d’un numéro de version suffisant.

Les détails des attaques restent confidentiels

La publication recense douze correctifs de sécurité et identifie CVE-2026-85046 comme une confusion de types dans V8, signalée le 4 août 2026 par Salvatore Gulizia. La confirmation d’exploitation dans la nature vise expressément cette vulnérabilité ; elle ne signifie pas que les onze autres failles du lot sont elles aussi exploitées.

Les informations publiques ne décrivent ni les cibles, ni l’ampleur des attaques, ni la chaîne technique employée. L’accès aux rapports de bugs et à certains liens peut rester restreint jusqu’à ce qu’une majorité d’utilisateurs ait reçu le correctif, voire davantage lorsqu’une bibliothèque tierce encore vulnérable est concernée.

À ce stade, le constat vérifiable est donc précis : le correctif est disponible sur le canal Stable de Chrome pour ordinateur, et l’exploitation de CVE-2026-85046 avait déjà commencé lors de sa publication. Faute de détails sur les attaques, le numéro de l’exécutable réellement actif reste le critère décisif pour savoir si un poste, une flotte ou un navigateur automatisé se trouve encore sous le seuil corrigé.