On ne résout pas à coups de chéquier un problème qui compte trente-cinq millions de lignes de code. Le navigateur n'est pas sûr parce qu'il a été écrit avec soin ; c'est le plus gros parseur de contenu non fiable qui tourne sur votre ordinateur. La seule chose qui passe à l'échelle, c'est de concevoir autour de ce constat.

Au repos, un navigateur ressemble à un miracle d'ingénierie généreusement financé. Google et Apple emploient chacun des centaines de personnes dont le métier à temps plein consiste à rendre Chrome et Safari moins exploitables. Les deux entreprises livrent des correctifs via des pipelines d'intégration continue qui se mesurent en minutes. Les deux font tourner des programmes de bug bounty qui paient à six et sept chiffres. Les deux publient des post-mortems. Les deux disposent d'une infrastructure de fuzzing de classe mondiale. Et pourtant, avec une régularité parfaite, chaque année, les utilisateurs du logiciel grand public le plus corrigé, le plus durci et le plus audité de la planète apprennent qu'une page qu'ils ont ouverte il y a trois jours avait silencieusement pris le contrôle de leur machine.

Ce billet explique pourquoi. Il explique aussi pourquoi ce calcul est sur le point d'empirer considérablement, et ce qui, à notre avis, constitue la seule issue possible.

L'argent des bounties est bien réel. Les bugs aussi.

Apple et Google paient aujourd'hui des sommes record pour les bugs de navigateur.

Le Vulnerability Reward Program de Google a distribué 12 millions de dollars sur l'ensemble de ses produits en 2024, dont 3,4 millions pour Chrome seul, répartis entre 137 chercheurs. 2025 a pulvérisé ce score : le VRP a versé 17,1 millions de dollars à 747 chercheurs — un bond de 45 % d'une année sur l'autre, et la plus grosse année de bounties de l'histoire de Google. Un unique sandbox-escape Chrome (un bug Mojo) a rapporté 250 000 $ à un seul chercheur.

Apple joue dans la même cour. La page du programme de bounties de l'entreprise affiche désormais un plafond de 2 millions de dollars pour ses chaînes à gravité maximale (contre 1 million auparavant), avec des multiplicateurs pouvant atteindre 5 millions ; les paiements cumulés depuis l'ouverture publique du programme ont franchi les 35 millions de dollars.

Ce sont de gros chiffres. Ce sont les bons chiffres ; les deux entreprises ont été transparentes à leur sujet. Mais voici le détail qui dérange, quand on dépense 17 millions pour trouver des bugs : ce qu'on achète vraiment, c'est la preuve qu'il en reste encore plus.

Les reçus, année par année.

Nombre mensuel moyen de CVE Chrome, de 2023 à la mi-avril 2026. Chaque donnée de ce graphique correspond à une CVE Chrome que les ingénieurs de Google, les chercheurs de son programme de bounties ou des tiers ont signalée, et pour laquelle Google a livré un correctif. Les zero-days exploités dans la nature — ceux qui étaient déjà utilisés avant que Google n'en connaisse l'existence — sont indiqués au-dessus de chaque année.

Plusieurs choses se passent simultanément sur ce graphique, et chacune est pire que la précédente.

La courbe entre 2023 et 2025 ressemble à un progrès. Moins de CVE Chrome par mois, année après année, sur la période où les dépenses de bounty de Google ont augmenté de moitié. Les zero-days exploités dans la nature, seule catégorie qui compte vraiment pour un utilisateur, se sont maintenus à environ huit par an pour Chrome seul — auxquels s'ajoutent chaque année quelques-uns pour Safari et WebKit, dont CVE-2023-42916 / 42917 (tous deux marqués « activement exploités » par Apple fin 2023), CVE-2024-23222 (le premier zero-day d'Apple en 2024), et CVE-2025-24201 (exploité dans des « attaques extrêmement sophistiquées »).

La tentation d'interpréter la tendance était réelle : ça marchait, juste lentement.

Et puis 2026 est arrivée. Les trois premiers mois de cette année à eux seuls ont produit environ 200 CVE Chrome — un rythme qui, s'il se maintient, va pulvériser toutes les années précédentes. Le décompte des zero-days exploités dans la nature est déjà à quatre, avec plus de huit mois encore devant nous. Quelque chose a changé.

Ce quelque chose qui a changé a un nom.

Le 7 avril 2026, Anthropic a annoncé la préversion d'un modèle de pointe, classé en interne « Copybara » et commercialisé sous le nom de Claude Mythos, optimisé pour une seule tâche : trouver et exploiter de façon autonome des vulnérabilités de sécurité. Le rapport public de red-team décrit un modèle qui :

A généré un exploit zero-day fonctionnel dans 72,4 % des cas sur des benchmarks internes, contre moins de 1 % pour Opus 4.6, la génération précédente.
A chaîné quatre vulnérabilités distinctes en un seul JIT heap spray qui s'est échappé à la fois du moteur de rendu et de la sandbox du système d'exploitation d'un navigateur majeur.
A trouvé « des milliers » de zero-days de sévérité élevée et critique sur tous les grands systèmes d'exploitation et tous les grands navigateurs web, au cours d'une évaluation.

À son crédit, Anthropic ne met pas Mythos à disposition du public. À la place, la capacité est distribuée via un programme contrôlé baptisé Project Glasswing, qui inclut Apple, Google, Microsoft, AWS, Cisco, CrowdStrike, NVIDIA, Palo Alto Networks, JPMorgan Chase, Broadcom et la Linux Foundation. Ces organisations ont désormais accès à un modèle qui trouve des zero-days à un rythme qui ne se mesure plus en mois mais en heures.

Ça, c'est, tout bien pesé, la bonne nouvelle. La mauvaise, c'est que Mythos est une annonce, pas une invention. Si un laboratoire de pointe a atteint cette capacité au sein d'un pilote sous contrainte, quelqu'un d'autre — un gouvernement hostile, un éditeur commercial de spyware, un groupe criminel bien financé — disposera d'un équivalent d'ici quelques trimestres. C'est le phénomène plus large que la presse a déjà commencé à appeler la Vulnpocalypse.

La Vulnpocalypse n'est pas une formule. C'est un changement mesurable de la fenêtre.

Le terme a été employé, notamment, dans le reportage du 9 avril de NBC News consacré à Mythos et dans l'article « Mythos and the Vulnpocalypse » de la Cloud Security Alliance. Ce n'est pas un exercice de branding. Il décrit un changement précis et quantifiable : le délai moyen entre la divulgation publique d'une vulnérabilité et son exploitation active est passé d'environ 2,3 ans en 2019 à moins de 24 heures en 2026. Lorsqu'AISLE, une société de recherche de vulnérabilités par IA, a reçu le bulletin OpenSSL de janvier 2026 le jour de sa publication, elle a redécouvert indépendamment les douze zero-days corrigés en quelques heures.

La fenêtre qui rétrécit entre « un bug est divulgué » et « le bug est dans la nature ». Un cycle de correctifs qui se mesurait en années en 2019 se mesure aujourd'hui en heures. Si votre plan de sécurité repose sur le fait d'être plus rapide que l'attaquant, l'attaquant est discrètement devenu un fuzzer surhumain.

Ce n'est pas une hypothèse. La NVD, base de données de vulnérabilités de référence du gouvernement américain, reconnaît discrètement depuis plus d'un an qu'elle n'arrive plus à suivre : début 2026, l'arriéré de CVE non enrichies disposant d'exploits fonctionnels est devenu l'histoire dominante de ses opérations. Les nouvelles soumissions de CVE ont augmenté de plus de 260 % depuis 2020 alors que les effectifs d'analystes stagnent, et la communication publique du NIST est passée de « nous rattraperons le retard » à « nous prioriserons les plus à risque ».

Si vous attendez que l'éditeur publie un correctif, que ce correctif soit diffusé, que votre appareil prenne la mise à jour, et que vous relanciez votre navigateur — voilà un plan de sécurité qui, en 2026, dispose d'une fenêtre de 24 heures pour aller au bout. Moyenne.

Pourquoi le problème est architectural, pas budgétaire.

La raison pour laquelle Google et Apple ne peuvent pas régler ça à coups de budget est simple, et mérite d'être dite clairement : le navigateur est le plus gros parseur de contenu non fiable qui tourne sur votre ordinateur, et il n'existe pas de parseur sûr pour autant de données contrôlées par l'attaquant.

Ce qu'on demande réellement au navigateur de parser, en toute sécurité, à chaque chargement de page. Chacune des cases ci-dessous est à elle seule un projet de plusieurs centaines de milliers de lignes, chacun embarqué dans le navigateur, chacun une surface d'attaque du point de vue d'une page hostile.

Chromium, c'est environ 35 millions de lignes de C++, plus un énorme répertoire //third_party qui embarque plus de 200 bibliothèques externes — le décodeur WebP (CVE-2023-4863, tristement célèbre pour avoir été chaîné au Pegasus de NSO dans l'incident BLASTPASS), le décodeur VP8/VP9, libxml2, ICU, Skia, ANGLE, Dawn, BoringSSL. Chacune de ces bibliothèques est un parseur qui traite des données contrôlées par celui qui possède la page que vous venez d'ouvrir. Tout bug dans l'une d'elles est un bug dans le navigateur.

Safari et WebKit sont plus petits — le cœur représente environ 2,5 millions de lignes de C++, selon l'audit d'Igalia — mais la forme de la surface d'attaque est identique : une pile monumentale de parseurs C et C++, qui traitent des entrées adverses, chaque octet décodé s'exécutant dans le même espace d'adressage que votre profil navigateur.

On ne peut pas écrire autant de C++ traitant autant d'entrées non fiables sans bugs. On ne peut pas s'acheter la sortie des bugs quand le côté attaquant du marché a désormais accès à un fuzzer qui génère des exploits en quelques heures. Le rythme auquel le défenseur trouve et livre des correctifs et le rythme auquel l'attaquant trouve et weaponise de nouveaux bugs divergent, mathématiquement, depuis avril 2026.

Ce que les zero-days récents ont réellement fait.

Avant l'annonce Mythos, les zero-days de navigateur les plus marquants des trois dernières années étaient déjà dessoûlants. Petite liste :

BLASTPASS / libwebp, 2023

CVE-2023-4863 était un heap overflow dans le décodeur d'images WebP utilisé à la fois par Chrome et Safari. L'exploit, déployé par le spyware Pegasus du groupe NSO, ne demandait aucune interaction : visiter la mauvaise image suffisait. Il reste l'une des démonstrations les plus claires qu'un parseur tiers peut compromettre l'ensemble du navigateur.

Operation ForumTroll, 2025

CVE-2025-2783, découverte par Kaspersky GReAT, était un sandbox escape Mojo dans Chrome. Elle a été chaînée avec une compromission du moteur de rendu pour livrer le spyware commercial de Memento Labs à des cibles russes et biélorusses. Google l'a corrigée quelques jours après sa divulgation. Les attaquants l'utilisaient depuis au moins plusieurs mois.

Exploitation V8 nord-coréenne, 2024

CVE-2024-7971 était une confusion de types dans V8 utilisée par des acteurs liés à la Corée du Nord pour déployer un kit de vol de cryptomonnaie. La même année a vu plusieurs autres bugs V8 rattachés à des éditeurs commerciaux de spyware. Point commun : chacun d'eux n'a eu besoin que d'une page web.

Safari, fin 2025

CVE-2025-24201 a été exploitée dans ce qu'Apple a décrit comme des « attaques extrêmement sophistiquées » visant des personnes spécifiques. Un autre duo en décembre (CVE-2025-43529, CVE-2025-14174) a exploité WebKit et ANGLE, et a été marqué comme activement exploité dans des attaques ciblées. WebKit partage une généalogie de code avec l'ANGLE de Chromium ; un bug chez l'un est parfois corrigé chez les deux.

Ces bugs n'ont pas été trouvés parce que les ingénieurs étaient négligents. Ils ont été trouvés parce que les adversaires modernes sont payés pour les trouver, et parce qu'il y en a toujours plus. Ce que fait Mythos, c'est changer le ratio entre « chercheurs capables de trouver un bug » et « gens pouvant se payer un chercheur capable de trouver un bug ». Anthropic a restreint son outil pour l'instant. Il y en aura d'autres.

L'argument architectural.

Tout ce qui précède doit pointer vers une seule conclusion : la bonne hypothèse de conception, c'est que le navigateur contient en ce moment même un zero-day que vous ignorez, qui servira contre quelqu'un cette année, et qui pourrait servir contre vous.

Cette hypothèse posée, la seule question qui compte est la suivante : que se passe-t-il après que le bug a été déclenché ?

Sur un navigateur classique, la réponse est brutale. Le navigateur tourne dans votre compte utilisateur. Son moteur de rendu a accès à vos fichiers, à votre trousseau, à vos cookies, à votre webcam, à votre microphone et à votre réseau local — parce que ce sont des choses auxquelles le compte utilisateur a accès, et que le navigateur est un programme qui tourne en tant que cet utilisateur. Une compromission du moteur de rendu qui contourne la sandbox du navigateur — exactement ce que Mythos a démontré sur un navigateur majeur pendant son évaluation — est une compromission de votre ordinateur. Point final.

C'est l'issue que le reste de l'industrie accepte implicitement et autour de laquelle elle planifie discrètement — avec des couches d'EDR, de détection de points finaux, de MDM, de télémétrie, de réponse à incident, et, pour les moins chanceux, d'avocats spécialisés en négociation avec les rançongiciels.

Bromure fait autre chose.

Bromure ne cherche pas à courir plus vite que Mythos. Cette course ne peut pas être gagnée. Ce que fait Bromure, c'est changer ce qu'un zero-day atteint réellement.

Un zero-day de navigateur dans un navigateur classique s'exécute dans votre compte utilisateur. Le même zero-day dans Bromure s'exécute dans une machine virtuelle jetable qui ne contient ni vos fichiers, ni votre trousseau, ni rien de ce qui vous importe. La pire issue, c'est la perte de la session de navigation que vous aviez déjà fermée.

Dans Bromure, le navigateur tourne dans une VM invitée scellée. Quand une compromission du moteur de rendu se déclenche — le même sandbox escape Mojo qui a tourné dans Operation ForumTroll, la même chaîne de confusion de types V8 que Mythos a générée lors de ses tests internes —, l'attaquant obtient une exécution de code dans une VM Linux jetable. Cette VM ne contient pas vos fichiers. Elle ne contient pas votre trousseau. Elle ne contient pas votre webcam, ni votre microphone, ni votre réseau local. Elle contient un navigateur, un profil, et l'état que ce profil a accumulé.

Quand la session s'achève et que vous fermez la fenêtre, la VM est détruite. L'exploit est détruit avec elle. La persistance — la manœuvre la plus précieuse qu'un attaquant peut tenter après un accès initial — ne peut pas s'établir dans quelque chose qui est sur le point de cesser d'exister.

Ce que nous ne prétendons pas.

L'architecture de Bromure n'est pas une baguette magique. Deux limites méritent d'être énoncées :

L'exploit compromet toujours la session de navigation

Les mots de passe saisis dans cette session, les cookies stockés dans ce profil, les données entrées dans les formulaires pendant la fenêtre d'exploitation — tout cela vit dans la VM et est accessible à une compromission de cette VM. L'isolation cantonne les dégâts à la session ; elle ne protège pas rétroactivement des entrées déjà confiées à la session. La séparation par profil et les sessions jetables réduisent la valeur de ce rayon d'action ; elles ne le ramènent pas à zéro.

Une évasion de VM reste envisageable

Une chaîne suffisamment sévère pourrait, en principe, s'échapper de la VM elle-même. C'est un problème beaucoup plus difficile que de s'échapper d'une sandbox de navigateur — plusieurs ordres de grandeur de bugs en moins, et la surface d'attaque de l'hyperviseur est par conception plus étroite que celle d'un navigateur —, mais elle n'est pas nulle. Bromure réduit la probabilité qu'un zero-day de navigateur se traduise par une compromission de l'hôte ; il ne l'élimine pas.

Le bon chiffre n'est pas « zéro risque ». Le bon chiffre, c'est « combien de zero-days par an finissent réellement par compromettre votre ordinateur réel ». Sur un navigateur classique, ce chiffre grimpe, et il s'apprête à grimper plus vite. Sous Bromure, il est conditionné par une classe de bug distincte dont la découverte coûte environ cent fois plus cher.

Préparez-vous au monde dans lequel vous allez bientôt vivre.

Les zero-days de navigateur ne sont pas un bug de l'écosystème. Ce sont une caractéristique structurelle du fait de faire tourner des dizaines de millions de lignes de C++ sur la trajectoire d'octets adverses, pour lesquelles il n'existe pas de correctif d'ingénierie crédible, et pour lesquelles le frein économique (vous êtes trop coûteux à attaquer) est sur le point d'être automatisé. Apple et Google ne se la coulent pas douce. Le problème est véritablement plus dur que leurs budgets.

Ce que nous pouvons faire, et ce que fait Bromure, c'est déplacer le rayon d'action. Isoler le navigateur. Rendre chaque session jetable. Mettre le système d'exploitation hôte à un mur de plus de chaque page. C'est une forme de produit différente, et c'est la seule que nous ayons trouvée qui tienne encore debout quand l'adversaire est une fabrique d'exploits IA toujours active, avec une facture d'API à trois chiffres.

Installez Bromure. Faites-en votre choix par défaut pour tout ce à quoi vous ne faites pas pleinement confiance. Et quand le prochain titre annoncera « Un zero-day activement exploité dans Chrome corrigé en urgence » — et ça arrivera, dans les semaines qui viennent —, continuez de lire, parce que l'issue n'a pas à être la vôtre.