Chrome 150 et Firefox 152 : les failles critiques à patcher sans attendre

À la mi-juillet 2026, Mozilla et Google ont publié coup sur coup deux mises à jour de sécurité majeures pour leurs navigateurs. Firefox 152.0.6 corrige deux failles critiques dont le code d'exploitation est déjà public. Chrome 150.0.7871.124 referme de son côté 15 vulnérabilités, dont deux failles critiques logées dans le moteur de rendu Ozone. Si vous gérez un parc de postes en entreprise, ce type d'advisory ne doit pas attendre le prochain cycle de maintenance planifié : il appelle une action immédiate.

Chrome et Firefox concentrent l'essentiel du trafic professionnel en France, que ce soit pour accéder à vos outils SaaS, à votre ERP en ligne ou à votre messagerie webmail. Une faille critique dans le moteur JavaScript ou dans l'isolation des sites ouvre potentiellement la porte à de l'exécution de code à distance ou à du vol de données entre onglets, sans que l'utilisateur n'ait besoin de faire quoi que ce soit d'autre que de consulter une page piégée. C'est ce qui rend ces correctifs prioritaires, même en l'absence d'exploitation confirmée en conditions réelles pour l'instant.

Ce que corrige Firefox 152.0.6

Mozilla a publié Firefox 152.0.6 pour boucher deux failles classées critiques :

• CVE-2026-15718 : un pointeur invalide dans le composant JavaScript : WebAssembly.
• CVE-2026-15719 : un problème d'isolation de site dans le composant DOM : Navigation.

Pour ces deux vulnérabilités, Mozilla indique avoir connaissance de code d'exploitation rendu public, tout en précisant n'avoir observé aucune attaque en cours exploitant ces failles. C'est précisément ce type de situation, faille critique doublée d'un exploit public, qui justifie un déploiement en urgence plutôt qu'une mise à jour au fil de l'eau.

Ce que corrige Chrome 150

Google a de son côté publié Chrome 150.0.7871.124 et .125 pour Windows et macOS, et 150.0.7871.124 pour Linux. Le correctif comble 15 vulnérabilités au total :

• Deux failles critiques de type use-after-free dans Ozone, la couche d'abstraction graphique de Chrome sur Linux : CVE-2026-15764 et CVE-2026-15765.
• Douze failles de sévérité haute réparties dans Skia, Libyuv, le rendu HTML dans Canvas, le theming de la boîte à outils Linux, V8, Media, GPU, Core et l'UI. Les types de bugs vont de l'usage de mémoire non initialisée au dépassement de tampon sur le tas, en passant par un contrôle de politique insuffisant, une validation insuffisante d'entrées non fiables et d'autres cas de use-after-free.

Sur ces 15 failles, seules trois ont été signalées par des chercheurs externes. Les autres ont été découvertes en interne par les équipes de Google, qui n'a pas encore communiqué les montants de bug bounty versés. Contrairement à Firefox, aucune des failles Chrome n'est signalée comme exploitée ni comme disposant d'un exploit public à ce jour.

La checklist pour sécuriser votre parc dès maintenant

Voici les étapes à dérouler, dans l'ordre, si vous êtes responsable IT, DSI ou simplement en charge des postes de votre équipe.

• Vérifiez la version installée sur chaque poste. Sous Chrome : chrome://settings/help. Sous Firefox : about:preferences puis « À propos de Firefox ». Vous visez au minimum Chrome 150.0.7871.124 (125 sous Windows et macOS) et Firefox 152.0.6.
• Forcez la mise à jour si l'auto-update est désactivé. Sur un parc géré par GPO, la console d'administration Google ou Microsoft Intune pour Chrome, ou par le fichier policies.json pour Firefox, poussez la politique de mise à jour immédiatement plutôt que d'attendre le prochain cycle mensuel.
• Priorisez Firefox si votre parc en dépend. Le code d'exploitation des deux failles Firefox étant déjà public, ce sont les postes équipés de ce navigateur qui présentent le risque le plus immédiat, même en l'absence d'attaque confirmée pour l'instant.
• Redémarrez complètement le navigateur après mise à jour. Une mise à jour téléchargée mais non appliquée, parce que l'utilisateur garde ses onglets ouverts en permanence, ne protège personne. Fermez toutes les fenêtres, pas seulement l'onglet actif.
• Consignez le correctif dans votre registre de vulnérabilités interne. Utile pour vos audits de conformité et pour tracer le délai réel entre publication du correctif et application sur le parc, un indicateur que les auditeurs sécurité regardent de près.

Notre lecture chez CZSyn

Ce type d'annonce tombe presque chaque mois, et c'est justement le problème : la régularité finit par banaliser l'urgence. Beaucoup de PME françaises appliquent scrupuleusement leurs correctifs Windows ou macOS, mais laissent les navigateurs se mettre à jour tout seuls, sans jamais vérifier que l'auto-update fonctionne réellement sur l'ensemble du parc. Un poste en veille prolongée, un profil Chrome géré avec des restrictions héritées, ou un pare-feu qui bloque les serveurs de mise à jour de Mozilla, et vous vous retrouvez avec des navigateurs vulnérables des semaines après la publication du correctif, sans même le savoir.

Notre recommandation pour une PME de taille moyenne : centralisez la supervision des versions de navigateurs comme vous le faites déjà pour les systèmes d'exploitation, avec une alerte dès qu'un poste dépasse un seuil de retard défini. Ce n'est pas une question de budget, c'est une question de discipline opérationnelle. Et dans le cas présent, avec un exploit Firefox déjà public, ce n'est clairement pas le moment de laisser traîner.

Sources primaires

• SecurityWeek, « Critical Vulnerabilities Patched With Fresh Chrome 150, Firefox 152 Updates ».
• Google, blog officiel des versions Chrome, chromereleases.googleblog.com.
• Mozilla, avis de sécurité officiels, mozilla.org/security/advisories.