Chrome 151 est arrivé avec une mise à jour de sécurité qui ne mérite pas le petit bouton « plus tard ». Le navigateur corrige 370 failles, dont sept classées critiques, tout en changeant deux détails qui peuvent casser des machines et du code. Le mot-clé principal est clair : Chrome 151 n’est pas une version cosmétique, c’est un gros rattrapage de sécurité.
Le volume impressionne, mais il faut éviter le sensationnalisme facile. Google ne dit pas que ces 370 bugs sont exploités dans la nature, et les détails de plusieurs failles restent masqués le temps que la majorité des utilisateurs installe le correctif. En revanche, laisser traîner une version 150 ou antérieure revient à repousser une mise à jour qui touche directement le moteur JavaScript, le rendu graphique, l’interface et le mécanisme de mise à jour.
Un correctif massif, pas un feu d’artifice marketing
La version stable de bureau annoncée le 29 juillet porte les numéros 151.0.7922.71 pour Linux, et 151.0.7922.71 ou .72 pour Windows et macOS. Le bulletin officiel de Chrome compte 7 failles critiques, 71 élevées, 170 moyennes et 122 faibles. Le total retombe bien sur 370 : pas de chiffre gonflé au passage, juste une pile de correctifs qui donne envie de vérifier la politique de mise à jour de ton parc.
Les sept failles critiques concernent surtout des zones où un contenu web malveillant peut faire très mal : use-after-free dans Compositing, Views, Skia et Ozone, validation insuffisante dans Dawn et ANGLE, ainsi qu’une condition de course dans l’outil de mise à jour. Ce ne sont pas sept trous identiques, mais ils ont un point commun peu rassurant : ils vivent dans les couches qui transforment une page web en pixels, en objets graphiques ou en processus à maintenir à jour.
La liste des correctifs n’est pas une preuve d’exploitation active. Le bulletin de Google ne signale pas que ces sept failles critiques sont utilisées contre les internautes. C’est précisément pour cela qu’il faut rester précis : patcher vite, oui ; inventer une campagne d’attaque, non. La sécurité adore les faits, même quand ils sont moins croustillants qu’un titre apocalyptique.
Visuel : capture des notes de version officielles de Chrome 151, publiée par Google. Source : https://developer.chrome.com/release-notes/151
Le navigateur ne se résume pas à V8
Quand on parle de faille Chrome, on pense souvent à V8, le moteur JavaScript. Cette fois, le correctif déborde largement du moteur : les composants graphiques, la composition des pages, la couche GPU et l’interface sont dans la liste. Un site n’a pas besoin de lancer un script exotique pour toucher ces zones ; il suffit que le navigateur traite des contenus web conçus pour provoquer un comportement inattendu.
Chrome 151 apporte aussi une évolution de sécurité moins spectaculaire mais intéressante : l’analyse XML passe à une implémentation Rust pour plusieurs scénarios courants qui n’utilisent pas XSLT. L’objectif annoncé est de réduire les risques liés à la corruption mémoire tout en gardant la compatibilité avec DOMParser, XMLHttpRequest.responseXML et certains documents SVG. Ce n’est pas une garantie magique, mais déplacer progressivement des parseurs sensibles vers un langage à sécurité mémoire est une stratégie cohérente.
Le reste de la version concerne aussi les performances et le Web moderne. Les entrées soft-navigation et interaction-contentful-paint donnent aux applications monopages de nouveaux repères pour mesurer les changements de contenu après une interaction. Les politiques d’accès aux sockets locaux deviennent plus granulaires. Pour les développeurs, ce sont des évolutions utiles ; pour les administrateurs, elles rappellent surtout qu’une mise à jour de navigateur peut modifier des comportements périphériques sans afficher un gros panneau rouge.
Deux pièges à vérifier avant le redémarrage
Premier piège : macOS 12 sort du train. Chrome 150 est la dernière version à prendre officiellement en charge Monterey. Chrome 151 continuera à fonctionner avec un avertissement, mais la machine ne recevra plus les mises à jour de sécurité ni les nouveautés. Si tu gères encore des postes sous macOS 12, le problème n’est donc pas seulement de cliquer sur « mettre à jour » : il faut planifier la migration du système ou accepter un navigateur figé.
Deuxième piège : new FontFaceSet() devient illégal. La suppression de l’ancien attribut LegacyNoInterfaceObject expose désormais FontFaceSet comme propriété globale, mais sans constructeur utilisable. Du code qui instancie directement new FontFaceSet() reçoit une TypeError. La bonne voie passe par document.fonts, pas par un bricolage qui espère que le navigateur fera semblant de ne rien voir.
Dans les environnements de développement, vérifie les images Docker qui embarquent Chrome, les agents Playwright ou Selenium et les postes de test macOS 12. Une mise à jour sur ton ordinateur ne corrige pas automatiquement un navigateur empaqueté dans une image de CI. Le maillon oublié n’est pas toujours le poste du développeur : c’est souvent le runner que personne ne redémarre parce qu’il « marche encore ».
Le cas CVE-2026-11645 rappelle pourquoi il ne faut pas attendre
Chrome 151 ne corrige pas à lui seul toutes les urgences Chromium. En juin, la CISA a ajouté CVE-2026-11645 à son catalogue des vulnérabilités exploitées : une lecture et écriture hors limites dans V8 pouvant mener à l’exécution de code dans le bac à sable via une page HTML spécialement conçue. Cette vulnérabilité est distincte du lot des sept failles critiques de Chrome 151, mais elle montre pourquoi le numéro de version et le catalogue de l’éditeur doivent être contrôlés ensemble.
La leçon pratique tient en trois vérifications. Sur un poste, ouvre la page d’aide de Chrome et confirme que la version est bien 151.0.7922.71 ou plus récente. Dans une flotte administrée, cherche les politiques qui bloquent le canal stable ou retardent les redémarrages. Dans les images de CI, reconstruis l’image et vérifie la version réelle à l’intérieur, pas seulement celle déclarée dans le fichier de configuration.
Un navigateur à jour, ça se prouve
Le déploiement de Chrome 151 doit être traité comme une opération de maintenance contrôlée : inventaire des versions, mise à jour progressive, vérification après redémarrage et surveillance des tests qui touchent les polices, les SVG, le rendu graphique ou les parcours monopages. Pour les postes anciens, la question du système d’exploitation passe avant celle du navigateur. Pour les développeurs, le vrai test est celui du code qui dépend d’API retirées, pas celui de la page d’accueil qui s’affiche correctement.
Google a publié un gros filet de sécurité. À toi de vérifier qu’il est bien accroché à toutes les fenêtres, y compris celles qui tournent dans un conteneur et celles que personne ne regarde.
Sources
Google Chrome Releases — Stable Channel Update for Desktop, 29 juillet 2026 : https://chromereleases.googleblog.com/2026/07/stable-channel-update-for-desktop_0887107924.html — décompte des 370 correctifs, versions et niveaux de gravité.
Chrome for Developers — Notes de version Chrome 151, 28 juillet 2026 : https://developer.chrome.com/release-notes/151 — date de sortie stable, XML en Rust, API de performance, fin de macOS 12 et retrait du constructeur FontFaceSet.
CISA — Ajout de CVE-2026-11645 au catalogue KEV, 9 juin 2026 : https://www.cisa.gov/news-events/alerts/2026/06/09/cisa-adds-three-known-exploited-vulnerabilities-catalog — contexte d’exploitation active d’une faille Chromium V8 distincte du lot Chrome 151.
Google Security — Stronger with every update: How we’re making Chrome and the web safer in the AI Era : https://blog.google/security/stronger-with-every-update/ — contexte sur la recherche de vulnérabilités et le durcissement continu de Chrome.
—
Recherche, relecture et illustration assistées par IA. Le contenu reflète le travail éditorial de la rédaction.
No comments yet