Une note de correctif n'est pas un modèle de menaces. « Processing maliciously crafted web content may lead to an unexpected Safari crash » — autrement dit, « le traitement d'un contenu web malveillant peut provoquer un plantage inattendu de Safari » — est la manière polie dont l'éditeur indique que, pour certains utilisateurs, cette faille a été la dernière chose que le navigateur a faite avant que quelque chose d'autre ne s'exécute. La question utile, c'est : à quoi ce « quelque chose d'autre » a-t-il accès ?

Le 11 mai 2026, Apple a publié About the security content of macOS Tahoe 26.5. Cette version comble environ soixante-dix CVE à travers le système d'exploitation, dont dix concernent WebKit — le moteur de rendu de Safari, qui est aussi le moteur derrière chaque autre « vue web » sur macOS, du rendu HTML de Mail au navigateur intégré dans l'App Store. Aucune des dix n'est listée par Apple comme exploitée dans la nature. Cela ne revient pas à dire qu'elles n'ont pas été exploitées, seulement qu'Apple n'a, à ce jour, aucune preuve allant dans ce sens. Le reste de ce billet prend l'avis au pied de la lettre et pose une question plus étroite, plus utile : pour chacune de ces failles, qu'aurait-elle fait à un utilisateur de Bromure ?

La réponse courte est dans le titre. La réponse plus longue, c'est ce qui rend l'architecture digne qu'on s'y attarde.

L'avis, en clair

Lire une note de sécurité Apple est en partie un exercice de vocabulaire. La formulation canonique — « processing maliciously crafted web content may lead to » — couvre un spectre qui va de « un onglet va se fermer » jusqu'à « la machine n'est plus à vous ». Ce qui les distingue, c'est la classe de la faille, et l'avis le dit aussi, juste à voix basse.

Les dix CVE WebKit dans macOS Tahoe 26.5, regroupées par classe de vulnérabilité. Chaque classe a un plafond différent sur ce qu'une chaîne d'exploitation construite par-dessus peut atteindre. Les deux classes du bas — corruption mémoire avec potentiel d'exécution de code arbitraire, et use-after-free — sont celles qui, dans l'historique, ont été le plus souvent chaînées en compromission de moteur de rendu, puis jusqu'à l'hôte.

Apple ne publie pas, par principe, d'analyses d'exploitabilité. La formulation est délibérée : un « plantage de processus » peut désigner un moteur de rendu qui atteint une assertion et meurt sans conséquence, ou un moteur de rendu qui entre dans un état où, avec quelques semaines de travail et un heap groom, un attaquant transforme le plantage en primitive d'écriture, puis en exécution de code. Les chercheurs du domaine ont démontré à maintes reprises que le second cas est réalisable pour une large part des use-after-free WebKit divulgués exactement avec cette formulation — CVE-2025-43529, corrigée dans macOS 26.2 en décembre dernier, était décrite dans des termes identiques et faisait l'objet d'attaques ciblées au moment de sa divulgation. La bonne façon de lire cet avis, c'est donc comme une liste de candidats pour la prochaine vague d'exploitation dans la nature, pas comme une liste de failles que l'on sait inoffensives.

Première classe — les cinq use-after-free

Un use-after-free, en une phrase, c'est une faille où le navigateur libère un bloc de mémoire qui contenait un objet — un nœud DOM, un écouteur d'événement, un wrapper JavaScript — puis continue d'utiliser l'ancienne référence comme si l'objet existait toujours. Au moment où l'ancienne référence est déréférencée, l'emplacement a été rempli par autre chose : un autre objet que la page vient de créer, ou un tampon que la page vient de remplir avec des octets ressemblant à un pointeur de fonction. La page contrôle désormais un pointeur que le navigateur traite comme digne de confiance.

CVE-2026-28883, CVE-2026-28942, CVE-2026-28946, CVE-2026-28947, et le sous-ensemble UAF du cluster CVE-2026-28901 — CVE-2026-28913, sont les cinq use-after-free WebKit de cette version. Apple les attribue à un mélange de chercheurs indépendants et, dans un cas (CVE-2026-28942), à Milad Nasr et Nicholas Carlini travaillant avec Claude — la même catégorie plus large de recherche de vulnérabilités assistée par IA que Mozilla décrivait en avril en attribuant à une première exécution de Mythos 271 correctifs dans une seule version de Firefox.

Sur un Mac sous macOS 26.5 d'origine avant l'application de cette mise à jour, le pire scénario pour l'une de ces failles ressemble à ceci :

Vous visitez une page. La page exécute du JavaScript qui sollicite une opération DOM d'une manière qui déclenche le use-after-free.
La mémoire du moteur de rendu est manipulée de sorte que l'emplacement libéré soit rempli avec un contenu que l'attaquant contrôle.
L'exécution de code atterrit dans le processus de contenu Safari — le même espace d'adressage que votre session de navigation, vos cookies, vos onglets connectés.
Un exploit de seconde étape, chaîné au premier, s'évade du bac à sable de contenu pour atteindre le processus Safari plus large. Le bac à sable de WebKit est solide mais pas inviolable ; ces dernières années comptent plusieurs évasions documentées.
Une fois hors du bac à sable, l'attaquant s'exécute sous votre compte utilisateur, sur votre machine. Il a accès en lecture à ~/Documents, ~/Library/Keychains, ~/.ssh, aux cookies du profil stocké de Safari, au contenu d'iCloud Drive téléchargé pour un usage hors ligne, et à tout ce qui vit sous votre répertoire personnel.

C'est la chaîne complète du navigateur traditionnel. Aucune des étapes n'est hypothétique ; chacune a été observée dans une véritable chaîne WebKit exploitée dans la nature ces trois dernières années.

Un use-after-free WebKit dans Safari d'origine, comparé à la même faille déclenchée dans un onglet Bromure. La faille se déclenche dans les deux cas. La différence, c'est ce qu'il y a de l'autre côté du moteur de rendu quand cela arrive.

Il y a un détail dans le diagramme de droite qu'il vaut mieux poser d'emblée : Bromure n'utilise pas WebKit. Chaque onglet exécute Chromium à l'intérieur de sa VM Linux invitée jetable. Le texte littéral de ces CVE — cinq use-after-free WebKit — ne s'applique donc pas au moteur de rendu que livre Bromure. Un utilisateur de Bromure qui n'a jamais appliqué macOS 26.5 n'est pas exposé à ces failles WebKit spécifiques à travers l'onglet Bromure qu'il a ouvert.

Ce n'est pas, en soi, une affirmation intéressante. Chrome a son propre catalogue de failles mémoire. Firefox a le sien. Le point qui compte est de second ordre : même si vous substituez mentalement à ces CVE la classe équivalente de use-after-free dans Chromium V8 ou Blink — CVE-2024-7971, la confusion de types dans V8 qu'ont utilisée en 2024 des acteurs liés à la Corée du Nord, en est l'analogue évident — l'image de droite ne change pas. L'exploit se déclenche dans le moteur de rendu. Le moteur de rendu est à l'intérieur de la VM invitée. L'exécution de code atterrit dans une boîte Linux qui ne contient ni votre trousseau, ni votre dossier Documents, ni vos clés SSH. Quand l'onglet se ferme, la VM est détruite.

Deuxième classe — trois autres failles mémoire et une faille de validation d'entrée

CVE-2026-43658 est la seule faille WebKit de cet avis qu'Apple qualifie explicitement de « gestion mémoire » plutôt que de use-after-free ; l'impact annoncé est un plantage inattendu de Safari. CVE-2026-28917 est étiquetée comme validation d'entrée, et produit également un plantage de processus. Toutes deux relèvent du même seau général que les use-after-free — ce sont des plantages dans l'espace d'adressage de WebKit causés par une page hostile — et toutes deux ont le même plafond réaliste : avec assez de travail, un « plantage » peut, dans certains cas, être promu en primitive d'exécution de code, et dans d'autres rester véritablement un simple plantage. Apple ne nous dit pas dans quelle catégorie chacune tombe, et les correctifs ne tranchent pas non plus la question à une lecture rapide.

Le point digne d'être souligné, c'est que pour l'utilisateur, cette distinction ne change pas la réponse architecturale. Sur Safari d'origine, même une faille de plantage à l'air anodin dans WebKit est, au pire, un point d'appui. Sur Bromure, même la pire version de l'une de ces failles — exécution de code complète dans le moteur de rendu — est un événement d'exécution de code à l'intérieur d'un invité que l'on jette.

Troisième classe — les cinq failles de logique et de politique

Cinq des dix failles WebKit de cet avis ne sont pas du tout des failles mémoire. Ce sont des failles de logique — de petites incohérences entre ce que la politique de sécurité de Safari dit autoriser et ce que son code applique réellement.

CVE-2026-43660 et CVE-2026-28907 — contournement CSP

La Content Security Policy est le mécanisme par lequel un site web indique au navigateur « n'exécute du JavaScript qu'en provenance de ces origines, ne charge des images que depuis ces autres ». Ces deux failles permettent à une page malveillante de faire sauter l'application de cette politique par Safari sur un chemin du parseur. Conséquence concrète : un XSS stocké sur un site qui pensait être protégé par CSP s'exécute désormais.

CVE-2026-28962 et CVE-2026-28958 — divulgation d'informations

Toutes deux permettent à une page hostile de lire des données auxquelles elle ne devrait pas avoir accès. La première touche à la logique de contrôle d'accès de WebKit ; la seconde, à ses chemins de protection des données. Utilisées dans une chaîne, ce sont les failles qui transforment « j'ai l'exécution de code dans votre moteur de rendu » en « j'ai votre cookie de session pour un autre site sur lequel vous étiez connecté ».

CVE-2026-28971 — usurpation de téléchargement iframe

Un iframe malveillant peut utiliser les paramètres de téléchargement de la page parente. En surface, c'est une faille d'interface ; en pratique, c'est la manière dont un téléchargement furtif vient se greffer sur un site auquel l'utilisateur a explicitement accordé sa confiance pour enregistrer des fichiers. Une primitive d'accès initial pour les maliciels, droit sortie du manuel.

À quoi servent les failles de logique

Prises isolément, aucune ne donne l'exécution de code. Leur valeur est structurelle : chacune est un barreau que les failles mémoire ci-dessus utilisent pour grimper. Un use-after-free brut est difficile à transformer en arme sans un moyen de fuiter un pointeur, un moyen de contourner CSP, un moyen de lire l'état d'une autre origine. Les failles de logique de la même version sont la moitié discrète de toute chaîne d'exploit publique.

Le même argument s'applique côté Bromure, avec une précision qui mérite d'être faite. La faille d'usurpation de téléchargement (CVE-2026-28971) est intéressante parce que c'est la seule de la liste qui, sur Safari d'origine, peut produire un fichier sur disque que l'utilisateur pourrait ensuite ouvrir. Les téléchargements depuis un onglet Bromure atterrissent par défaut dans la VM invitée de cet onglet ; les faire sortir de l'invité est une action utilisateur explicite. Un fichier furtif que la page parvient à « télécharger » est, sur Bromure, un fichier dans un invité Linux sur le point de cesser d'exister. Les divulgations d'informations d'origine croisée (CVE-2026-28962, CVE-2026-28958) lisent des données que le moteur de rendu peut voir, ce qui sur Bromure correspond aux données qui vivent à l'intérieur de la VM de ce seul onglet.

Ce qui reste dans la pièce : ce que la VM isole et ce qu'elle n'isole pas

Il serait trop facile de repartir de ce qui précède avec la mauvaise conclusion. L'architecture de Bromure est efficace pour restreindre le rayon d'explosion d'une compromission du moteur de rendu. Elle n'est pas magique. Plusieurs choses restent dans la pièce et méritent d'être nommées explicitement.

La session elle-même est compromise

Un exploit fonctionnel sur l'une de ces failles s'empare quand même de l'onglet dans lequel il se déclenche. Les mots de passe tapés dans cet onglet pendant la fenêtre d'exploitation sont en jeu. Les cookies stockés dans le profil que cet onglet utilise sont en jeu. Les données de formulaire sont en jeu. La séparation par profil dans Bromure garantit que les dégâts sont bornés à ce profil, pas à toute votre vie numérique, mais ce n'est pas nul.

Le presse-papiers est le pont évident

La posture par défaut de Bromure laisse le presse-papiers disponible pour l'invité, parce que, pour la plupart des utilisateurs, le coût de casser le copier-coller au quotidien l'emporte sur le rare scénario d'exploitation. Cette posture est un choix délibéré, que nous pouvons rompre à la demande pour les sessions que vous voulez hermétiques. Mieux vaut savoir que le pont existe.

Une évasion d'hyperviseur reste sur la table

Une chaîne suffisamment déterminée pourrait, en principe, s'évader de l'hyperviseur Apple Silicon lui-même. La surface d'attaque y est de plusieurs ordres de grandeur plus petite que celle d'un navigateur, et l'historique public de telles failles est court, mais il n'est pas nul. Nous ne revendiquons pas l'immunité ; nous revendiquons d'avoir déplacé la classe de faille dont dépend votre sécurité.

Pas d'extensions, pas de couche d'assistance navigateur

Bromure n'autorise tout simplement pas l'installation d'extensions Chrome. C'est une position, pas un réglage. Cela élimine toute une seconde surface d'attaque — chaque extension est son propre chemin de code quasi-confiance avec des permissions qui voyagent à côté du moteur de rendu — qui a historiquement été la voie par laquelle beaucoup de compromissions réelles de navigateur ont obtenu leur persistance.

Pourquoi le Mac et le navigateur veulent être des machines séparées

Il y a une façon plus générale de dire tout ce qui précède. Un Mac moderne contient, côte à côte dans le même domaine de confiance :

Le système, avec vos fichiers et votre trousseau.
Les applications natives que vous avez installées, avec toutes les habilitations qu'elles ont demandées.
Le navigateur, qui est de très loin la plus vaste machinerie d'analyse contrôlable par un attaquant sur le système.

Quand une faille WebKit se déclenche sur un macOS d'origine, la partie du système qui vient d'être compromise est la partie du système qui a accès en lecture aux deux autres. Ce n'est pas une erreur de Safari ; c'est la conséquence directe de faire tourner un navigateur comme une application en espace utilisateur, à côté de tout le reste de ce que fait l'utilisateur.

La conception de Bromure traite le navigateur et le reste du Mac comme des machines différentes. Le navigateur tourne effectivement sur une machine différente — un invité Linux, sur un CPU virtuel, avec un disque virtuel réinitialisé à chaque session. Le Mac hôte ne voit l'invité qu'à travers un ensemble étroit d'appels d'hyperviseur : framebuffer, entrée, réseau, presse-papiers quand il est autorisé. Une faille de classe WebKit — ou son équivalent Chromium — qui atterrit dans l'invité est, du point de vue de l'hôte, du code qui s'exécute sur un autre ordinateur, dans un autre système d'exploitation, sans chemin vers les fichiers de l'utilisateur. Le fait que les deux « ordinateurs » partagent un même boîtier est un détail d'implémentation.

Que faire aujourd'hui

Si vous lisez ceci sur le Mac que vous utilisez pour tout le reste, le plus important, c'est la chose ennuyeuse : appliquez la mise à jour macOS 26.5. La fenêtre entre la publication d'un correctif par Apple et le moment où quelqu'un en tire un exploit fonctionnel se mesure désormais, selon les mesures du secteur lui-même, en heures plutôt qu'en semaines. Les utilisateurs de Safari d'origine ayant appliqué cette mise à jour sont protégés contre les dix failles WebKit ci-dessus. Ceux qui ne l'ont pas appliquée ne le sont pas.

Si vous lisez ceci sur Bromure, vous êtes protégé contre les failles de moteur de rendu de classe WebKit par l'architecture plutôt que par l'adoption des correctifs, parce que le moteur de rendu n'est pas WebKit, ne tourne pas sur l'hôte, et se trouve dans un invité détruit à la fermeture de l'onglet. Vous devriez quand même appliquer la mise à jour macOS 26.5, parce que les autres soixante CVE de cette version corrigent des parties de macOS que Bromure n'isole pas — composants du noyau, services système, frameworks natifs — et celles-ci comptent toujours.

Le cadrage que nous aimerions voir plus de gens adopter est le suivant. Les zero days WebKit ne vont pas s'arrêter. Les zero days Chromium ne vont pas s'arrêter. Ce qui peut s'arrêter, pour n'importe quel utilisateur donné, c'est le lien entre « une page s'est trompée » et « votre ordinateur s'est trompé ». C'est ce lien que Bromure a été conçu pour briser, un avis de dix CVE après l'autre.

Installez Bromure. Continuez d'appliquer vos mises à jour macOS. Et la prochaine fois qu'Apple publiera une mise à jour Safari indiquant « processing maliciously crafted web content may lead to » — et ce sera bientôt, parce que la cadence est désormais mensuelle — lisez la phrase, classez-la, et remarquez que, pour la partie de votre journée passée dans Bromure, la phrase ne se termine pas.