- Google a publié une mise à jour du canal stable de Chrome pour desktop, qui inclut une faille zero-day liée au CSS identifiée sous le nom de CVE-2026-2441
- Google a confirmé que cette faille est activement exploitée dans des attaques réelles (in the wild), et les utilisateurs doivent mettre à jour immédiatement vers la dernière version afin de réduire les risques de sécurité
- La mise à jour est en cours de déploiement progressif pour Chrome sur Windows, macOS et Linux
Aperçu de la mise à jour du canal stable de Chrome
- Google a annoncé une mise à jour du canal stable (Stable Channel) de Chrome pour desktop
- Windows/macOS : 145.0.7632.75/76, Linux : 144.0.7559.75
- La mise à jour est déployée sur les plateformes Windows, macOS et Linux
- Elle sera appliquée progressivement via la mise à jour automatique
Vulnérabilité de sécurité CVE-2026-2441
- Cette version comprend une vulnérabilité de sécurité référencée sous CVE-2026-2441
- Il s’agit d’une faille zero-day survenant lors du traitement du CSS
- Google indique explicitement que cette faille est déjà exploitée dans des attaques réelles
Mesures recommandées aux utilisateurs
- Google recommande à tous les utilisateurs de mettre immédiatement Chrome à jour vers la dernière version
- Si la mise à jour automatique n’est pas encore terminée, il est possible d’effectuer la mise à jour manuellement
- L’installation de la dernière version permet de se protéger contre cette vulnérabilité
Déploiement et support
- La mise à jour est déployée progressivement via le canal stable
- Pour certains utilisateurs, l’application de la mise à jour peut prendre un certain temps
- L’équipe Chrome poursuit en continu les améliorations de sécurité et de stabilité
2 commentaires
J’ai fait la mise à jour, mais sur Mac la version est déjà montée jusqu’à 145.0.7632.110.
Il s’agit d’une vulnérabilité de type use-after-free qui peut aller jusqu’à la prise de contrôle du système lorsqu’un traitement de police dans le CSS continue d’utiliser une adresse invalidée ; il suffit donc d’ouvrir un site web pour être exposé. Apparemment, cette faille avait même déjà été exploitée.
Avis Hacker News
Une vulnérabilité use-after-free dans le CSS de Google Chromium a été découverte
Le problème permettrait à un attaquant distant de provoquer une corruption du tas via une page HTML malveillante, et pourrait affecter non seulement Chrome, mais aussi l’ensemble des navigateurs basés sur Chromium comme Edge ou Opera
Cela semble assez grave, et certains se demandent quel montant de bug bounty le chercheur a reçu
Vu l’effort nécessaire pour trouver une faille critique et produire un exploit reproductible, la récompense paraît bien trop faible
La plupart épinglent en effet une version précise de Chrome
Mais le fait qu’elle ait été « observée dans la nature » pourrait vouloir dire qu’une chaîne d’attaque incluant déjà un sandbox escape existe
Ne pas parvenir à éliminer ce type de bug dans les langages système du XXIe siècle serait honteux
Il doit encore y avoir ce genre de bugs cachés dans les coins obscurs du code de Chromium/Blink
Pour un projet aussi central, il faudrait une équipe dédiée à la vérification continue de l’ensemble du code
Investir dans ce durcissement de la sécurité aurait bien plus de valeur que d’ajouter des fonctions du type intégration avec un réfrigérateur intelligent
Avec des fuzzers suffisamment puissants, il ne doit presque plus rester de zones inaccessibles
L’expression « Use after free in CSS » fait un peu sourire
Il n’est pas évident de comprendre l’impact concret de cette vulnérabilité
Sans évasion de sandbox ni XSS, elle semble presque inoffensive, mais d’après le code PoC,
elle permettrait l’exécution de code arbitraire dans le processus de rendu, des fuites d’informations, le vol de cookies et de sessions, la manipulation du DOM, le keylogging et d’autres attaques
D’abord, un bug du moteur de rendu permet d’obtenir une exécution de code arbitraire à l’intérieur de la sandbox, puis un sandbox escape donne un contrôle complet sur le système
Cette vulnérabilité correspond à la première étape, et si elle a déjà été utilisée dans des attaques réelles, il est probable qu’une deuxième étape existe aussi
Il est surprenant de voir apparaître encore ce genre de vulnérabilités mémoire
On pourrait penser qu’il existe déjà des outils capables de produire des binaires vérifiés, comme avec les langages à sûreté mémoire
Le CSS est lui aussi devenu plus complexe, avec davantage de variables, de portée et de fonctionnalités de préprocesseur, au point qu’une extension « no-style » pourrait presque sembler nécessaire, à l’image de « no-script »
Certains se demandent si ce rapport relève d’une simple erreur ou d’une chaîne d’attaque en plusieurs étapes
Le vrai problème, c’est la couverture de test. Le codebase est tellement vaste qu’il est difficile d’obtenir une couverture complète, et c’est dans ces interstices que ce type de faille apparaît
Le CSS est au cœur du web, et le supprimer casserait presque tous les sites
En revanche, l’exécution isolée (isolation) pourrait être une alternative
Si la session du navigateur est diffusée depuis un serveur distant, même en cas de zero-day, seule l’instance distante serait affectée et non la machine locale
Ce n’est pas parfait, mais cela réduit la surface d’attaque dans une logique de défense en profondeur
La liste des outils de sécurité utilisés par l’équipe Chromium mentionnait AddressSanitizer, MemorySanitizer, libFuzzer, etc., et l’absence de OSS-Fuzz a été jugée intéressante
Certains veulent voir le code PoC une fois le correctif déployé
La blague selon laquelle il faudrait réécrire Chromium en Rust est revenue
En cherchant le CVE, certains ont trouvé une page d’issue, mais
elle affiche « Access is denied »
Elle semble être privée et accessible uniquement après connexion