Chrome 153 corrige CVE-2026-87491, le septième zero-day V8 exploité de 2026

6 août 2026. Jihyeon Jeong, du Compsec Lab de l’université nationale de Séoul, signale à Google une écriture hors limites dans le moteur V8. 8 septembre 2026. Google publie Chrome 153, qui corrige 230 vulnérabilités, dont CVE-2026-87491. 9 septembre 2026. La CISA l’ajoute au catalogue KEV avec une échéance de correction au 23 septembre. Pourquoi c’est important : c’est le septième zero-day de Chrome activement exploité depuis janvier, et la simple visite d’une page piégée suffit à déclencher l’exploit.

Une écriture hors limites dans le moteur de tout Chromium

CVE-2026-87491 est classée CWE-787, écriture hors limites (out-of-bounds write), dans V8, le moteur JavaScript et WebAssembly de Chrome. Un attaquant distant livre une page HTML conçue pour l’occasion : lorsqu’un navigateur vulnérable la traite, la faille permet d’écrire au-delà de la région mémoire allouée et de corrompre l’état adjacent du programme, jusqu’à l’exécution de code arbitraire.

Deux nuances comptent. D’abord, Google qualifie la faille de sévérité moyenne dans sa propre échelle Chromium — le NVD n’a pas encore publié de score CVSS — mais confirme dans son avis qu’un exploit existe dans la nature. Ensuite, l’exécution se produit à l’intérieur du sandbox de Chrome, pas au niveau de l’hôte : passer de la compromission du navigateur à la compromission de la machine exige en principe une seconde faille, un sandbox escape, dont Google n’a pas révélé l’existence pour cette chaîne.

Cette nuance n’atténue pas l’urgence. Un exploit dans le sandbox donne déjà accès aux données et aux fonctions de la session du navigateur — cookies, jetons, mots de passe enregistrés, contenu des onglets — et constitue un premier étage classique d’une chaîne d’exploitation plus large.

Sept zero-days en neuf mois

La faille s’inscrit dans une série désormais bien documentée. CVE-2026-87491 est le septième zero-day de Chrome activement exploité que Google corrige depuis le début de l’année 2026. La cadence s’est nettement resserrée à l’approche de l’automne : le sixième (une confusion de types dans V8, CVE-2026-85046) datait du 4 septembre, cinq jours à peine avant.

Ce rythme n’est pas un bruit statistique. Le moteur V8 concentre une part disproportionnée de ces failles, pour une raison structurelle : c’est un composant écrit en C++, massivement optimisé pour la performance, où les just-in-time compilers manipulent directement la mémoire. Chaque optimisation ajoute une surface d’attaque, et les exploit developers suivent. Une faille de mémoire dans V8 touche tous les navigateurs fondés sur Chromium — pas seulement Chrome — ce qui en fait une cible à fort rendement.

L’arc complet de l’année est parlant. Le premier zero-day de 2026, CVE-2026-2441, était une utilisation après libération dans CSS, corrigée en urgence le 13 février dans Chrome 145. Entre les deux extrêmes, chaque faille confirmée a rejoint le catalogue KEV de la CISA. Sept zero-days en neuf mois, dont deux dans V8 à cinq jours d’intervalle : le rythme n’est plus un aléa, c’est une donnée d’exploitation pour qui planifie des correctifs.

Ce que change Chrome 153

Chrome 153.0.8010.36 est disponible pour Linux, et 153.0.8010.36/.37 pour Windows et macOS. La mise à jour ne se limite pas au zero-day : elle corrige 230 vulnérabilités au total, dont cinq de sévérité critique et quarante et une de sévérité élevée. C’est un correctif cumulatif massif, pas un patch ciblé.

Le correctif a suivi un chemin inhabituellement rapide vers l’action fédérale : la CISA a ajouté CVE-2026-87491 au catalogue KEV le 9 septembre, soit un jour après la publication du patch, et impose aux agences civiles fédérales américaines une correction au 23 septembre. Cette réactivité reflète la règle du catalogue KEV : seule une faille réellement exploitée y entre, et son délai est proportionnel à la menace.

Le délai de trente-trois jours entre le signalement du 6 août et le patch du 8 septembre mérite d’être noté. C’est un rappel que le responsible disclosure de Google prend du temps — et que, pendant ce délai, une faille déjà exploitée circulait sans correctif public.

Un navigateur, un périmètre

La fréquence des zero-days de Chrome reflète un basculement plus profond. Le navigateur est devenu le point d’entrée le plus rentable pour un attaquant : il exécute du code non maîtrisé en continu, il détient les jetons de session, les mots de passe enregistrés et l’accès aux applications internes, et il est présent sur chaque poste du parc. Un exploit par drive-by ne demande ni hameçonnage sophistiqué ni interaction élaborée — une page web suffit.

C’est pourquoi les équipes qui traitent le navigateur comme un simple « logiciel de plus » sous-estiment leur exposition. Le correctif de CVE-2026-87491 n’est pas un patch parmi d’autres : c’est la correction d’une faille dans le composant qui exécute la plus grande surface de contenu hostile de tout le système d’information.

Ce qu’il faut faire

Le correctif est simple, mais la vraie question est la couverture du parc.

• Mettez à jour Chrome maintenant. La version 153.0.8010.36 (ou .37 selon la plateforme) supprime la faille. Le navigateur se met à jour seul au redémarrage, mais un parc qui force la fermeture des onglets peut rester en retard de plusieurs jours.
• Étendez à tout Chromium. Edge, Brave, Opera, Vivaldi et les WebView embarquées partagent V8. Un inventaire qui ne couvre que Chrome laisse des failles ouvertes sur les autres navigateurs du parc.
• Priorisez les postes exposés à la navigation non maîtrisée. Les machines qui ouvrent des e-mails, des liens externes ou des pages web non contrôlées sont les premières concernées par une attaque par drive-by.
• Surveillez les symptômes. Sans indicateur de compromission publié par Google, la détection se limite à l’inventaire des versions et aux anomalies de processus Chrome — crashs répétés du renderer, terminaisons anormales — visibles dans la télémétrie des postes.

Un point de vigilance pour les équipes SOC : la faille seule ne s’évade pas du sandbox. Une compromission de poste complète passerait donc par une chaîne — CVE-2026-87491 en premier étage, puis une seconde faille. L’absence d’évasion documentée aujourd’hui ne signifie pas l’absence d’évasion demain.

Dans un parc géré, la mise à jour ne dépend pas de la bonne volonté des utilisateurs. Vérifiez la politique de mise à jour automatique de Chrome via GPO, Intune ou votre MDM : une règle qui autorise les redémarrages planifiés évite au parc de rester bloqué sur une version vulnérable pendant des semaines. Appliquez la même rigueur aux navigateurs Chromium tiers — Edge se gère via Microsoft, mais Brave, Opera et Vivaldi doivent être inventoriés et versionnés explicitement.

Verdict

Si vous gérez un parc de postes sous Chrome ou tout autre navigateur Chromium, forcez la mise à jour vers 153.0.8010.36 (ou .37) avant le 23 septembre et vérifiez l’inventaire des navigateurs V8 au-delà du seul Chrome : un zero-day V8 activement exploité est une menace pour l’ensemble de l’écosystème Chromium, pas pour un produit unique. Si votre politique impose des correctifs validés en retard, traitez cette mise à jour comme une exception d’urgence — la CISA l’a déjà fait en l’inscrivant au KEV, et un navigateur est l’application qui exécute le plus de contenu non maîtrisé de tout votre parc.

Références

• SecPod — CVE-2026-87491: Google Fixes 7th Exploited Chrome Zero-Day of 2026, 10 septembre 2026
• The Hacker News — Chrome V8 Zero-Day Exploited in the Wild Enables Code Execution Inside Sandbox, 9 septembre 2026
• Security Affairs — Google fixes the seventh actively exploited Chrome zero-day of 2026
• CISA — Known Exploited Vulnerabilities Catalog