Google a déployé Chrome 155 (versions 155.0.8059.39/.40 pour Windows et macOS, 155.0.8059.39 pour Linux) avec 247 correctifs de sécurité — plus du double du précédent déploiement pour le bureau (108 dans Chrome 154). SecurityWeek en a fait état le 7 octobre 2026.
Parmi ces correctifs figurent quatre vulnérabilités critiques de type use-after-free :
- CVE-2026-106382 (Chromecast),
- CVE-2026-106197 (Navigateur),
- CVE-2026-106358 (Navigation),
- CVE-2026-106347 (Track).
Google n’a signalé aucune exploitation connue en milieu réel (in-the-wild), mais ces quatre vulnérabilités critiques — dont plusieurs pourraient affecter les limites du sandbox — justifient une mise à jour et un redémarrage rapides de la flotte.
La répartition des CVE par gravité est approximativement la suivante :
- 4 Critiques,
- 53 Élevées,
- 122 Moyennes,
- 68 Faibles.
Les classes de vulnérabilités les plus courantes sont :
- autorisation incorrecte (41),
- use-after-free (34),
- autorisation manquante (34),
- représentation trompeuse de l’interface utilisateur (20),
- fuite d’informations (17),
- ressource non initialisée (16).
Parmi ces bugs, 62 ont été signalés par des chercheurs externes. Google a versé environ 33 000 $ en récompenses pour les rapports déjà divulgués, tandis que les montants pour près de 50 signalements restent en attente.
Un détail notable : la chercheuse Xinyang Ge (Anthropic) a rédigé de nombreux rapports High/Critical, et plusieurs lignes de crédits mentionnent "assistée par Claude". Deux des quatre rapports critiques (Navigation et Track) ont été identifiés comme ayant bénéficié d’une assistance par l’IA. Cela reflète une tendance plus large de la recherche sur les vulnérabilités **assistées par l’IA**, accélérant les découvertes — la même semaine, les preuves de concept (PoC) pour LMCache et Atlassian dominent l’actualité.
Pour les utilisateurs et les équipes IT : la mise à jour « sera déployée au cours des prochains jours/semaines », il faudra peut-être utiliser `chrome://settings/help` pour forcer une vérification. Dans les flottes gérées, le téléchargement seul ne suffit pas — les navigateurs doivent être redémarrés. Edge et d’autres navigateurs Chromium suivent souvent ; inventoriez-les séparément. Même sans exploitation sauvage signalée, l’histoire montre que les vulnérabilités critiques de Chrome deviennent rapidement des cibles une fois que les détails sont rendus publics.
Les livraisons de 247 CVEs en une seule fois sollicitent également la communication des correctifs : de nombreuses organisations ne priorisent que les « zero-day en milieu sauvage ». Ici, le signal de « milieu sauvage » est absent, mais le volume élevé, ainsi que les quatre UAF critiques — y compris celles liées à la Navigation/Navigation Web — suffisent pour traiter Chrome 155 comme une fenêtre de sécurité obligatoire à appliquer la même semaine.
Les découvertes assistées par l’IA modifient également le calendrier : les chercheurs peuvent produire plus rapidement des problèmes Hautement critiques, rendant les mises à jour rapides et fréquentes plus importantes que les reconstructions d’images trimestrielles.
Pour les équipes de forensique et de gestion des incidents (IR), le navigateur reste une voie d’accès initiale courante via des attaques par drive-by et des documents malveillants. Une flotte bloquée sur la version 154 après la sortie de la 155 laisse une surface d’attaque inutilement exposée, alors que les histoires liées à Atlassian et les attaques en chaîne de fourniture (supply-chain) captent déjà l’attention des équipes SOC. Coordonnez les mises à jour du navigateur avec d’autres actions critiques pour éviter que le déploiement de « Chrome uniquement » ne soit reporté au week-end.
Que doivent faire maintenant les responsables IT et sécurité ?
Mettre à jour Chrome à ≥155.0.8059.39 (Windows/Mac également .40) et vérifier le redémarrage sur chaque client. Dans Intune/GPO/Jamf : suivre la conformité et bloquer les versions antérieures. Vérifier les produits dérivés basés sur Chromium.
Prioriser les machines navigant sur des sites non fiables ou disposant de privilèges élevés. Informer les utilisateurs de quitter complètement et rouvrir le navigateur après la mise à jour — sinon, les vulnérabilités critiques de UAF restent en mémoire.
Ajouter un contrôle hebdomadaire : partager le pourcentage de clients à jour sur la version 155+ dans les 72 heures. Traiter un redémarrage manquant comme une mise à jour manquante dans les rapports de conformité.
Confirmer que la mise à jour automatique est activée pour les points d'extrémité non gérés lorsque la politique le permet.
Définir un SLA de 72 heures pour la correction critique des navigateurs dans les procédures SOC et suivre les cas particuliers dans les OU. Vérifier que les Chromebooks et les pools VDI reçoivent la même version, et pas seulement les clients Windows physiques.