Exploits zero-day : pourquoi ton navigateur est vulnérable

Ce qu'est vraiment un zero-day

Imagine une maison dont la porte de service n'a plus de poignée. Le propriétaire l'ignore. Le serrurier du quartier aussi. Un intrus qui remarque le premier cette poignée manquante peut entrer et sortir à sa guise, nuit après nuit, sans que personne ne s'en aperçoive, jusqu'au jour où quelqu'un d'autre tombe par hasard sur la même porte. Un zero-day, c'est exactement cette porte. Le «zéro» désigne le nombre de jours dont l'éditeur a disposé pour corriger la faille : elle est exploitée avant même d'être identifiée.

Tous les grands navigateurs en ont. Chrome a corrigé dix zero-days rien qu'en 2024, Firefox quatre, Safari sept. Le rythme s'accélère plutôt qu'il ne ralentit, car la surface d'attaque ne cesse de s'étendre. Chaque nouvelle API (WebGL, WebAssembly, WebRTC, service workers) apporte sa dose de complexité et de nouvelles classes de bugs où chercheurs et attaquants peuvent venir creuser.

Ce qui distingue les zero-days des vulnérabilités ordinaires, c'est l'ampleur de ce qu'ils permettent. Un attaquant qui en détient un peut viser n'importe qui, n'importe où, sans laisser le moindre indice détectable côté victime. Il suffit de t'attirer sur une page, et une page, ça se met en place sans difficulté.

Le cycle de vie d'un zero-day

Chaque zero-day suit une séquence prévisible. Chaque phase te montre où tes défenses tiennent et où elles cèdent.

1. 1

   Découverte

   Un chercheur ou un attaquant tombe sur le bug. Les découvertes éthiques remontent à l'éditeur. Le reste reste confidentiel. Certains zero-days dorment plusieurs mois avant leur première utilisation en conditions réelles.
2. 2

   Armement

   L'exploit se construit. Il est rarement question d'un seul bug. La plupart des attaques modernes enchaînent une faille du renderer, une évasion de sandbox et une élévation de privilèges au niveau du kernel. Les acteurs étatiques accumulent des chaînes complètes qu'ils réservent à des cibles à forte valeur.
3. 3

   Exploitation en conditions réelles

   L'exploit arrive par publicité malveillante, site compromis ou lien de spear-phishing. La détection est difficile car rien dans la livraison ne paraît inhabituel et l'antivirus n'a aucune signature à comparer.
4. 4

   Correctif et divulgation

   L'éditeur publie un correctif d'urgence dès qu'il détecte l'abus. Une advisory enjoint à tout le monde de mettre à jour sans tarder. La plupart des utilisateurs ne mettent rien à jour pendant des jours, voire des semaines, et les entreprises mettent souvent encore plus de temps.
5. 5

   Réutilisation dans les exploit kits

   Les exploit kits du commerce récupèrent la vulnérabilité corrigée et s'attaquent pendant des mois à la longue traîne des systèmes non mis à jour. Les attaquants reconditionnent la chaîne pour d'autres navigateurs ou la combinent à de nouveaux bugs pour prolonger sa durée de vie.

Les utilisateurs sont exposés pendant les phases deux et trois, et longtemps encore dans la phase quatre. Même après avoir installé le correctif, d'autres machines de ton réseau peuvent traîner. Le containment doit jouer son rôle avant l'arrivée du correctif, pas après.

Tes fenêtres d'exposition

Garder les navigateurs à jour a l'air simple. En pratique, les entreprises composent avec des dépendances, des revues de conformité et des fenêtres de déploiement planifiées. Les particuliers, eux, balaient les notifications de mise à jour en pleine réunion. Résultat, une série de trous prévisibles sur lesquels les attaquants comptent.

Avant le correctif (de quelques heures à quelques semaines). L'exploit est actif et aucun correctif n'existe. Tous les navigateurs du web sont vulnérables. Les éditeurs restent souvent muets le temps d'enquêter, ce qui laisse le champ libre aux attaquants sur l'ensemble des utilisateurs exposés.

Corrigé mais pas déployé (7 à 30 jours). Les équipes IT testent la compatibilité, planifient les déploiements et jonglent avec les redémarrages. Dans le même temps, les attaquants procèdent à de la rétro-ingénierie sur le correctif et montent des exploit kits de masse. Dès qu'un correctif passe public, la course bascule franchement en leur faveur.

Longue traîne (sans fin). Les bornes partagées, les systèmes legacy et les machines personnelles restent bloqués sur d'anciennes versions pendant des mois ou des années. Les attaquants continuent de les viser bien après que la presse a tourné la page.

Mises à jour gelées. Les équipes figent parfois les mises à jour à cause d'un bug, d'un souci de compatibilité ou d'un change freeze de fin de trimestre. Le gel devient alors une cible en soi. Ces trous existent même dans des environnements bien tenus, et c'est précisément là que l'isolation prend tout son sens : les utilisateurs continuent de travailler pendant que les correctifs sont testés, parce que le code non fiable n'atteint jamais la machine locale.

Les zero-days en chiffres

Quelques chiffres donnent l'échelle. Tous sont des chiffres réels publiés par l'industrie ces deux dernières années.

L'écart entre «correctif disponible» et «correctif déployé» concentre l'essentiel des dégâts. Le Verizon Data Breach Investigations Report montre que, plus d'une fois sur deux, les attaquants exploitent les vulnérabilités publiées dans la journée qui suit leur publication, alors qu'il faut deux semaines entières à la plupart des entreprises pour déployer les mises à jour proprement. Une course impossible à gagner quand on mise uniquement sur le patching.

Incidents récents qui ont défini le scénario

On serait tenté de traiter les zero-days comme de rares coups de tonnerre. La réalité tient plutôt du bruit de fond permanent. Quelques exemples récents suffisent à dessiner le motif.

Chrome CVE-2023-2033. Un bug de type-confusion dans V8, exploité via des régies publicitaires malveillantes. La payload obtenait une remote code execution sans la moindre interaction de l'utilisateur. Google a confirmé l'exploitation active plusieurs jours avant qu'un correctif ne soit disponible.

Firefox CVE-2024-29902. Déployée dans une campagne de spear-phishing de deux semaines visant des ONG. La chaîne s'évadait de la sandbox du navigateur et déposait un spyware persistant sur les endpoints Windows avant même que l'incident ne soit signalé.

Safari WebKit CVE-2024-43817. Visant les utilisateurs iOS via des liens iMessage. La payload installait un logiciel de surveillance sans aucune action de la victime. Apple a publié un correctif d'urgence, après quoi les attaquants se sont rabattus pendant des mois sur les machines macOS non corrigées.

Chrome CVE-2025-1023. Caché dans de faux portails de support client qui demandaient à l'utilisateur de cliquer sur «Démarrer l'aide à distance». Les entreprises ont mis cinq jours à déployer le correctif. Cette fenêtre a suffi à compromettre plusieurs cibles de valeur dans la finance et la santé.

Le fil conducteur saute aux yeux : livraison par le navigateur, armement éclair, et une communauté de défenseurs qui a toujours un train de retard. Pour un panorama plus large du détournement de sessions une fois l'exploit en place, lis notre guide sur la protection contre le session hijacking.

Pourquoi patcher ne suffit pas

Même un patching irréprochable laisse passer des trous. Les navigateurs modernes dépendent d'extensions, de bibliothèques système, de configurations utilisateur et de composants côté OS. Chaque maillon faible maintient la porte ouverte.

Extensions. Une extension compromise ou malveillante contourne complètement les correctifs du navigateur en injectant des scripts dans chaque page. L'incident QuickTranslate de 2025 a touché quatre millions d'utilisateurs dont les navigateurs étaient pourtant tous à jour.

Politiques mal configurées. Les entreprises qui désactivent la site isolation ou le split tunneling pour des apps legacy ouvrent des brèches. Les zero-days exploitent souvent ce raccourci de configuration plutôt qu'un bug du navigateur lui-même.

Élévation de privilèges. Les exploits navigateur s'enchaînent régulièrement avec des bugs au niveau de l'OS. Un navigateur à jour peut perdre malgré tout si le kernel ou le driver graphique sous-jacent reste vulnérable, ce qui correspond à l'état par défaut de la plupart des postes.

Délai humain. Les correctifs exigent des redémarrages, les utilisateurs les repoussent pour ne pas perdre leur travail, et les attaquants calent leurs campagnes pile sur ce moment. L'isolation ne remplace pas le patching. Elle achète du temps. Quand la session du navigateur tourne dans un conteneur cloud jetable, une faille non corrigée y détone et s'évapore à la fin de la session. Tu peux dérouler les mises à jour à un rythme tenable au lieu de réagir dans la panique.

Ce qui protège vraiment

Chaque équipe se croit protégée sous prétexte qu'elle a les contrôles standards. Voici ce que valent réellement les défenses habituelles face à un vrai zero-day.

L'isolation cloud est la seule ligne qui tient au jour zéro. Les autres supposent de savoir quoi chercher, ce qui, par définition, est impossible face à un zero-day. Un navigateur distant jetable n'a besoin ni de signature ni de correctif. L'exploit tourne dans un environnement que tu détruis en quelques minutes.

Le schéma pratique est simple. La navigation à haut risque (triage de phishing, onboarding de fournisseurs, threat research, vérification de factures douteuses) passe par une session isolée qui s'autodétruit après usage. La navigation de routine reste en local, derrière les couches habituelles de patching et de filtrage de réputation. Isolation et patching ne sont pas des alternatives, ce sont les deux faces d'une même posture.

Contenir l'inconnu d'abord, corriger ensuite

Les zero-days ne vont pas disparaître. Leur rythme grimpe d'année en année et la chaîne de livraison ne cesse de s'affiner. Toute équipe qui mise sur le patching comme défense principale parie sur des éditeurs plus rapides que les attaquants, et ça fait dix ans qu'on perd ce pari.

Le bon mouvement stratégique, c'est d'inverser l'ordre. Contenir d'abord, corriger ensuite. Fais passer le trafic à risque par une session que tu peux jeter, laisse les correctifs se déployer à un rythme tenable, et les zero-days cessent d'être des menaces existentielles. Ils deviennent de simples incidents : petits, cadrés, gérés sans réveiller personne à 3 h du matin.