Un auditeur plus intelligent trouve davantage de bugs. Cela ne change pas le fait que le moteur de rendu reste un parseur de 35 millions de lignes exposé à des octets adverses. La bonne réaction à Mythos n'est ni le soulagement, ni l'effroi — c'est de continuer à concevoir comme si le prochain bug était celui qui passera.

Le 21 avril, Mozilla a publié un billet intitulé « The zero-days are numbered » (« Les jours des zero-days sont comptés »). La fondation y confirmait que Firefox 150 avait été livré avec 271 correctifs de sécurité découverts lors de l'évaluation d'une version précoce de Claude Mythos d'Anthropic, un modèle de frontière réglé pour la recherche de vulnérabilités, distribué via un programme partenaire contrôlé appelé Project Glasswing. Une version précédente de Firefox, la 148, avait déjà inclus 22 bugs trouvés par Claude Opus 4.6. Le saut de 22 à 271 sur un seul cycle de version est exactement le genre de nombre qui pousse les gens à dégainer les superlatifs.

Mozilla, à son crédit, s'en est abstenu. Le CTO Bobby Holley a déclaré à The Register que les résultats avaient donné « le vertige » à son équipe et soulevé la question de savoir s'il « est même encore possible de suivre ». Mais il a assorti cela d'une phrase mesurée, facile à manquer et très importante : « de façon encourageante, nous n'avons pas non plus vu de bugs qui n'auraient pas pu être trouvés par un chercheur humain d'élite. »

Cette phrase est toute l'histoire, et toute la thèse de ce billet.

Ce que l'annonce dit réellement

En dépouillant les titres, Mozilla rapporte trois choses.

Premièrement, une machine peut désormais faire à une cadence industrielle ce qu'un petit nombre d'humains d'élite pouvaient déjà faire à une cadence humaine. Le billet l'énonce directement : « aucune catégorie ni complexité de vulnérabilité que les humains peuvent trouver ne reste inaccessible à ce modèle. » C'est une déclaration de capacité. Ce n'est pas une révolution sur ce qui est trouvable ; c'est une révolution sur la vitesse à laquelle le trouvable se fait trouver.

Deuxièmement, il existe une réelle possibilité que la complexité des bugs dépasse la capacité de découverte à mesure que l'outillage IA se répand aussi dans le pipeline de développement. La formulation de Mozilla : « il existe un risque que les bases de code commencent à dépasser la compréhension humaine à mesure que davantage d'IA entre dans le processus de développement. » La compréhensibilité humaine, affirme le billet, est elle-même une propriété de sécurité.

Troisièmement — celui sur lequel tout le monde va projeter — Mozilla est optimiste. « De la lumière au bout du tunnel », a dit Holley. « Les défenseurs ont enfin une chance de gagner, et de manière décisive. »

Nous pensons que la première affirmation est vraie, que la deuxième mérite plus d'attention qu'elle n'en aura, et que la troisième a raison sur la course à l'armement de l'audit et tort sur ce que cette course répare réellement.

Les deux dernières versions de Firefox, avec et sans audit assisté par machine. Les 22 bugs de Firefox 148 ont été attribués à un modèle Claude antérieur ; les 271 bugs de Firefox 150 sont issus de l'évaluation d'un Mythos précoce. Mozilla insiste sur le fait qu'aucun des 271 n'aurait pu échapper à un chercheur humain d'élite — seulement qu'ils ont été trouvés plus vite.

La bonne nouvelle, dite simplement

Il serait malhonnête d'enterrer la bonne nouvelle, alors la voici : un outil qui transforme la capacité d'élite en recherche de vulnérabilités en quelque chose qui passe à l'échelle avec les heures-GPU est l'une des choses les plus utiles qui soit arrivée à la sécurité des navigateurs depuis dix ans. Un saut de 22 à 271, sur exactement un cycle de version, face à une base de code de quelques millions de lignes de C++, est le genre de signal que les autres éditeurs de navigateurs prendront au sérieux. Les ingénieurs de Chromium le prendront. Ceux de WebKit aussi. Les équipes qui maintiennent libxml2, ICU, HarfBuzz, libwebp et les cent autres parseurs que chaque navigateur embarque le feront, si on leur en laisse le temps.

Plus de bugs corrigés avant la sortie, c'est simplement mieux que moins de bugs corrigés avant la sortie. Les 271 ont tous été trouvés en interne, divulgués à personne avant l'envoi du correctif, sans preuve qu'aucun d'eux ait été exploité dans la nature. Selon la vieille formule de la recherche en sécurité, c'étaient des bugs morts-vivants. Mozilla les a tués avant qu'ils n'aient la chance de coûter quoi que ce soit à qui que ce soit.

Donc : un vrai progrès. Un vrai mérite à Mozilla d'avoir divulgué ouvertement plutôt que d'enterrer silencieusement le volume. Un vrai mérite à Anthropic de verrouiller Mythos derrière un programme partenaire plutôt que de le rendre généralement disponible à quiconque peut se payer un abonnement.

Et ensuite, la question plus difficile

Si l'effet de premier ordre est « beaucoup plus de bugs sont corrigés avant la sortie », l'effet de second ordre est « la même capacité est maintenant accessible à toute autre personne à qui Anthropic décide d'accorder l'accès, et une capacité à peu près équivalente sera accessible à n'importe qui dans quelques trimestres ». Ce second effet est celui que le billet précédent, Pourquoi les zero-days de navigateur ne disparaîtront pas, tentait d'exposer en détail. Nous n'allons pas rejuger la question ici. Ce qui compte aujourd'hui dans cet argument, c'est : un navigateur est la plus grande pièce de machinerie de parsing de contenu non fiable qui tourne sur votre ordinateur, et l'économie de la recherche de bugs dans ce genre de machinerie bouge sous les pieds de tout le monde en même temps.

Mozilla a raison : un défenseur bien doté a maintenant de meilleurs outils. Un attaquant bien doté aussi. La question est ce que cela fait aux chiffres qui intéressent réellement un utilisateur — pas les bugs corrigés par version, mais les bugs qui finissent en exploit fonctionnel dans la boîte de réception de quelqu'un.

Ce qu'un auditeur à vitesse-machine change, et ce qu'il ne change pas. L'audit accélère des deux côtés de la ligne. La forme de la surface d'attaque du navigateur, et les conséquences d'une seule compromission réussie, ne bougent pas.

La colonne de gauche, c'est là où vit Mythos. L'audit — des deux côtés — accélère. Cette accélération est asymétriquement utile aux défenseurs quand ce sont eux qui peuvent utiliser l'outillage les premiers, ce que Mozilla a fait, ce que Chromium fait vraisemblablement, ce que les centaines de navigateurs plus petits et d'applications fondées sur un navigateur ne font largement pas. Les accélérations de la colonne de droite n'existent pas. Aucune quantité d'audit ne transforme un moteur de rendu monolithique in-process en un moteur non monolithique. Aucune quantité d'audit ne sépare le moteur de rendu du trousseau, du système de fichiers, de la webcam, de la pile réseau. La forme du problème est inchangée.

La posture qui garde du sens

Mozilla termine son billet par un espoir raisonnable — que nous puissions préserver la compréhensibilité humaine comme propriété de sécurité de premier ordre du navigateur, tout en utilisant l'aide de la machine pour trouver des bugs. C'est un espoir que nous partageons. Ce n'est pas celui sur lequel ce blog est bâti.

La posture autour de laquelle Bromure a été construit ne prédit pas combien de bugs sont dans le moteur de rendu. Elle prédit qu'il y a toujours au moins un bug dans le moteur de rendu que personne n'a encore trouvé — parfois les défenseurs l'atteignent en premier, parfois les attaquants — et que l'architecture autour du moteur de rendu doit rendre cette incertitude survivable.

Ce n'est pas un argument d'éditeur de navigateur. C'est un choix de modèle de menace. Un moteur de rendu audité par Mythos reste un moteur de rendu qui exécute du C++ face à de l'entrée adverse. Le prochain article sur les chaînes de compilation memory-safe, la prochaine génération de fuzzers, le prochain Mythos, ne changeront pas ce qui se passe sur un ordinateur quand un moteur de rendu est compromis aujourd'hui, sur la version de Chrome, Safari ou Firefox déjà installée sur les portables des gens.

Deux défenses contre un bug du moteur de rendu. L'une dépend de l'auditeur qui atteint le bug en premier. L'autre dépend de l'architecture autour du bug, quel que soit celui qui l'a trouvé.

Les deux diagrammes sont de vraies défenses. Celui de gauche est celui dans lequel toute l'industrie du navigateur investit depuis vingt ans, et qui s'accélère désormais avec Mythos. Il s'améliore véritablement. C'est aussi — structurellement — une défense qui dépend de ce que l'éditeur finisse la course avant l'attaquant. Quand cette course passe de mois à heures, comme c'est le cas, la défense se rétrécit à la question de savoir si votre appareil a eu le temps de se mettre à jour dans la fenêtre. Cette fenêtre rétrécit des deux côtés en même temps.

Celui de droite est architectural. Il ne se soucie pas de savoir si le bug a été trouvé par Mozilla, par Anthropic, par le même groupe d'attaquants qui a mené l'opération ForumTroll en 2025, ou par personne encore. Il pose une autre question : quand un bug de moteur de rendu se déclenche, que signifie « se déclenche » en termes de ce que l'attaquant touche réellement ?

Ce que fait Bromure, en une phrase

Chaque onglet tourne dans une machine virtuelle Linux jetable sur Apple Silicon. Le moteur de rendu — V8, Blink, le décodeur WebP, Dawn, chacun des parseurs dans lesquels un auditeur de classe Mythos trouve des bugs — tourne dans cet invité, jamais sur l'hôte. Quand une compromission du moteur de rendu se déclenche, l'attaquant est dans l'invité. L'invité ne contient pas votre dossier Documents, votre trousseau, votre iCloud Drive, votre réseau local, votre caméra, ni votre microphone. Il contient un navigateur, un profil, et l'état que ce profil a accumulé. Quand la fenêtre se ferme, l'invité est détruit. Chaque session de navigation qui démarre, démarre propre.

Ce n'est pas une affirmation que les bugs de moteur de rendu n'ont pas d'importance. Ils en ont. Les mots de passe tapés dans un onglet compromis restent tapés dans cet onglet. Les cookies détenus par un profil compromis restent accessibles à une compromission de ce profil. Les entrées remises à la session pendant la fenêtre d'exploitation sont dans le périmètre. Ce qui n'est pas dans le périmètre, parce que ce n'est pas dans la même VM, c'est le reste de l'ordinateur — et c'est dans le reste de l'ordinateur que vivent la persistance, les mouvements latéraux, et la majeure partie des dégâts réels.

Deux choses que ce billet n'est pas en train de dire

Il y a deux erreurs qu'il serait facile de faire en lisant ce qui précède. Nous tenons à les écarter.

Pas « notre moteur de rendu est meilleur »

Bromure utilise Chromium en amont. Les parseurs que Mythos a audités dans Firefox ont des équivalents dans chaque navigateur basé sur Chromium, y compris Bromure. Nous ne prétendons pas que notre moteur de rendu a moins de bugs que ceux des autres. Nous prétendons que notre posture ne dépend pas de ce que notre moteur de rendu ait moins de bugs.

Pas « l'audit par IA, c'est mauvais, en fait »

Un outillage de classe Mythos est un gain net clair pour les défenseurs — si chaque navigateur et chaque parseur tiers embarqué est audité à cette cadence, le monde devient plus sûr. Notre propos est plus étroit : ce genre de progrès relève le plafond de la qualité des moteurs de rendu ; il ne change pas la question de conception de ce qu'il faut faire quand le moteur de rendu est malgré tout exploité. Cette question-là, c'est celle à laquelle Bromure a été construit pour répondre.

Ce qu'il faut surveiller ensuite

La lecture honnête de l'annonce de Mozilla, c'est que ceci est l'ouverture d'une longue conversation. Il y a au moins trois choses qui compteront dans les prochains trimestres.

Premièrement, si Chromium et WebKit confirment des volumes de découverte comparables quand leurs propres audits assistés par Mythos seront livrés. Les chiffres de Firefox sont frappants ; le portrait à l'échelle de l'industrie reste flou. Deuxièmement, si le même outillage commence à apparaître entre les mains des attaquants après divulgation. Mozilla prend soin de ne pas prétendre que les 271 bugs étaient des zero-days exploitables ; c'étaient des correctifs. La question, c'est à quoi ressemble la même classe d'outil pointée sur Chrome au lendemain de la prochaine version Stable, par quelqu'un qui ne patche pas.

Troisièmement, et c'est la préoccupation propre de Mozilla, si l'interaction entre développement assisté par IA et audit assisté par IA produit une augmentation nette de la compréhensibilité ou une diminution nette. Une base de code que seul un modèle peut auditer est une base de code dont la sécurité dépend d'un accès continu aux modèles. C'est un mode de défaillance différent de celui avec lequel nous avons vécu pendant vingt ans, et pas manifestement meilleur.

De notre côté, nous continuerons à écrire à ce sujet à mesure que les choses évolueront. Et nous continuerons à faire le même pari de conception : qu'une VM jetable par onglet fait de la pire issue d'un bug de navigateur une session qu'il faut redémarrer, et non un ordinateur qu'il faut reconstruire. Ce pari ne devient pas moins bon quand les moteurs de rendu s'améliorent. Il devient, au sens le plus étroit et utile, légèrement redondant — un problème que nous serions très heureux d'avoir.

Installez Bromure. Continuez aussi à mettre à jour votre autre navigateur. Et quand le prochain titre dira « un audit assisté par IA trouve des centaines de vulnérabilités dans [produit] » — et il y en aura beaucoup, cette année — lisez-le pour ce qu'il est : la preuve que le plafond monte, pas la preuve que le sol a changé.