Le Prochain Jour Zéro de Chrome, Direction Bruxelles

Six Jours Zéro en Huit Mois, une Récompense de Mille Dollars

L'équipe Chrome de Google a publié les versions 152.0.7977.82 et .83 pour Windows et macOS, ainsi que 152.0.7977.82 pour Linux, les 3 et 4 septembre 2026, corrigeant CVE-2026-85046, une faille de confusion de type dans le moteur V8 de JavaScript et WebAssembly que Google a confirmée comme déjà exploitée dans la nature. Cette faille permet à une page web conçue à cet effet de tromper le compilateur de V8 pour qu'il accorde à un attaquant un accès en lecture et en écriture arbitraire sur le tas mémoire du navigateur, ouvrant ainsi une voie vers l'exécution de code à distance à l'intérieur du bac à sable de Chrome. Le chercheur Salvatore Gulizia a signalé la faille le 4 août 2026 et a reçu une récompense de 1 000 dollars; Google a retenu les détails techniques jusqu'à ce que le correctif ait atteint la majorité des utilisateurs, une pratique habituelle pour une faille activement exploitée. Il s'agit du sixième jour zéro de Chrome activement exploité corrigé en 2026, et chacun d'entre eux a obtenu un score CVSS de 8,8 et a nécessité un correctif d'urgence en dehors du cycle de publication normal de Chrome.

Huit Jours Avant que l'Horloge ne Démarre

Le calendrier de Google révèle lui-même l'écart qui compte: l'entreprise a divulgué et corrigé CVE-2026-85046 les 3 et 4 septembre, huit jours avant la date d'entrée en vigueur de l'article du Cyber Resilience Act de l'UE qui aurait exigé un rapport formel pour exactement ce type d'événement. À partir du 11 septembre 2026, l'article 14 traite les logiciels comme Chrome comme des produits comportant des éléments numériques, et dès qu'un fournisseur apprend qu'une vulnérabilité est activement exploitée, il doit envoyer un avertissement précoce à un point de contact national et à l'ENISA, l'agence de cybersécurité de l'UE, dans les 24 heures, une notification plus complète sous 72 heures, puis un rapport final dans les 14 jours suivant la disponibilité du correctif. Si Google avait découvert et divulgué la même faille le 12 septembre plutôt que le 3, la même séquence - un chercheur signalant une faille V8, Google confirmant une exploitation dans la nature, puis Google publiant un correctif d'urgence - serait devenue le premier véritable cas d'application du Cyber Resilience Act plutôt qu'un simple avis de routine. Six jours zéro de Chrome exploités sur huit mois en 2026 font d'un septième, survenant une fois que les dents du texte seront en place, une question de moment plutôt que de probabilité.

La Règle de Décision pour Quiconque Gère la Politique de Correctifs

La leçon pratique pour toute entreprise européenne n'est pas d'attendre une déclaration réglementaire pour apprendre l'existence du prochain jour zéro de Chrome, car les notes de version de Google elles-mêmes indiquaient que les versions corrigées continueraient d'être déployées durant les jours et semaines suivants même une fois le correctif disponible, ce qui signifie que la vitesse de la mise à jour automatique, et non celle de la divulgation, détermine la durée d'exposition d'un parc d'ordinateurs portables. Quiconque gère la politique des postes de travail devrait considérer ce sixième jour zéro de l'année comme un taux de base, et non comme une anomalie: avec six incidents survenus à intervalles d'environ six à sept semaines tout au long de 2026, la posture correcte consiste en un processus permanent qui compare chaque semaine les versions de Chrome installées à la dernière version stable, plutôt que de faire confiance à une mise à jour automatique de chaque machine selon le calendrier prévu. Une fois l'horloge du Cyber Resilience Act enclenchée, une équipe informatique basée dans l'UE gagne aussi un nouveau signal à surveiller: l'historique des déclarations d'un fournisseur à l'ENISA devient un indicateur approximatif de la fréquence à laquelle ses produits sont réellement attaqués activement, plus concret qu'une promesse marketing de sécurité de niveau professionnel, et qu'il vaut la peine de vérifier avant un renouvellement, pas après un incident.

À lire ensuite: SonicWall SMA1000: failles déjà exploitées activement  |  Aucun Régulateur UE Ne Contrôle L'Accès À Astra