Chrome file vers la 154. Ton Chromebook, lui, est resté au 19 août

Sommaire

• Chrome file sur la 154, ton Chromebook regarde passer les trains
  • Les correctifs ChromeOS n’ont pas suivi, et l’écart se chiffre
  • Le 19 août, les correctifs ChromeOS sont sortis déjà en retard
  • Ce que je ne peux pas te dire
  • Correctifs ChromeOS : ce qu’il faut surveiller cette semaine
• Notes de bas de page :
  • Partager :

Deux minutes. Il faut qu’on parle de l’horloge interne de Google. Elle semble cassée. Autrement dit, comme un ressort qui s’est détendu. Vendredi 21 août, la firme a poussé deux billets sur son blog officiel. Le canal Dev de Chrome passe sur la branche 154. C’est fait pour les ordinateurs. C’est fait pour Android. Et devine quoi ? Aucun détail croustillant. Ensuite, aucune explication claire. Juste un renvoi sec vers le journal Git. Débrouille-toi avec ça, dit Google. Pendant ce temps, ton Chromebook attend sagement dans son coin. Il attend depuis le 19 août, pourtant. Et les fameux correctifs ChromeOS ? Ils ne sont jamais arrivés. Le décalage devient gênant. Google trace sa route et laisse son propre système d’exploitation dans le rétroviseur. On fait les comptes

Chrome file sur la 154, ton Chromebook regarde passer les trains

Fais le compte avec moi. Au petit matin du 22 août, le canal Dev tourne en 154.0.8013.2 sur ordinateur. Puis il affiche 154.0.8013.0 sur mobile. Ensuite, le canal Beta se prélasse sur la 153 depuis le 20 août. Le Stable de bureau, lui, parade en 151.0.7922.173 et .174. Publié le 20 août également. Ainsi, trois branches. Trois étages bien rangés. Tout est propre.

Et ChromeOS dans tout ça ?

ChromeOS Stable stagne en 16733.54.0. Sorti le 19 août. Ensuite, c’est le silence radio, tout simplement. Le navigateur embarqué porte le numéro 151.0.7922.168. Retiens bien ce nombre. D’ailleurs, on va y revenir très vite. Le dernier billet ChromeOS de n’importe quel canal remonte à ce fameux 19 août, précédé du Beta le 18. Depuis, rien. Pas la moindre petite ligne.

Alors non, le blog n’est pas en vacances. Google a bien publié deux billets le 21 août. Deux billets dédiés à Chrome. Zéro billet pour ChromeOS. La rédaction de Mountain View travaillait. Elle n’avait simplement rien à dire sur ton système. Nuance importante, et je vais y insister toute la semaine s’il le faut. Une absence démontrée par une maison en activité, ce n’est pas la même chose qu’un blog endormi. Est-ce délibéré ? Je n’en sais rien et je ne le prétendrai pas. En revanche, le résultat est le même pour toi.

Les correctifs ChromeOS n’ont pas suivi, et l’écart se chiffre

Reprenons ce fameux .168. En effet, c’est la version de Chrome qui tourne dans ton Chromebook depuis mercredi. Or, le 18 août, Google publiait une mise à jour pour les ordinateurs. Les versions 151.0.7922.169 et .170. Quinze correctifs de sécurité au total. Dont deux classés critiques, d’emblée. Un débordement de tampon ¹dans WebGL. Un autre dans Dawn. Ensuite arrive le 20 août. Google remet une pièce dans la machine. Les versions .173 et .174 tombent. Donc sept correctifs de plus. Dont un critique. Cette fois, c’est une utilisation après libération² dans Chromoting. Le composant de bureau à distance, pour être précis.

Donc additionne. Quinze plus sept. Voilà l’écart exact que les correctifs ChromeOS n’ont toujours pas comblé.

Ces trois failles critiques ont un petit nom public. CVE-2026-76034. CVE-2026-76036. CVE-2026-76017. De plus, elles touchent le rendu graphique et le bureau à distance. Autrement dit, des morceaux que ton Chromebook utilise en permanence.

Un point d’honnêteté s’impose. Je ne suis pas là pour te faire peur au kilomètre. Google n’indique aucune exploitation dans la nature pour ces failles. Autrement dit, personne ne s’en sert contre toi ce matin. À la connaissance de Google, du moins. Trois d’entre elles ont d’ailleurs été trouvées par des chercheurs externes, payés pour ça, avant les méchants. Le système de prime aux chercheurs fonctionne. Jusque-là. Touchons du bois.

Le 19 août, les correctifs ChromeOS sont sortis déjà en retard

Et là, on tient le détail qui pique vraiment. Le correctif de bureau du 18 août fait passer Chrome de .168 à .169. Donc le 18 au soir, le .168 est officiellement dépassé. Totalement périmé. Avec quinze trous documentés dedans. Deux critiques inclus. Puis, le lendemain 19 août, Google publie ChromeOS Stable. Et que met-il dedans, ce génie ?

Le .168.

Ta machine a reçu une mise à jour de sécurité le mercredi. Elle contenait un navigateur déclaré obsolète le mardi. Ce n’est pas un retard de déploiement. Ce n’est pas non plus un serveur trop lent. C’est la version qui était déjà en retard le jour de sa sortie. Voilà comment on se retrouve à vingt-deux correctifs d’écart en quatre jours. Sans que personne n’ait rien fait de mal. Formidable. Le canal Beta raconte exactement la même histoire. En plus discret. ChromeOS Beta est sur Chrome 152 depuis le 18 août. Le Beta de bureau, lui, est passé à 153. Un cran de retard là aussi. Par ailleurs, ça n’a rien d’accidentel. ChromeOS a toujours eu son propre calendrier. Ses validations matérielles. Ses contraintes de pilotes. C’est le prix de l’intégration.

Ce que je ne peux pas te dire

Maintenant, voici la partie où je refuse de te raconter n’importe quoi. Un numéro de version n’est pas un inventaire complet. Google pratique très couramment le rétroportage³. Ils reprennent un correctif écrit pour une branche récente. Ils le glissent dans une branche plus ancienne. Sans changer le grand numéro devant. Il est donc parfaitement possible qu’une partie de ces correctifs soit déjà dans ta machine. Tranquillement. Sans que rien ne l’annonce.

Possible, donc. Mais absolument pas documenté.

Et c’est exactement là que le bât blesse. On ne reproche pas ici à Google d’exposer bêtement ses utilisateurs. On lui reproche de ne pas dire ce qu’il fait. Le billet ChromeOS du 19 août liste des correctifs. Il ne dit pas lesquelles des failles de bureau sont couvertes. Ni lesquelles ne le sont pas. En face, cependant, le billet de bureau aligne ses CVE une par une. Avec sévérité et composant. Deux standards de transparence chez le même éditeur. Pour le même moteur. Les correctifs ChromeOS restent une boîte noire. Ceux du bureau, non. Cherche l’erreur.

Donc quand tu liras quelque part que ton Chromebook a vingt-deux failles béantes, méfie-toi. Ce n’est pas prouvé. Ce qui est prouvé, c’est qu’aucun document public ne permet de dire le contraire. La charge de la preuve est du mauvais côté.

Correctifs ChromeOS : ce qu’il faut surveiller cette semaine

Regarde bien la cadence. ChromeOS Stable est passé en 16733.48.0 le 13 août. Puis en 16733.54.0 le 19. Six jours d’écart. En résumé, au même rythme, le prochain tombe autour du 25 août. Soit en début de semaine prochaine. Ainsi, le vrai test est là. Si ce prochain Stable embarque d’un coup un navigateur en .173 ou au-delà, l’écart se referme. L’histoire s’arrête. Si le billet détaille enfin quelles CVE de bureau sont couvertes, alors Google aura corrigé son problème. J’écrirai un papier pour le dire. Si j’ai le temps. Cependant, s’il sort encore avec une base périmée et sans liste, on ne parlera plus d’un accident. On parlera d’une méthode.

D’ici là, tu peux faire une chose utile. Elle prend dix secondes. Ouvre chrome://version sur ton Chromebook. Note le numéro. Compare-le au .168. Si tu es en dessous, ta machine n’a même pas reçu la mise à jour du 19 août. Et là on ne discute plus de rétroportage. On discute d’un déploiement qui traîne. Enfin, un redémarrage règle souvent l’affaire. Pour le reste, patience. Les correctifs ChromeOS finiront bien par tomber. Le canal Dev, lui, est déjà sur la 154. Il paraît que c’est l’avenir. Ton Chromebook le découvrira en temps voulu.

Notes de bas de page :

1. Débordement de tampon. Un programme écrit plus de données que la case mémoire prévue ne peut en contenir, et déborde sur la case voisine. Selon ce qui se trouve à côté, ça va du plantage à l’exécution de code choisi par l’attaquant. ↩︎
2. Utilisation après libération, ou « use-after-free ». Le programme rend une zone mémoire au système, puis continue de s’en servir comme si de rien n’était. Un attaquant qui parvient à occuper la place entre-temps décide de ce que le programme va lire, ou exécuter. ↩︎
3. Rétroportage, ou « backport ». Reprendre une correction écrite pour une version récente d’un logiciel et l’appliquer à une version plus ancienne encore maintenue. Pratique courante et saine, mais invisible depuis le numéro de version, qui ne bouge pas forcément. ↩︎