EN
en direct

Chrome corrige son sixième zero-day exploité de 2026 dans le moteur V8

Le 4 septembre 2026, Google publie une mise à jour d’urgence de Chrome qui corrige CVE-2026-85046, une confusion de types dans le moteur V8 déjà exploitée dans la nature et notée 8,8 au CVSS. Mettez à jour vers Chrome 152.0.7977.82 ou supérieur et vérifiez tous les navigateurs Chromium de votre parc, Edge, Brave et Opera compris.

Un roulement carré coincé dans une douille ronde d’un engrenage gris et ordonné, l’anomalie soulignée en ambre.

4 septembre 2026. Google publie une mise à jour d’urgence de Chrome qui corrige CVE-2026-85046, une confusion de types dans le moteur V8, déjà exploitée dans la nature. 4 août 2026. Le chercheur Salvatore Gulizia, alias Serotav, avait signalé la faille et reçu une prime de 1 000 $. 2026. C’est le sixième zero-day de Chrome activement exploité que Google corrige depuis janvier. Pourquoi c’est grave : une simple visite d’une page piégée suffit à déclencher l’exploit, et la faille touche V8, le composant commun à tous les navigateurs Chromium — pas seulement Chrome.

Une confusion de types dans V8, la boîte noire

La faille est un cas d’école de confusion de types. V8 exécute le JavaScript et le WebAssembly à une vitesse proche du natif grâce à ses compilateurs JITTurboFan et Maglev — qui font des hypothèses agressives sur le type des variables à partir du profilage. Quand un compilateur se trompe sur la nature d’un objet, il traite une donnée comme un autre type : c’est exactement ce qui se produit ici.

Google qualifie la vulnérabilité de high severity, avec un score CVSS 8.8. Un attaquant peut fabriquer du contenu web qui pousse V8 à manipuler la mémoire de façon inattendue. Selon la chaîne d’exploitation, le résultat va du plantage à l’exécution de code contrôlé dans le processus de rendu de Chrome. Le vecteur est trivial : une page malveillante ou compromise, un lien de phishing, une publicité piégée.

Ce que fait réellement le bug

L’analyse technique publiée par Gulizia décrit le mécanisme en détail. V8 suit la structure des objets à l’aide de Maps, des classes cachées qui décrivent la forme d’un objet et, pour les tableaux, leur element kind. Deux types sont au cœur de l’exploit : PACKED_SMI_ELEMENTS, un tableau dense de petits entiers stockés en place, et PACKED_ELEMENTS, un tableau générique qui peut contenir objets, flottants et pointeurs.

La vulnérabilité survient quand le compilateur laisse un tableau initialisé en PACKED_ELEMENTS recevoir la Map d’un PACKED_SMI_ELEMENTS. Ce décalage casse la sûreté mémoire de deux façons. À la lecture, V8 croit lire des entiers alors que la mémoire contient de vrais pointeurs : l’attaquant fuit des adresses réelles et contourne l’ASLR. À l’écriture, V8 écrit un entier interprété comme un pointeur dans la mémoire de stockage. En enchaînant ces deux primitives, l’attaquant obtient une lecture et une écriture arbitraires sur le tas JavaScript — le Saint Graal d’une chaîne d’exploitation de navigateur.

Google ne divulgue pas les détails de l’exploit ni les cibles, une retenue standard pour un zero-day actif : tant que la majorité des utilisateurs n’a pas mis à jour, publier le mécanisme revient à armer les opportunistes et les botnets qui scrapent les divulgations.

Le sixième zero-day de l’année

La statistique donne la mesure du problème. CVE-2026-85046 est le sixième zero-day de Chrome exploité dans la nature corrigé en 2026, après CVE-2026-2441, CVE-2026-3909, CVE-2026-3910, CVE-2026-5281 et CVE-2026-11645. La plupart ciblent V8, de loin la plus grande surface d’attaque du navigateur : c’est elle qui exécute du code non fiable venu du web à vitesse native.

La mise à jour ne contient pas que ce correctif. Le bulletin Chrome liste 12 correctifs de sécurité au total, dont plusieurs de gravité élevée touchant V8, WebGL, le composant réseau, DevTools, Skia, CacheStorage, le compositing et le rapport de crash — une écriture hors limites dans WebGL, des use-after-free dans le compositing, DevTools et Skia, une course dans V8. Le correctif porte Chrome en version 152.0.7977.82/.83 sur Windows et macOS, et 152.0.7977.82 sur Linux.

Qui est exposé

Le périmètre dépasse Chrome. Tout navigateur construit sur Chromium partage le même moteur V8 : Microsoft Edge, Brave, Opera et Vivaldi sont également exposés à CVE-2026-85046. Chaque éditeur applique son propre calendrier de mise à jour, mais les correctifs amont de Chromium sont en général intégrés rapidement. Un administrateur ne peut pas se contenter de mettre à jour Chrome : il doit vérifier chaque navigateur du parc.

Côté entreprise, la consigne est de vérifier que les postes gérés sont passés en 152.0.7977.82 ou supérieur, et de surveiller la télémétrie des terminaux comme les journaux de filtrage web à la recherche de campagnes de phishing qui exploitent des domaines fraîchement enregistrés ou de fausses invites de mise à jour.

bash
# Vérifier la version installée sur un poste Linux
google-chrome --version
# Le résultat doit être Chrome 152.0.7977.82 ou supérieur

Comment l’exploit atteint la victime

Le déclencheur est du contenu web : une victime n’a qu’à visiter une page malveillante ou compromise pour que la tentative d’exploitation commence. Les attaquants distribuent ensuite les liens par tous les canaux usuels — courriels de phishing, publicités malveillantes, messages sur les réseaux sociaux, sites légitimes compromis. Google n’a pas divulgué les cibles ni les acteurs derrière l’exploitation active, mais le périmètre réel dépasse largement Chrome : tout navigateur Chromium embarque le même V8.

La retenue de Google sur les détails techniques n’est pas de la discrétion : elle est défensive. Tant que la majorité des utilisateurs n’a pas installé le correctif, publier le mécanisme revient à offrir aux opportunistes et aux botnets qui scrapent les divulgations un proof of concept prêt à l’emploi. C’est pourquoi le bulletin mentionne qu’un exploit « existe dans la nature » sans en dire plus.

Enfin, le correctif se déploie progressivement, sur plusieurs jours et semaines. Un administrateur ne peut donc pas supposer qu’un poste est protégé parce que la version est sortie : il doit vérifier la version installée — 152.0.7977.82 ou supérieure — et relancer le navigateur, car le correctif ne s’applique qu’après redémarrage. Pour un parc géré, la vérification passe par l’inventaire des navigateurs : un poste peut avoir Chrome à jour et un Edge resté sur une version antérieure, tous deux vulnérables par le même V8. Les outils de gestion d’entreprise — Chrome Enterprise, stratégies de groupe ou MDM — permettent de forcer une version minimale et de confirmer le redémarrage, là où la télémétrie et les journaux de filtrage web doivent traquer les domaines fraîchement enregistrés et les fausses invites de mise à jour.

Pourquoi V8 reste la surface numéro un

Les zero-day V8 se succèdent pour une raison structurelle : les compilateurs JIT troquent de la marge de sécurité contre de la vitesse. Plus TurboFan et Maglev deviennent rapides, plus les cas limites échappent aux tests — et plus les attaquants, souvent des groupes étatiques ou des vendeurs de surveillance commerciale, les trouvent rapidement. Google signale que le correctif sera déployé progressivement sur plusieurs jours : la fenêtre où un poste reste vulnérable n’est pas nulle.

C’est pourquoi la mise à jour du navigateur ne suffit pas comme défense. Une sortie de sandbox — le passage du processus de rendu au système — reste l’étape suivante de toute chaîne V8, et c’est là que la segmentation réseau, un EDR capable de signaler les anomalies du processus de rendu et l’isolation de site reprennent la main. La question n’est pas de savoir si un zero-day V8 reviendra, mais si le reste de la pile l’arrête.

Verdict

Pour les utilisateurs, ouvrez Aide → À propos de Google Chrome, laissez la mise à jour se télécharger et relancez le navigateur. Vérifiez que la version atteint 152.0.7977.82 ou supérieur.

Pour les administrateurs de parc, ne vous arrêtez pas à Chrome : contrôlez Edge, Brave, Opera et Vivaldi sur les postes gérés, et forcez le redéploiement si un navigateur traîne. Une faille V8 activement exploitée est un chemin d’attaque connu, pas une hypothèse.

Pour les équipes sécurité, traitez ce sixième zero-day comme le signal d’un invariant : la surface JIT ne cessera pas de produire des bugs. Le navigateur à jour est la première ligne, mais la segmentation, l’EDR et l’isolation de site restent la seule chose entre un exploit V8 et une compromission complète.

Références

Le brief cyber, chaque mardi

Les failles qui comptent, les correctifs à appliquer, en dix minutes de lecture.

Pas de spam. Désinscription en un clic.
à lire ensuite

Sur le même sujet

Un contournement d’authentification par rejeu laisse 22 000 serveurs Exchange exposés

Divulgué le 11 août 2026, CVE-2026-62911 permet à un attaquant disposant d’un accès de rejouer une authentification capturée pour élever ses privilèges sur Microsoft Exchange, et un PoC public circule déjà. Près de 22 000 serveurs restaient exposés fin août ; si vous êtes sur Exchange 2016 sans ESU, le correctif n’est pas une option, c’est la migration qui s’impose.

Une faille CVSS 10 exécute du code en root dans Kestra sans authentification

Le 2 septembre 2026, la CISA a inscrit CVE-2026-49869 au catalogue KEV : une injection de commandes CVSS 10 dans l’orchestrateur open source Kestra, causée par une comparaison de chemin qui laisse passer tout endpoint se terminant par « configs ». Passez en 1.0.45 ou 1.3.21 avant l’échéance fédérale du 5 septembre, puis vérifiez que l’instance n’a pas déjà servi de point d’entrée.

← Retour au fil

Tapez au moins deux caractères.

naviguer ouvrir esc fermer