Failles zero-day : 10 incidents historiques et leurs leçons

Et si la faille qui permet une intrusion n’était pas encore connue de votre équipe de sécurité ? C’est tout le défi posé par les attaques zero-day : elles exploitent une vulnérabilité alors que les défenseurs disposent de peu d’informations et parfois d’aucun correctif adapté. Mais il faut être précis : une attaque contre un système resté non corrigé des semaines après la publication d’un patch n’est pas, pour cette seule raison, une attaque zero-day.

Stuxnet, Pegasus, WannaCry, Heartbleed, Log4Shell… Ces noms évoquent des crises bien réelles, mais ils ne relèvent pas tous du même scénario. Nous revenons sur dix incidents pour distinguer les véritables exploitations zero-day des vulnérabilités déjà divulguées, puis comprendre ce que les équipes SOC et RSSI peuvent concrètement améliorer.

De Stuxnet à Pegasus, en passant par les attaques contre Chrome et SharePoint, plusieurs épisodes ont montré la rapidité avec laquelle une vulnérabilité peut devenir une menace opérationnelle. D’autres cas, comme WannaCry utilisant EternalBlue après la publication d’un correctif, restent essentiels pour comprendre la gestion des risques, mais ne doivent pas être présentés comme des attaques zero-day au moment de leur propagation.

Dix épisodes, dix leçons : identifier les failles avant qu’elles ne deviennent des portes d’entrée, réduire l’exposition et relier les signes de compromission. Pour chaque cas, nous distinguons les zero-days avérés des vulnérabilités déjà connues afin d’en tirer des décisions utiles pour le SOC et le RSSI.

Qu’est-ce qu’une faille zero-day ?

Dans le vocabulaire de la cybersécurité, il faut distinguer trois notions :

• Vulnérabilité zero-day : faille auparavant inconnue du fournisseur ou des défenseurs lorsqu’elle est exploitée. Le terme est parfois employé plus largement pour une faille récemment dévoilée sans correctif, mais ces situations doivent être distinguées dans l’analyse historique.
• Exploit zero-day : technique ou code permettant d’exploiter cette vulnérabilité avant la disponibilité d’un correctif adapté.
• Attaque zero-day : utilisation réelle de cet exploit contre une cible.

Une vulnérabilité connue, publiée et corrigée peut rester dangereuse si les systèmes n’ont pas été mis à jour. C’est une situation différente : l’attaquant exploite alors une vulnérabilité non corrigée chez la victime, pas nécessairement un zero-day.

La définition du NIST insiste sur l’exploitation d’une vulnérabilité auparavant inconnue. Cette nuance est importante pour comparer les événements historiques sans confondre découverte, divulgation, correctif et exploitation.

Dix incidents qui ont changé la manière de gérer les vulnérabilités

• Stuxnet (2010). Statut : Exploitation de plusieurs zero-days confirmée. Leçon : Protéger les environnements industriels et leurs dépendances.
• EternalBlue / WannaCry (2017). Statut : WannaCry a frappé après publication d’un correctif. Leçon : Déployer rapidement les mises à jour et surveiller la propagation.
• Heartbleed (2014). Statut : Vulnérabilité majeure ; pas un cas zero-day démontré ici. Leçon : Identifier les composants et secrets exposés.
• Shellshock (2014). Statut : Divulgation publique puis exploitation documentée. Leçon : Réduire l’exposition des services et accélérer la remédiation.
• Pegasus / FORCEDENTRY (2021). Statut : Zero-day exploité, documenté par Citizen Lab. Leçon : Prévoir les attaques ciblées et sans interaction.
• Log4Shell (2021). Statut : Exploitation rapide ; chronologie à distinguer selon les campagnes. Leçon : Maîtriser les dépendances logicielles.
• Google Chrome / V8 (2025). Statut : Exploit actif signalé par Google. Leçon : Mettre à jour les navigateurs et appareils.
• SharePoint / ToolShell (2025). Statut : Exploitation active d’une vulnérabilité zero-day. Leçon : Vérifier les compromissions, pas seulement appliquer le patch.
• PrintNightmare (2021). Statut : Faille divulguée et correctifs d’urgence. Leçon : Sécuriser les services transverses et les privilèges.
• BlueKeep (2019). Statut : Correctif antérieur aux exploitations publiques connues citées. Leçon : Maintenir le parc et limiter les accès distants.

1. Stuxnet (2010) : plusieurs zero-days au service d’une attaque industrielle

Stuxnet a marqué les esprits en visant des environnements industriels, notamment des systèmes de contrôle Siemens. Les analyses d’ICS-CERT et les alertes du CERT-FR ont décrit son exploitation de vulnérabilités Windows alors non corrigées, ainsi que ses modes de propagation.

Leçon pour les équipes cyber : les systèmes industriels, les postes de maintenance et les échanges entre zones doivent être intégrés à la gestion du risque, même lorsqu’ils paraissent isolés. La visibilité sur les communications IT/OT et la maîtrise des supports amovibles sont des éléments d’une défense multicouche.

Source : CERT-FR : Stuxnet et vulnérabilité Windows non corrigée.

2. EternalBlue et WannaCry (2017) : une propagation sur des machines non mises à jour

L’exploit EternalBlue ciblait des vulnérabilités SMBv1 de Windows. Microsoft a publié le bulletin MS17-010 le 14 mars 2017, avant la propagation de WannaCry en mai. Les systèmes insuffisamment mis à jour ont alors été particulièrement exposés.

La distinction est déterminante : WannaCry n’était pas une attaque zero-day au moment de cette campagne. Son impact montre qu’un correctif disponible ne protège pas les machines qui ne l’ont pas reçu et qu’une vulnérabilité connue peut faciliter la propagation interne.

Source : Microsoft : chronologie EternalBlue / WannaCry.

3. Heartbleed (2014) : une vulnérabilité de bibliothèque largement réutilisée

Heartbleed, référencée CVE-2014-0160, concernait le mécanisme Heartbeat d’OpenSSL. Dans certains contextes, son exploitation pouvait révéler des portions de mémoire contenant des informations sensibles.

L’intérêt de ce cas n’est pas d’en faire artificiellement un zero-day : il révèle la difficulté de savoir quels services utilisent une bibliothèque vulnérable et quelles mesures sont nécessaires après correction. Une organisation peut devoir mettre à jour des composants, revoir ses certificats et évaluer les données potentiellement exposées.

Source : Cisco : analyse de CVE-2014-0160.

4. Shellshock (2014) : une fonction banale qui devient une porte d’entrée

La vulnérabilité Shellshock, CVE-2014-6271, affectait la manière dont Bash traitait certaines variables d’environnement. Selon l’exposition d’un service, elle pouvait permettre l’exécution de commandes non prévues. Des tentatives d’exploitation ont été observées après sa divulgation publique.

Leçon : un composant historique peut créer une surface d’attaque importante lorsqu’il est appelé par des services exposés. Il faut inventorient les usages, appliquer les mises à jour adaptées et rechercher les traces d’exploitation lorsqu’une vulnérabilité critique devient publique.

Source : Red Hat : Shellshock.

5. Pegasus / FORCEDENTRY (2021) : l’exemple d’un zero-day sans clic

Citizen Lab a documenté FORCEDENTRY, une chaîne d’exploitation zero-click visant iMessage et associée au logiciel espion Pegasus. Une victime pouvait être ciblée sans avoir à ouvrir volontairement un lien malveillant.

Ce cas rappelle que la sensibilisation des utilisateurs reste utile, mais ne suffit pas à prévenir toutes les attaques. La gestion des correctifs, la sécurité des terminaux, l’analyse forensique et les protections propres aux appareils mobiles sont indispensables dans les contextes d’espionnage ciblé.

Source : Citizen Lab : FORCEDENTRY.

6. Log4Shell (2021) : le risque caché dans les dépendances logicielles

Log4Shell (CVE-2021-44228) a touché Log4j, une bibliothèque Java de journalisation intégrée à de nombreux logiciels. Les conditions d’exploitation dépendaient de la version, de la configuration et des chemins de données accessibles. Les organisations ont dû rechercher rapidement les composants concernés, parfois intégrés dans des applications tierces.

Leçon : la visibilité sur les dépendances logicielles, les inventaires techniques et les mesures de confinement sont aussi importants que la gestion des correctifs. Les campagnes d’exploitation peuvent se prolonger après l’annonce publique d’une faille ; elles ne sont pas toutes des attaques zero-day.

Source : CISA : directive d’urgence Log4j.

7. Google Chrome (2025) : les navigateurs restent une surface d’attaque

En juin 2025, Google a documenté CVE-2025-5419, une vulnérabilité du moteur V8 de Chrome, en précisant avoir connaissance d’un exploit actif. Cet exemple illustre le risque associé à un outil présent sur la quasi-totalité des postes de travail.

Leçon : les politiques de mise à jour des navigateurs, le contrôle des extensions, le durcissement et la télémétrie des postes doivent être pris au sérieux. Les protections réseau ne remplacent pas les correctifs des applications clientes.

Source : Google : mise à jour de sécurité Chrome du 2 juin 2025.

8. SharePoint / ToolShell (2025) : une attaque sur les serveurs collaboratifs exposés

En juillet 2025, Microsoft a signalé des attaques visant des serveurs SharePoint sur site, notamment autour de CVE-2025-53770. Les versions SharePoint Online de Microsoft 365 n’étaient pas concernées par cet avis particulier.

Au-delà de l’installation du correctif, Microsoft a recommandé des vérifications de compromission et plusieurs mesures complémentaires, notamment la rotation de clés dans certains cas. Une correction logicielle ne supprime pas automatiquement un accès acquis par un attaquant avant le déploiement du patch.

Source : Microsoft : consignes CVE-2025-53770.

9. PrintNightmare (2021) : le risque des services transverses

PrintNightmare, CVE-2021-34527, affectait le service Windows Print Spooler. Le fait qu’un service courant puisse exposer des fonctions privilégiées a attiré l’attention sur la surface d’attaque des fonctionnalités activées par défaut et des services rarement réévalués.

Leçon : limiter les privilèges, désactiver les fonctionnalités inutiles et vérifier l’application effective des correctifs aide à réduire le risque. Dans ce cas, la chronologie de divulgation et de correction doit être distinguée d’une exploitation zero-day avérée.

Source : CISA : correctifs PrintNightmare.

10. BlueKeep (2019) : le danger d’un accès distant mal maîtrisé

BlueKeep (CVE-2019-0708) concernait les services Remote Desktop d’anciennes versions de Windows. Microsoft a diffusé des correctifs en mai 2019 et a décrit plus tard des tentatives d’exploitation observées publiquement.

Leçon : un service exposé inutilement, un système obsolète ou un correctif retardé peuvent maintenir un risque pendant des mois. La réduction de la surface d’exposition et la connaissance des actifs sont aussi essentielles que les signatures de détection.

Source : Microsoft : BlueKeep et exploitation observée en 2019.

Que nous apprennent ces dix épisodes ?

Trois enseignements se dégagent. D’abord, les vulnérabilités critiques ne se trouvent pas seulement dans les applications visibles : elles peuvent concerner une bibliothèque, un service système, un navigateur ou une plateforme de collaboration. Ensuite, la date de publication d’un correctif ne marque pas la fin du risque : les systèmes non corrigés, les accès persistants et les dépendances invisibles peuvent maintenir l’exposition.

Enfin, prévenir une exploitation et détecter les actions d’un attaquant sont deux sujets complémentaires. Même lorsqu’une vulnérabilité précise n’est pas encore identifiée, certaines phases d’une intrusion peuvent provoquer des changements observables dans le système d’information.

Comment limiter les risques liés aux failles zero-day ?

Il n’existe pas de protection universelle contre les attaques zero-day. Une stratégie réaliste combine plusieurs contrôles :

1. Connaître sa surface d’attaque : inventaire des actifs, des logiciels, des services exposés et des dépendances critiques.
2. Réduire les chemins d’exploitation : principes du moindre privilège, segmentation réseau et désactivation des services inutiles.
3. Prioriser les vulnérabilités réellement exploitées : surveiller notamment les avis fournisseurs, CERT-FR et le catalogue CISA des vulnérabilités exploitées (KEV).
4. Déployer et vérifier les correctifs : distinguer correctif publié, correctif installé et compromission éventuellement déjà présente.
5. Observer les comportements suspects : rechercher les signes de reconnaissance, communications anormales, mouvements latéraux et exfiltration.
6. Préparer l’investigation et la réponse : tests, conservation de la télémétrie utile, procédures de confinement et responsabilités clairement définies.

Pour compléter la veille et la remédiation, découvrez le Guide NDR Gatewatcher.

Quel rôle le NDR peut-il jouer face à une attaque zero-day ?

Un NDR ne corrige pas une vulnérabilité et ne garantit pas de reconnaître chaque exploit inédit. Son intérêt réside dans l’observation des communications et l’analyse de comportements qui peuvent accompagner une attaque : échanges C2 inhabituels, balayages internes, communications entre segments non attendues ou volumes de données atypiques.

Une attaque peut ainsi débuter par l’exploitation d’une application, puis produire des signes détectables lors d’un mouvement latéral ou d’une sortie de données. Le NDR peut aider l’équipe SOC à corréler ces observations, à délimiter le périmètre de l’incident et à orienter l’investigation, sous réserve de la visibilité effectivement déployée.

Cette approche complète la gestion des correctifs, la protection des terminaux, la segmentation et les outils du SOC. Pour en savoir plus sur le dispositif, consultez Gatewatcher DETECTION CENTER et la plateforme NDR Gatewatcher.

Vous cherchez à mieux identifier les comportements suspects après une compromission ? Échangez avec un expert Gatewatcher et demandez une démonstration.

Comment prioriser une alerte liée à une vulnérabilité critique ?

Une détection réseau prend davantage de sens lorsqu’elle est replacée dans le contexte métier de l’actif. Decision Center Gatewatcher présente une approche de scoring de risque contextualisé, de corrélation et d’aide à la décision gouvernée. Cette approche peut soutenir la qualification d’un incident, sans prétendre connaître une vulnérabilité inconnue ni garantir la détection de toutes les attaques zero-day.

Besoin d’évaluer vos capacités de détection au-delà des signatures ? Demandez une démonstration de la plateforme Gatewatcher pour examiner les flux réellement visibles et les scénarios prioritaires de votre SOC.

FAQ : vulnérabilités et attaques zero-day

Quelle est la différence entre une faille zero-day et une faille non corrigée ?

Une faille zero-day ne dispose pas encore d’un correctif adapté ; elle peut être inconnue du fournisseur ou connue mais non corrigée. Une faille non corrigée chez une organisation peut, elle, être publique depuis longtemps et disposer déjà d’un correctif que cette organisation n’a pas installé.

Peut-on détecter une attaque zero-day sans connaître sa signature ?

Parfois, oui : l’analyse d’anomalies et des comportements peut révéler certaines étapes d’une intrusion. Mais cela dépend des données observées, du contexte et des techniques de l’attaquant. Aucun outil ne garantit la détection de toutes les attaques inédites.

Les correctifs suffisent-ils contre les zero-days ?

Non. Tant qu’aucun correctif n’est disponible, la réduction d’exposition, la segmentation et la surveillance sont essentielles. Après publication, il faut installer les correctifs et vérifier si des systèmes ont été compromis avant leur déploiement.

Quelle différence entre CVE, exploit et attaque ?

Un identifiant CVE référence publiquement une vulnérabilité. Un exploit est une méthode permettant d’en tirer parti. Une attaque correspond à son utilisation réelle contre une cible. Un identifiant CVE n’implique donc pas qu’une exploitation ait été observée.

Conclusion : prévenir, observer et réagir

Le zero-day rappelle une vérité simple : les équipes de sécurité ne disposent pas toujours d’une signature ni d’un correctif au moment décisif. À l’inverse, WannaCry a montré le danger d’une faille déjà corrigée chez l’éditeur mais toujours exploitable sur le terrain. Dans les deux cas, la réponse repose sur une même discipline : connaître ses actifs, réduire les chemins d’attaque, observer les comportements anormaux et être capable de décider vite, avec des preuves.

Les solutions NDR peuvent compléter cette défense en apportant de la visibilité sur les communications effectivement observées. Pour comprendre leur place dans votre architecture, découvrez le NDR Gatewatcher ou demandez une démo.