Chrome 155 est arrivé avec 247 correctifs de sécurité

Chrome 155 est arrivé sur le canal Stable le 6 octobre 2026. L’annonce de version indique 247 correctifs de sécurité, dont quatre classés critiques. C’est un lot inhabituellement important, même pour le rythme de deux semaines qu’a adopté Chrome avec Chrome 153.

Cet article couvre ce que la version dit, ce qu’elle laisse ouvert, et pourquoi le rythme des correctifs d’un navigateur fait partie de la routine de quiconque exploite un formulaire.

Ce qui est sorti

La version de bureau est 155.0.8059.39/.40 sous Windows et macOS, et 155.0.8059.39 sous Linux. Chrome 155 est aussi arrivé sur Android et iOS. Il est arrivé en deux temps : une petite part des utilisateurs de Windows et macOS a reçu 155.0.8059.26/.27 le 30 septembre, puis le déploiement plus large a commencé le 6 octobre. Chrome 156 est entré dans le canal Beta le 30 septembre.

L’annonce de Google précise que l’accès aux détails des bogues et à leurs liens reste restreint jusqu’à ce que la majorité des utilisateurs ait reçu le correctif, et qu’il le reste plus longtemps lorsque la faille se trouve dans une bibliothèque tierce dont dépendent aussi d’autres projets.

La répartition par gravité dans l’analyse secondaire est de quatre critiques, 53 élevées, 122 moyennes et 68 faibles. Comparé à la précédente mise à jour de bureau, qui portait 11 correctifs, c’est une version qui change beaucoup de choses d’un coup.

Les quatre bogues critiques

Les quatre entrées critiques sont des bogues use-after-free, une classe où la mémoire est libérée alors que quelque chose en détient encore un pointeur. Google les énumère par composant et par CVE.

• Chromecast : CVE-2026-106382, signalé par Google.

• Browser : CVE-2026-106197, signalé par Xinyang Ge.

• Navigation : CVE-2026-106358, signalé par Xinyang Ge d’Anthropic, avec l’aide de Claude.

• Track : CVE-2026-106347, signalé par Xinyang Ge d’Anthropic, avec l’aide de Claude.

Un use-after-free dans Navigation ou Track compte pour quiconque a une page qui envoie un formulaire, parce que les deux se trouvent sur le chemin que parcourt le navigateur lorsqu’un visiteur passe d’une page à l’autre et qu’une soumission est envoyée. C’est une raison de se soucier du correctif. Ce n’est pas une affirmation que quelque chose sur votre page était cassé.

Pourquoi ce rythme fait partie de votre routine

Chrome publie désormais toutes les deux semaines. Un formulaire qui reçoit des soumissions via un composant généré s’exécute dans le navigateur que le visiteur a apporté, et vous ne contrôlez pas ce navigateur. Ce que vous contrôlez, c’est la vitesse à laquelle vos propres machines prennent le correctif, et si quelqu’un lit les notes de version.

Deux habitudes couvrent l’essentiel. Mettez à jour les navigateurs que votre équipe utilise. Puis notez ce que vous testez après chaque version de navigateur : une soumission depuis un navigateur de bureau, une depuis un téléphone, et une page hébergée ouverte à froid. C’est une routine moins coûteuse que d’apprendre un changement de rendu par la plainte d’un expéditeur.

Ce que cela ne tranche pas

• Cela ne dit pas qu’un bogue a été exploité. L’annonce de Google n’indique pas que l’une des 247 vulnérabilités ait été utilisée, et les détails des quatre bogues critiques restent restreints.

• Cela ne dit pas que FormFlow a été touché. Rien ici n’affirme que FormFlow, ses pages hébergées ou son composant généré étaient vulnérables, ont été testés contre Chrome 155, ou ont changé à cause de cette version.

• Cela ne dit pas que votre formulaire fonctionne sous Chrome 155. Savoir si votre page s’affiche et s’envoie correctement est une question pour votre propre test, sur votre propre page.

Lisez le nombre de correctifs comme la taille de la maintenance, pas comme une mesure du danger. L’action utile est la même dans les deux cas : mettre à jour, puis tester la seule page dont vous dépendez.