Chrome vient de recevoir un correctif discret mais essentiel pour colmater une faille dans V8, son moteur JavaScript. Une mise à jour de routine en apparence, qui rappelle pourtant à quel point ce composant technique se retrouve régulièrement au cœur des correctifs de sécurité du navigateur.
Google a déployé une nouvelle version de Chrome pour corriger une vulnérabilité jugée sérieuse dans V8, le moteur chargé d’exécuter tout le JavaScript du web. Le problème, identifié sous la référence CVE-2025-13042, a été signalé début novembre par un chercheur indépendant, vite pris en charge par l’équipe de sécurité de Chrome. Le patch (142.0.7444.162/.163) est désormais disponible pour Windows, macOS et Linux, et vous devriez ne pas trop attendre avant de l’installer.
Un défaut d’implémentation plus sérieux qu’il y paraît
Pour résumer, CVE-2025-13042 correspond à ce que Google classe comme une inappropriate implementation dans V8. En pratique, ce type de faille correspond à un comportement inattendu du moteur lors de certaines opérations de gestion mémoire. Le moteur finit par lire ou écrire des données qui ne devraient pas être accessibles ou le sont au mauvais moment. Ce type de défaillance entraîne généralement un plantage du navigateur, mais il peut aussi provoquer une corruption de mémoire exploitable. Or, dans un contexte favorable à un attaquant, cette corruption peut devenir un tremplin pour l’exécution de code arbitraire, le contournement de protections internes ou l’accès à des zones sensibles de Chrome.
Comme toujours, Google ne publiera pas de détails tant que la majorité des utilisateurs et utilisatrices n’auront pas reçu la mise à jour. Le navigateur applique automatiquement le correctif mais nécessite un redémarrage pour activer la nouvelle version. Celles et ceux qui souhaitent vérifier leur installation peuvent consulter la page À propos de Google Chrome dans les paramètres.
À noter également que les personnes utilisant un navigateur basé sur Chromium, comme Edge, Brave ou Opera, devraient également vérifier leur version puisqu'ils intègrent le même moteur et reçoivent souvent des correctifs similaires avec un léger décalage.
Pourquoi V8 concentre encore autant de correctifs
Si ce genre de faille fait autant parler, ce n’est pas par hasard. Le moteur n’interprète plus simplement du JavaScript ligne par ligne comme autrefois, mais repose aussi sur un ensemble de techniques dites Just in Time (JiT), qui transforment le code à la volée pendant son exécution pour le rendre beaucoup plus rapide.
Pour y parvenir, le moteur observe le comportement du code, repère les schémas qui se répètent et produit sur mesure des versions optimisées qui collent à ce qu’il a observé. Cela fonctionne très bien dans la plupart des cas, mais V8 doit faire des paris pour accélérer l’exécution. Le moteur s’appuie sur ce qu’il a vu jusque-là pour supposer que certaines structures de données auront toujours la même forme ou que certaines opérations se dérouleront toujours de la même manière.
Cette logique d’optimisation explique pourquoi la surface d’attaque est particulièrement délicate. Si l’une de ces hypothèses se révèle fausse à un moment précis et qu’elle est mal gérée, la version optimisée du code peut se retrouver dans un état incohérent. Les vérifications de sécurité sont alors appliquées au mauvais moment ou sur une structure qui n’a plus la forme attendue. Le moteur peut mélanger des types de données, manipuler une zone mémoire qui n’était pas prévue ou réutiliser une valeur que le JavaScript ne devrait jamais pouvoir influencer. C’est exactement dans ces zones grises que naissent les failles les plus sensibles.
C’est aussi la raison pour laquelle ce type de vulnérabilité revient régulièrement dans les bulletins de Google. V8 évolue vite, bénéficie d’un flot continu de patchs et d’optimisations, et supporte un écosystème web qui ne cesse de s’enrichir. Chaque nouvelle fonctionnalité ou amélioration de performance représente potentiellement une surface d’attaque supplémentaire. Google s’appuie bien sûr sur une batterie d’outils de fuzzing (sortes de tests de stress automatisés bombardant le moteur de millions de données inhabituelles pour forcer des bugs méconnus à se manifester) et d’analyse mémoire pour détecter les erreurs avant qu’elles n’aient un impact, mais certaines échappent encore aux tests automatisés et ne sont repérées que lorsqu’un chercheur les signale. Vous savez donc ce qu'il vous reste à faire.
Source : Google
