Chrome 154 corrige 108 failles dont 11 critiques, toutes des bugs de mémoire

22 septembre 2026. Google commence le déploiement de Chrome 154 sur le canal stable, pour Windows, macOS et Linux. 29 septembre 2026. La base NVD et le CVE Brief publient la série de failles critiques associées, pour la plupart des use-after-free notées CVSS 9,6. 30 septembre 2026. Le CVE Brief place Chrome en tête des divulgations critiques du jour, avec huit failles à 9,6 publiées en une seule livraison. Pourquoi c’est important : un mois après le zero-day V8 exploité de Chrome 153, c’est cette fois une batterie de failles de mémoire qui atterrit d’un coup, et plusieurs permettent une exécution de code hors de la sandbox.

108 correctifs, 11 critiques

Le chiffre brut est déjà parlant : Chrome 154 embarque 108 correctifs de sécurité dans sa première promotion stable, dont 11 classés critiques par Google. Les builds concernés sont 154.0.8037.57 pour Linux et 154.0.8037.57 ou .58 pour Windows et macOS, avec des incréments ultérieurs jusqu’à 154.0.8037.92 au fil du cycle.

La répartition des failles critiques est remarquablement homogène : presque toutes sont des use-after-free ou des débordements de tampon, et elles se concentrent dans les couches graphiques et de rendu. CVE-2026-95350, CVE-2026-95281 et CVE-2026-95284 sont trois débordements de tampon dans ANGLE, le traducteur de shaders OpenGL ES, tous découverts par les chercheurs de STAR Labs SG. CVE-2026-102304 est un use-after-free dans le gestionnaire de mots de passe qui permet une exécution de code hors de la sandbox. CVE-2026-102306 touche Bluetooth, CVE-2026-102309 le plein écran, CVE-2026-102331 un débordement dans ANGLE sur Android, et CVE-2026-95277 la couche Views.

La mécanique d’exploitation est la même partout : une page HTML piégée, une interaction utilisateur, aucun privilège requis. C’est le vecteur le plus courant du web, et c’est précisément celui qu’un pare-feu ne peut pas bloquer.

Use-after-free : la classe qui ne meurt pas

Le use-after-free domine cette livraison, et ce n’est pas un hasard. Un use-after-free survient quand le programme libère une zone mémoire puis continue d’y accéder ; si un attaquant parvient à placer des données contrôlées à cette adresse entre-temps, il obtient de la corruption mémoire, puis potentiellement de l’exécution de code. La classe est structurellement liée au C++ et à la gestion manuelle de la mémoire, et elle représente depuis des années la première cause de failles critiques dans Chrome.

Google le sait. Depuis plusieurs versions, le navigateur migre progressivement des composants vers des langages sûrs en mémoire, et des mécanismes comme MiraclePtr ou l’isolation par site réduisent la surface exploitable. Mais cette livraison montre que le chantier est loin d’être fini : les couches ANGLE, GPU, WebGL, ServiceWorker et Views restent des réservoirs de failles, souvent héritées d’un code historique difficile à réécrire.

Le contraste avec le mois dernier

Le contraste avec septembre est instructif. 8 septembre 2026, Google publiait Chrome 153 avec 230 correctifs et un seul titre d’actualité : CVE-2026-87491, une écriture hors limites dans le moteur V8 déjà exploitée dans la nature, le septième zero-day de Chrome exploité en 2026.

Un mois plus tard, la forme du risque a changé. Chrome 154 n’a, à ce jour, aucune faille confirmée exploitée dans la nature — le CVE Brief du 30 septembre recense huit failles Chrome à CVSS 9,6, mais aucune ne figure dans le catalogue KEV de la CISA. En revanche, la quantité de failles critiques a explosé : on passe d’un zero-day isolé à une dizaine de failles critiques simultanées. Pour un défenseur, cela déplace la priorité du « corrigez cette faille-là » vers le « maintenez le parc à jour, en permanence ».

Le navigateur, angle mort du périmètre

Cette livraison rappelle une réalité que les équipes sécurité oublient volontiers : le navigateur est le composant le plus exposé et le plus difficile à contrôler du poste de travail. Un use-after-free dans le gestionnaire de mots de passe ou une faille hors sandbox contourne la séparation qui protège le système d’exploitation, et la simple visite d’un site suffit à l’amorcer.

La conséquence est opérationnelle. Chrome se met à jour automatiquement, mais le parc réel est hétérogène : Edge, Brave, Opera, Vivaldi et les webviews embarquées partagent le moteur Chromium et suivent leur propre calendrier. Une faille corrigée dans Chrome reste ouverte des jours, voire des semaines, dans un navigateur tiers ou une application qui embarque un Chromium vieillissant. La vérification doit porter sur tout ce qui rend une page web, pas seulement sur l’icône Chrome.

La migration mémoire, l’autre chantier

Si les use-after-free continuent d’affluer, c’est que la correction au coup par coup ne suffit pas. Google l’a compris et mène depuis plusieurs années un chantier de fond : réécrire les composants les plus exposés en Rust, généraliser MiraclePtr pour neutraliser une grande partie des use-after-free, et renforcer l’isolation par site pour contenir les dégâts d’une faille.

La réalité de cette livraison, c’est que les couches graphiques — ANGLE, GPU, WebGL — restent les plus perméables. Ces composants déplacent des tampons mémoire à des vitesses où la réécriture en langage sûr est difficile, et ils reçoivent en continu des données venues du web. Tant que cette migration n’est pas achevée, chaque version mensuelle continuera d’apporter son lot de failles de mémoire, et le use-after-free restera la classe dominante des critiques.

Pour le défenseur, cela change la doctrine. On ne « finit » jamais de patcher un navigateur : on le maintient à jour en continu, on limite les extensions aux seules indispensables, et on traite le Chromium embarqué — webviews, clients desktop, composants Electron — comme une surface à part entière, avec son propre calendrier de correctifs. Une faille hors sandbox dans la liste de ce mois-ci suffit à justifier cette rigueur.

À noter pour le suivi : la promotion stable s’étale sur plusieurs semaines, et les correctifs ne tiennent pas tous dans le build initial 154.0.8037.57. Les incréments ultérieurs, jusqu’à 154.0.8037.92, apportent des rustines supplémentaires. Vérifier la version exacte déployée — et non le seul numéro majeur 154 — fait partie du contrôle, car un parc qui se contente d’afficher « Chrome 154 » peut en réalité mélanger plusieurs niveaux de correctifs.

Verdict

Si vous gérez un parc d’entreprise, forcez la mise à jour vers 154.0.8037.57 ou supérieur et vérifiez dans la foulée Edge, Brave, Opera et les webviews : le correctif Chromium ne se propage pas tout seul. Si vous administrez des postes isolés ou hors gestion, planifiez un rattrapage manuel : aucune de ces failles n’exige de privilèges, et la présence d’une faille hors sandbox dans la liste élève le risque au-dessus du simple crash de navigation. Et si vous suivez les chiffres : surveillez moins le nombre de zero-day exploités que la dérive continue du use-after-free — c’est elle qui dit si la migration mémoire de Chrome progresse, ou si elle se contente de colmater.

Références

• Chrome Releases — Stable Channel Update for Desktop (Chrome 154)
• The Hack Academy — Chrome 154 security fixes: 108 in the Stable release
• Cyber Security News — Chrome Patches 108 Vulnerabilities Including Critical Flaws
• ByteIota — Chrome 154: 108 Patches, 11 Critical GPU and V8 Flaws
• CVE Brief — 30 septembre 2026