Failles zero-day : ce qu'elles changent pour ton navigateur

Ce qu'est une faille zero-day

Imagine une porte dont le verrou est défectueux. Quelqu'un peut découvrir le défaut avant que le propriétaire dispose d'une pièce de rechange. En sécurité informatique, une faille zero-day est une vulnérabilité exploitée avant qu'un correctif soit accessible au public. L'éditeur peut déjà en avoir connaissance, ou non. Si la faille est exploitée après la publication du correctif, on parle généralement de vulnérabilité « n-day ».

Les navigateurs traitent des contenus web complexes et non fiables. Ils disposent de plusieurs protections destinées à contenir les défaillances. Une faille dans le moteur de rendu est grave, mais ne donne pas automatiquement accès au système d'exploitation. Selon le navigateur, la plateforme et l'objectif, l'attaquant peut devoir exploiter une autre faille pour sortir du bac à sable ou élever ses privilèges. La documentation de Chromium sur l'isolation des sites décrit l'une des couches qui limitent un moteur de rendu compromis.

L'avantage d'une faille zero-day pour l'attaquant tient à l'absence de correctif disponible pour cette faille. Elle n'est pas invisible par définition : la surveillance des comportements, l'isolation des sites, le bac à sable et les enquêtes peuvent encore révéler ou limiter l'attaque. L'attaquant doit aussi atteindre une personne ou un système vulnérable, par exemple avec une page malveillante ou un contenu spécialement conçu.

Le cycle d'une faille zero-day

Cette séquence simplifiée distingue une faille sans correctif public d'une faille qui reste dangereuse après sa publication.

1. 1

   Découverte

   Une équipe de recherche, l'éditeur ou un attaquant découvre une vulnérabilité. Elle peut être signalée en privé, trouvée lors d'une enquête ou gardée secrète. Ces situations ne suivent pas un calendrier fixe.
2. 2

   Mise au point de l'attaque

   L'attaquant cherche comment déclencher la faille dans l'environnement visé. Certaines attaques ne demandent qu'une seule vulnérabilité; d'autres combinent une faille du moteur de rendu avec une sortie du bac à sable ou une autre faiblesse. Une prise de contrôle complète de l'appareil n'est pas automatique.
3. 3

   Exploitation observée

   La faille peut être exploitée via une page malveillante, un site compromis ou un lien ciblé. Même sans signature de cette attaque précise, les protections du navigateur et les outils qui surveillent les comportements peuvent encore bloquer ou révéler une partie de l'activité.
4. 4

   Correctif et annonce

   L'éditeur enquête, prépare un correctif et publie un avis de sécurité quand il est prêt. Le calendrier de publication et de déploiement varie. Une fois disponible, installer rapidement le correctif ferme la faille connue sur le système concerné.
5. 5

   Exploitation après publication

   Les systèmes qui n'ont pas reçu le correctif peuvent rester exposés. Des attaquants peuvent parfois adapter des détails publics ou du code existant pour les viser. Cette réutilisation est possible, sans être systématique ni suivre une durée fixe. L'analyse de Google sur la réutilisation d'exploits montre pourquoi un correctif publié doit aussi parvenir aux utilisateurs.

L'attaque est dite zero-day uniquement tant qu'aucun correctif public n'existe. Après sa publication, le risque concerne surtout les appareils qui ne l'ont pas installé. Repère les versions touchées, applique les correctifs rapidement et garde actives les protections du navigateur et des appareils pendant toute cette période.

D'où viennent les retards de mise à jour

Les tests de compatibilité, les règles imposées aux appareils gérés ou un navigateur laissé ouvert peuvent retarder une mise à jour. Ce délai est distinct de la période où aucun correctif n'existe encore. Les deux demandent plusieurs protections, mais seule la mise à jour corrige la faille publiée dans la version touchée.

Avant le correctif. Le logiciel concerné n'a pas encore de correctif précis. L'étendue des personnes exposées dépend de la version, du système d'exploitation, des réglages et des conditions nécessaires à l'attaque. L'éditeur peut limiter les détails techniques pendant qu'il prépare la correction.

Correctif disponible, mais pas installé. Une flotte d'appareils gérés peut nécessiter des tests et un déploiement coordonné. Entre-temps, les attaquants peuvent viser les versions non corrigées. La publication du correctif ne protège pas un navigateur qui n'a pas redémarré avec la version corrigée.

Appareils oubliés. Les machines partagées, les systèmes d'exploitation qui ne sont plus pris en charge et les navigateurs non gérés peuvent manquer la mise à jour. Un inventaire et la vérification des versions permettent de les retrouver, plutôt que de supposer tout le parc à jour.

Retards exceptionnels. Si tu dois reporter une mise à jour, limite l'accès aux contenus risqués, active les protections des navigateurs gérés et précise quand la version corrigée sera déployée. Un navigateur distant peut réduire l'exposition locale au code des sites, mais ne justifie pas le report des correctifs et n'écarte pas les risques pour les comptes utilisés dans cette session.

Ce que montrent les données

Google Threat Intelligence Group a recensé 75 failles zero-day exploitées et divulguées en 2024, dans plusieurs catégories de produits, et non 75 failles de navigateur. Son analyse de 2024 compte les cas détectés et publiés, pas toutes les attaques.

Dans cet ensemble de données, le nombre de failles zero-day touchant les navigateurs est passé de 17 en 2023 à 11 en 2024. Ces chiffres ne donnent ni un délai universel de déploiement des correctifs ni la probabilité qu'une personne prise au hasard soit attaquée. Ils rappellent l'importance de suivre les versions touchées, d'installer les correctifs disponibles et de conserver des protections avant leur publication.

Des exemples documentés

Les avis des éditeurs documentent les failles et leurs correctifs, mais donnent souvent peu de détails sur les victimes ou l'ensemble de la chaîne d'attaque. Ces quatre exemples montrent pourquoi il faut respecter cette limite.

Chrome CVE-2023-2033. L'avis publié par Google en avril 2023 décrit une confusion de types dans V8 et signale qu'un exploit existait. L'avis ne précise pas comment l'attaque a été diffusée et n'établit pas une prise de contrôle complète de l'appareil.

Firefox CVE-2024-9680. L'avis de Mozilla d'octobre 2024 rapporte une faille d'utilisation de mémoire libérée dans les chronologies d'animation et indique qu'elle a été exploitée. Il ne décrit ni campagne précise, ni sortie du bac à sable, ni logiciel espion.

Safari 18.1.1. L'avis de sécurité d'Apple mentionne la CVE-2024-44308 dans JavaScriptCore et la CVE-2024-44309 dans WebKit. Apple indique que ces deux failles ont pu être exploitées sur des Mac à processeur Intel. L'avis ne précise ni le mode de diffusion de l'attaque ni l'existence d'une campagne ultérieure.

Chrome CVE-2025-2783. Dans son avis de mars 2025, Google confirme une exploitation et propose une mise à jour pour ordinateur. Les détails publics de cet avis ne précisent ni le mode de diffusion de l'attaque ni les délais de déploiement.

L'exploitation d'une faille du navigateur et le vol d'un compte connecté sont deux conséquences différentes. Une faille du moteur de rendu peut rester confinée dans le bac à sable; le vol d'une session peut, lui, se produire sans faille du navigateur. Pour ce risque distinct, lis notre guide sur le détournement de session.

Les autres protections

Installer rapidement les correctifs reste essentiel, mais aucun éditeur ne peut corriger une faille avant de la connaître et de disposer d'une solution. Les autres protections ont des rôles distincts : elles peuvent réduire les occasions d'atteindre le code vulnérable, limiter les effets de l'attaque ou aider à la détecter.

Extensions. Selon les permissions accordées, une extension peut accéder largement aux pages ou aux données de navigation. Vérifie celles qui sont installées et supprime celles dont tu n'as plus besoin. L'abus d'une extension est distinct d'une faille zero-day du navigateur : mettre Chrome ou Firefox à jour ne contrôle pas les extensions à ta place.

Protections du navigateur. L'isolation des sites, le bac à sable et les mesures contre les exploits peuvent limiter certaines attaques. Leur efficacité dépend de la faille et de la plateforme. Toute modification des réglages de sécurité d'un parc géré doit répondre à un besoin documenté et à une évaluation des risques.

Système d'exploitation et protection des appareils. Maintiens le système à jour, comme le navigateur. Les outils de sécurité peuvent analyser les comportements même sans signature de la faille zero-day précise. Ils ne sont ni aveugles par définition ni capables de bloquer toutes les attaques à coup sûr.

Isolation dans un navigateur distant. Ouvrir un site dans un navigateur distant peut réduire l'exposition directe du navigateur et du système local au code de ce site. Cela n'empêche ni la compromission des comptes utilisés dans la session distante, ni les téléchargements dangereux, ni les interactions par le visualiseur et le presse-papiers. Les sessions Browser.lol ne se terminent pas toujours à la fermeture de l'onglet, et les profils enregistrés peuvent persister. L'isolation complète les mises à jour rapides; elle ne justifie pas leur report.

Une défense à plusieurs niveaux

Chaque protection répond à une partie différente de l'attaque. Son utilité dépend de la faille, de la configuration et de l'usage.

Aucune ligne ne garantit l'immunité. L'isolation à distance change l'endroit où le code du site s'exécute; une faille du navigateur distant peut encore toucher sa session ou les comptes qui y sont ouverts. Le visualiseur Browser.lol fonctionne aussi dans ton navigateur local. Teste l'ensemble du parcours, notamment les téléchargements, le presse-papiers, les identifiants et les profils enregistrés, avant de conclure que le risque est circonscrit.

Pour les tâches qui exigent d'ouvrir des sites inconnus, définis une procédure contrôlée avec des comptes de test et évite autant que possible les vrais secrets. Vérifie que la session distante est bien terminée quand tu as fini : fermer l'onglet ne suffit pas à le garantir. Continue de mettre à jour les navigateurs locaux et distants et d'examiner les alertes des autres protections.

Réduire l'exposition et corriger sans tarder

Les signalements de failles zero-day rappellent qu'un correctif précis ne peut précéder la découverte de la faille. Ils ne prouvent ni que tous les navigateurs subissent des attaques constantes ni que les mises à jour ont échoué. Correctifs des éditeurs, bac à sable, surveillance des appareils et isolation à distance ont chacun un rôle et des limites différentes.

Mets à jour les navigateurs concernés dès que possible, garde leurs protections actives et utilise un navigateur distant quand il réduit réellement l'exposition locale. Les identifiants, les fichiers transférés et la session distante elle-même font partie du périmètre à protéger. Cette approche à plusieurs niveaux réduit le risque sans promettre d'arrêter toute attaque inconnue.