Chrome 151 : sept UAF critiques CVE-2026-17650 à 17656

Les faits

Le 28 juillet 2026, Google a publié Chrome 151 dans son canal stable, accompagné d'un bulletin de sécurité de grande ampleur : 370 vulnérabilités corrigées, dont 7 classées critiques — toutes des use-after-free (UAF) dans des composants fondamentaux du moteur de rendu. Cette mise à jour représente l'une des plus importantes en nombre de correctifs dans un cycle Chrome, surpassant les records précédents établis lors des releases 148 et 149 de 2026. La version de référence est 151.0.7922.71 pour Linux, et 151.0.7922.71 ou 151.0.7922.72 pour Windows et macOS — les deux builds Windows/macOS sont équivalentes en termes de correctifs de sécurité.

Une vulnérabilité use-after-free (UAF) est une classe de faille mémoire qui survient lorsqu'un programme continue à utiliser un pointeur vers une zone mémoire après que celle-ci a été libérée (freed). Dans la gestion de mémoire dynamique (heap), après un appel à free() ou delete, la zone mémoire devient disponible pour réallocation. Si un pointeur dangling (orphelin) vers cette zone est encore utilisé, un attaquant peut potentiellement contrôler le contenu de la mémoire nouvellement allouée à cet emplacement — une technique appelée heap grooming ou heap feng shui — et ainsi détourner le flux d'exécution pour exécuter du code arbitraire avec les privilèges du processus Chrome.

Dans le contexte d'un navigateur web, les UAF sont particulièrement redoutables car les composants de rendu gèrent des millions d'objets mémoire dont le cycle de vie est complexe et hautement dynamique. Les 7 CVE critiques de Chrome 151 s'étendent de CVE-2026-17650 à CVE-2026-17656 et affectent les composants suivants : Compositing (CVE-2026-17650), le système de composition graphique qui gère la superposition des couches de rendu web ; Views (CVE-2026-17652), le framework d'interface utilisateur interne de Chromium gérant les éléments visuels du navigateur ; Skia (CVE-2026-17653), la bibliothèque graphique 2D open-source développée par Google utilisée pour le rendu de toutes les pages web sur toutes les plateformes ; et Ozone (CVE-2026-17656), la couche d'abstraction matérielle pour le rendu sur Linux et ChromeOS. Les CVE intermédiaires (17651, 17654, 17655) affectent d'autres composants internes dont les détails techniques n'ont pas encore été entièrement documentés dans les bulletins publics Google, conformément à la politique de divulgation différée du projet Chromium.

La criticité de ces UAF tient à leur vecteur d'attaque : AV:N/AC:L/PR:N/UI:R. En pratique, visiter une page web contenant du JavaScript ou du HTML spécialement conçu peut déclencher la corruption mémoire ciblée. L'interaction utilisateur requise (UI:R) se limite à l'ouverture d'une page web — un clic sur un lien de phishing, une publicité malveillante (malvertising) intégrée dans un site légitime, ou une iframe injectée dans un contenu compromis suffisent. Cette accessibilité réduit considérablement la barrière à l'exploitation comparé à des failles nécessitant un accès physique ou une interaction applicative complexe.

Le modèle de sécurité de Chrome repose sur le sandboxing des processus de rendu pour contenir les exploits : chaque onglet s'exécute dans un processus isolé avec des privilèges réduits (renderer process sandbox). Cependant, une UAF dans des composants proches du système comme Skia ou Ozone peut être chaînée avec d'autres primitives d'exploitation pour réaliser un sandbox escape — sortir du bac à sable et exécuter du code avec les privilèges du processus parent, voire du système. Des CVE antérieures comme CVE-2026-13780 (UAF dans ANGLE, mars 2026) ont démontré que ce type d'exploitation en deux temps est parfaitement réalisable par des acteurs étatiques (nation-state actors) et des groupes de cybercriminalité sophistiqués disposant de capacités de reverse engineering avancées.

La temporalité de la découverte mérite attention. CVE-2026-17656 (UAF in Ozone) a été rapportée à Google le 14 juin 2026, soit 44 jours avant la sortie du correctif le 28 juillet. Ce délai reflète la complexité du cycle de validation des correctifs Chrome, qui doit garantir la stabilité du navigateur sur un spectre très large d'environnements. Pendant cette fenêtre de 44 jours, le risque d'exploitation restait théorique pour les acteurs extérieurs à Google, mais le risque de divulgation accidentelle via des patches partiels en beta channel (qui sont analysés par des chercheurs en sécurité) est documenté dans la littérature de sécurité Chromium.

L'ampleur de cette release — 370 CVE contre une moyenne de 20 à 50 par cycle mensuel Chrome — s'explique par plusieurs facteurs. D'une part, une dette technique dans le traitement de rapports de bugs accumulés depuis plusieurs mois dans le système Chromium IssueTracker. D'autre part, l'intensification des programmes de bug bounty Chrome et de fuzzing automatisé (ClusterFuzz, OSS-Fuzz) que Google a considérablement renforcés en 2025-2026, permettant la détection d'un volume plus important de vulnérabilités avant qu'elles ne soient découvertes par des acteurs malveillants. Parmi les 363 vulnérabilités non critiques, on compte de nombreuses failles High incluant des UAF dans les composants Extensions, Payments et Media, ainsi que des heap buffer overflow, type confusion et out-of-bounds read.

Microsoft Edge, basé sur le même moteur Chromium open-source, est également affecté par ces vulnérabilités. Microsoft a publié des mises à jour Edge correspondantes dans les jours suivant la release Chrome 151. Les navigateurs basés sur Chromium — Brave, Opera, Vivaldi, et Samsung Internet — sont également concernés, leurs éditeurs respectifs ayant annoncé des mises à jour de rattrapage. L'historique montre que les UAF critiques dans les composants de rendu Chrome font l'objet d'exploits fonctionnels dans des délais de 2 à 4 semaines après la publication du correctif, notamment par des acteurs étatiques ayant les capacités de reverse engineering nécessaires. La fenêtre d'exposition active commence donc maintenant et ne se fermera que lorsque l'ensemble du parc sera mis à jour.

Aucune exploitation in-the-wild n'a été confirmée pour ces 7 CVE critiques au moment de la publication de Chrome 151. Cependant, selon les analyses publiées par GBHackers et CyberSecurityNews, le score EPSS (Exploit Prediction Scoring System) de CVE-2026-17656 (UAF in Ozone) est particulièrement élevé en raison de la maturité des techniques d'exploitation de ce composant, de la disponibilité de recherches publiques antérieures sur Ozone, et de l'intérêt historique des groupes APT pour les vulnérabilités Chrome liées au rendu graphique Linux/ChromeOS.

Impact et exposition

L'exposition est massive par nature : Chrome détient une part de marché mondiale d'environ 65 % sur les navigateurs desktop selon StatCounter (données juillet 2026). Tout utilisateur de Chrome antérieur à la version 151 — sur Windows, macOS ou Linux — est potentiellement exposé. Les environnements d'entreprise où les mises à jour Chrome sont gérées de façon centralisée (Google Admin Console, WSUS, déploiement MSI) peuvent accuser un délai de déploiement de plusieurs jours à semaines selon les politiques internes de validation, créant une fenêtre d'exposition collective significative.

Le vecteur d'exploitation le plus réaliste et le plus difficile à défendre est le malvertising : injection de code malveillant dans des réseaux publicitaires légitimes pour servir du contenu exploitant les UAF via des iframes ou des scripts. Ce vecteur ne requiert aucune interaction utilisateur au-delà de la visite du site — même un site de confiance peut involontairement servir du contenu malveillant si son réseau publicitaire est compromis. Les campagnes de spear-phishing ciblées peuvent également utiliser ces failles via des liens vers des pages d'exploitation spécialisées intégrées dans des emails d'apparence légitime.

Les organisations avec des politiques de navigation restrictives — proxies avec filtrage de contenu, sandboxing des sessions de navigation (Remote Browser Isolation, RBI), ou liste blanche d'URLs — réduisent significativement le risque d'exploitation via malvertising. Cependant, les composants affectés comme Skia peuvent être atteints via des ressources graphiques embarquées dans des documents Office, des emails HTML ou des fichiers PDF ouverts dans Chrome, sans nécessiter de navigation externe vers un site malveillant.

Recommandations immédiates

• Mettre à jour Chrome immédiatement : menu ⋮ > Aide > À propos de Google Chrome — la mise à jour est automatiquement téléchargée puis appliquée au redémarrage. Version cible : ≥ 151.0.7922.71
• Pour les parcs gérés : pousser immédiatement Chrome 151 via Google Admin Console (Chrome Browser Cloud Management), MECM/SCCM, Intune ou votre outil de gestion de configuration. Ne pas attendre le cycle de déploiement standard — traiter comme une urgence sécurité
• Vérifier et mettre à jour Microsoft Edge (Chromium), Brave, Opera et Vivaldi vers leurs versions intégrant les correctifs Chromium 151 correspondants
• Activer Enhanced Safe Browsing dans Chrome (Paramètres > Confidentialité > Sécurité) pour une couche de protection supplémentaire contre les pages d'exploitation connues
• Surveillance SOC : alerter sur les crashs anormaux répétés du processus Chrome renderer dans les logs EDR (processus chrome avec argument --type=renderer qui se termine de manière inattendue) — indicateur d'une tentative d'exploitation qui a déclenché un crash avant d'aboutir