Faille zero-day : sur les VPN et pare-feux, quelques jours entre publication et
exploitation confirmée

Mardi matin, un avis de sécurité tombe sur le concentrateur VPN qui porte tous vos accès distants. Score critique, exécution de code sans authentification, correctif "en cours". La question n'est pas de savoir si quelqu'un va tenter l'exploitation, mais quand. Pour une faille zero-day au sens strict, la réponse est "c'est déjà fait" : la faille était exploitée avant d'être publiée. Pour les autres, on peut mesurer.

Nous avons repris le catalogue public des failles dont la CISA a confirmé l'exploitation, et compté, pour chaque entrée ajoutée depuis janvier 2024, l'écart entre la publication de la CVE dans la NVD et son inscription au catalogue. Sur les VPN, pare-feux et passerelles d'accès, cet écart se compte en quelques jours : 1 à 6 jours en médiane selon le périmètre qu'on retient, contre près d'un mois pour le reste du catalogue. Et près de la moitié de leurs failles récentes y entrent le jour même de leur publication, ou avant.

Une faille zero-day, c'est zéro jour pour se préparer

On mélange souvent trois choses. Une faille zero-day est une vulnérabilité exploitée avant qu'un correctif n'existe. Le terme désigne aussi bien la faille que l'exploit qui en tire parti, le fameux 0day du jargon. À l'instant où l'éditeur publie un patch, la même faille devient techniquement une n-day : le correctif existe, mais tant que vous ne l'avez pas appliqué, elle reste exploitable chez vous. Un attaquant ne fait pas la différence. Pour lui, une n-day non déployée vaut une zero-day, avec en prime le mode d'emploi que la publication du patch lui a offert.

C'est le paradoxe des équipements de bord. Le jour de la divulgation, la pression maximale pèse moins sur ceux qui n'ont pas encore de correctif que sur ceux qui l'ont mais qui mettront des semaines à le déployer sur un concentrateur VPN en production. La faille zero-day fait la une ; l'exploitation de masse, elle, se joue dans la fenêtre n-day : les jours et semaines qui suivent le patch, quand le code de l'exploit se diffuse et que les parcs n'ont pas bougé. C'est le terrain de la gestion des vulnérabilités, et le point aveugle du patch management sur les actifs exposés.

VPN, pare-feux, passerelles : 1 à 6 jours, contre un mois ailleurs

Pour comparer, il faut deux groupes définis avant de calculer. Nous avons repris une table de classement du catalogue, produit par produit, construite et relue la veille pour une autre étude (celle des failles utilisées par les rançongiciels). Sa famille "VPN, pare-feu, passerelle" couvre les concentrateurs VPN, les pare-feux, les passerelles d'accès et d'application, le SD-WAN et les fournisseurs d'identité exposés. Tout le reste du catalogue forme le second groupe, à l'exception de 26 entrées que la table ne sait pas classer, publiées à part.

Sur les 93 entrées de cette famille ajoutées au catalogue entre le 1^er janvier 2024 et le 4 octobre 2026, l'écart médian entre publication NVD et inscription est de 1 jour, et 43,0 % y sont entrées le jour de leur publication ou avant. Pour les 562 entrées du reste du catalogue, la médiane est de 29,5 jours et la même part tombe à 17,3 %.

Une partie de cet écart vient de l'âge des failles : le catalogue inscrit régulièrement de vieilles CVE, exploitées des années après leur publication, et le reste du catalogue en compte davantage. À ancienneté égale, en ne gardant que les CVE publiées depuis 2024, l'écart se resserre mais ne disparaît pas : 1 jour de médiane pour la famille (83 entrées), 8 jours pour le reste (429). Pour donner un repère, toutes familles confondues, ces CVE récentes ont une médiane de 6 jours (535 entrées).

Pourquoi nous écrivons "quelques jours" et pas "1 jour"

Parce que le chiffre dépend du périmètre, et que la table n'a pas été conçue pour cette question. Elle range dans la famille certains outils d'administration de pare-feux et des routeurs VPN d'une marque, mais laisse dehors les routeurs VPN d'une autre, des consoles exposées à Internet et les passerelles de messagerie. Nous avons donc refait le calcul sous deux variantes. Retirer les outils d'administration (85 entrées) ne change rien : 1 jour. Élargir la famille à tous les équipements exposés qu'elle omettait (142 entrées) porte la médiane à 6 jours, contre 28,5 pour le reste, et à 2 jours contre 9 pour les CVE publiées depuis 2024.

Le sens du résultat tient sous toutes les variantes : les équipements de bord entrent au catalogue nettement plus vite que le reste. Son ampleur, elle, bouge du simple au sextuple. D'où la formulation : quelques jours, avec le périmètre à côté.

Ce que valait le "6 jours" de la première version

La première version de cet article annonçait un écart médian de 6 jours, "mesure CISA KEV", sur 54 CVE d'équipements de bord. Le calcul se reproduit exactement, et sa définition mérite d'être écrite en clair : ce sont les entrées du catalogue au nom de Fortinet, Ivanti et Citrix, plus celles de Microsoft dont le produit contient le mot "Exchange", ajoutées entre janvier 2024 et le 1^er septembre 2026, et l'écart mesuré est celui qui sépare la publication NVD de l'inscription au catalogue. Seize ont été inscrites le jour de leur publication ou avant, et 30 sous sept jours, bornes comprises (28 en moins de sept jours au sens strict).

Le problème est le filtre, pas l'arithmétique. Un nom d'éditeur n'est pas une famille d'équipements. Sur les 54 entrées, 23 relèvent de la famille VPN, pare-feu, passerelle. Les autres se répartissent en 19 consoles de gestion de parc et d'appareils, exposées elles aussi, 4 entrées Fortinet "Multiple Products" dont 3 touchent FortiOS, 4 autres produits, 3 failles Exchange, et un composant de Windows (le service IKE, Internet Key Exchange) que le mot "Exchange" a capté par erreur. Les médianes par éditeur de la première version (3 jours pour Ivanti, 4,5 pour Fortinet, 7 pour Citrix) se reproduisent aussi, mais elles mélangent ces familles. La mesure par famille, définie avant le calcul, les remplace.

  exploitation      PUBLICATION       course au patch      patch
  silencieuse       CVE + avis        parc = cible         deploye
  (jour -N)         (jour 0)          (jour 0..+P)         (jour +P)
      |                 |                   |                  |
      +--- zero-day ----+------- n-day non deploye -----------+---->
                        |
                        +---> inscription au KEV (exploitation confirmee)
                              VPN, pare-feux, passerelles : +1 a +6 jours (mediane)
                              reste du catalogue          : ~ +29 jours

L'autre question : combien de failles d'une année y passent

Les chiffres précédents partent du catalogue et regardent en arrière. On peut aussi partir des CVE publiées une année donnée et compter celles qui entrent au catalogue dans les douze mois, ce qui laisse à toutes le même recul. Sur les 39 953 CVE publiées dans la NVD en 2024, 149 sont entrées au KEV dans l'année, soit 37 pour 10 000. Parmi elles, le délai médian est de 7 jours. Les 23 qui touchent la famille VPN, pare-feu, passerelle ont une médiane nulle : 12 d'entre elles ont été inscrites le jour de leur publication ou avant. Le reste (119) est à 14 jours. En 2023, la proportion était de 50 pour 10 000 (145 sur 28 816), avec une médiane de 4 jours.

Ces deux lectures disent la même chose sous deux angles. Une infime partie des CVE publiées sera exploitée de façon confirmée, et c'est pour celles-là que les scores CVSS ne suffisent pas à trier. Mais quand la faille touche un équipement de bord, la fenêtre entre publication et exploitation confirmée se compte en jours.

La mesure

Deux sources ouvertes, croisées par identifiant de CVE, sans aucun téléchargement nouveau : le catalogue CISA KEV dans sa version 2026.10.04 (1 734 entrées, collecté le 6 octobre 2026), et un miroir public des flux de la NVD (instantané au 5 octobre 2026, CVE rejetées exclues). Les 1 734 entrées du catalogue s'y retrouvent toutes. Le délai est la date d'inscription au KEV moins la date calendaire de publication dans la NVD, en temps universel, négatifs compris. Les quartiles sont calculés par interpolation linéaire.

La table de familles a été construite et relue produit par produit le 6 octobre pour une autre analyse, puis reprise telle quelle : elle était figée avant le calcul des délais, ce qui écarte le choix d'un périmètre flatteur après coup. Ses incohérences de périmètre, elles, sont réelles, et c'est pourquoi les deux variantes sont publiées. L'ensemble a été rejoué depuis les fichiers bruts par une contre-expertise menée séparément, avec son propre code, qui retrouve les mêmes comptages et a demandé deux corrections, intégrées ici : la ventilation exacte des 54 entrées de la première version, et la sensibilité au périmètre.

Quatre failles d'équipements exposés, datées

Les médianes cachent des histoires. Voici quatre CVE réelles, une par éditeur du filtre de la première version, avec leur date de publication NVD et leur date d'inscription au catalogue KEV. Toutes portent l'indicateur d'usage par des campagnes de rançongiciel, et toutes visent une interface exposée en frontal, avant authentification.

La faille FortiOS et celle d'Ivanti Connect Secure racontent la même histoire, à un an d'écart : divulgation et confirmation d'exploitation le même jour. Le zero-day dans sa forme pure. Une écriture hors limites sur le service SSL-VPN de FortiOS, un débordement de pile sur le concentrateur Ivanti, dans les deux cas une exécution de code à distance sans le moindre identifiant, avec un score CVSS proche du maximum. Quand l'avis de sécurité sort, l'attaque est déjà en cours dans la nature.

Le cas NetScaler, surnommé CitrixBleed 2, est différent et instructif. Ce n'est pas une zero-day au sens strict : l'exploitation a été confirmée après la publication. Le score de la NVD paraît modeste (7,5 en CVSS v3.1) parce qu'il ne s'agit que d'une lecture mémoire hors limites, pas d'une exécution de code ; l'éditeur, lui, l'a noté 9,3 en CVSS v4. Mais cette lecture fuit des jetons de session valides : de quoi rejouer une session authentifiée sans mot de passe, sans second facteur, sur une passerelle d'accès distant. Le 7,5 sous-estime l'impact réel, et c'est un rappel utile que la lecture du score CVSS seule ne dit ni si vous êtes exposé, ni ce qu'un attaquant en fait vraiment. Vingt-trois jours ont séparé la publication de la confirmation d'exploitation, autant de jours pour recueillir des sessions.

Enfin, ProxyLogon, l'incident Exchange fondateur. La date d'inscription au KEV (novembre 2021) ne veut rien dire ici, parce que le catalogue lui-même n'existait pas avant : c'est une entrée rétroactive. Ce qui compte, c'est la chronologie réelle. La faille SSRF a été exploitée comme zero-day dès le début de 2021 ; Microsoft a publié un correctif en urgence, hors cycle, le 2 mars 2021 ; et dans les jours qui ont suivi la publication, l'exploitation est passée de quelques opérateurs ciblés à un balayage massif d'Internet, tant que des serveurs Exchange restaient non patchés. Le schéma que toutes les autres répètent : petite exploitation silencieuse, divulgation, puis ruée sur le parc n-day.

La messagerie n'a d'ailleurs pas le profil des VPN dans le catalogue récent. Les 62 entrées de la famille messagerie et collaboration ajoutées depuis janvier 2024 ont un écart médian de 32,5 jours entre publication et inscription, et seulement 7 y sont entrées le jour même ou avant. Les trois failles Exchange du filtre de la première version en donnent un aperçu : deux ont été inscrites plus de trois ans après leur publication, la troisième en deux jours.

La fenêtre avant le patch : ce qui marche

Face à une zero-day, la première réaction, patcher, est parfois impossible (pas de correctif) et toujours insuffisante à elle seule (il faut le déployer, le tester, redémarrer un équipement de production). Alors on se rabat sur ce qui reste, dans l'ordre :

• Savoir ce qu'on expose : la seule action qui garde de la valeur avant même qu'un correctif existe. Sans inventaire des services joignables depuis Internet et de leurs versions, vous découvrez votre exposition en lisant un article de presse, ou pire, dans les journaux d'un attaquant.
• Appliquer les contournements de l'éditeur : désactiver le composant vulnérable, filtrer un chemin d'URL, couper une fonctionnalité. Utile, à condition de savoir sur quels équipements l'appliquer, ce qui ramène au point précédent.
• Restreindre l'accès aux interfaces d'administration : un portail d'admin de VPN ou de pare-feu exposé à Internet entier est une invitation. Derrière une liste d'IP autorisées ou un accès conditionnel, la même faille perd l'essentiel de sa portée.
• Surveiller les signes de compromission : une fois la faille connue, les indicateurs le sont aussi. Encore faut-il savoir quels équipements surveiller en priorité, donc, encore, connaître son exposition.

Tout revient au même prérequis. Les mesures d'urgence supposent qu'on sache où les appliquer. Le jour où une CVE FortiOS ou NetScaler tombe, l'organisation qui tient un inventaire à jour de sa surface exposée lit une liste d'actifs concernés en quelques minutes. Celle qui ne l'a pas lance une chasse au trésor pendant que la fenêtre se referme. C'est toute la logique de la gestion de surface d'attaque externe.

Ce que verrait un module de surveillance de surface d'attaque

On s'en tient au mécanisme, sans scanner quoi que ce soit qui ne nous appartienne pas. Des moteurs de cartographie d'Internet comme Shodan ou Censys collectent en continu les bannières des services exposés : la réponse qu'un serveur renvoie quand on ouvre une connexion. Un portail VPN SSL, une interface NetScaler, un serveur Exchange annoncent presque toujours leur produit et, souvent, leur version, dans un en-tête HTTP, un certificat TLS, une page de connexion ou une réponse d'erreur caractéristique. C'est de l'information passive, publiée par l'équipement lui-même à qui veut l'écouter.

Un module de surveillance de surface d'attaque reconstruit cet inventaire du point de vue de l'attaquant, à partir de vos domaines, puis recoupe chaque bannière et chaque version avec les CVE connues. Le jour où une nouvelle faille tombe sur FortiOS, le travail est déjà fait : la version vulnérable est dans l'inventaire ou elle ne l'est pas.

La corrélation par bannière et version a ses limites, et il faut les dire. Elle repère l'exposition probable, pas la preuve d'une faille exploitable : une version peut être rétroportée sans changer de numéro affiché, un contournement peut déjà être en place, une bannière peut être maquillée. C'est un signal de priorisation, pas un verdict de compromission. Pour transformer ce signal en certitude, il faut aller confirmer l'exploitabilité, ce que fait un pentest automatisé non intrusif côté outil, ou un pentest web en boîte noire quand l'enjeu justifie une main humaine. Mais avant tout cela, il faut la liste, tenue à jour avant que la faille ne tombe.

À retenir

• Zero-day = zéro jour pour se préparer. La faille est exploitée avant tout correctif. Dès que le patch existe et n'est pas déployé, elle devient une n-day, aussi dangereuse en pratique.
• Le délai réel se compte en jours. Sur le catalogue CISA KEV 2024-2026, les VPN, pare-feux et passerelles entrent au catalogue 1 à 6 jours après leur publication en médiane, selon le périmètre retenu, contre 28,5 à 29,5 jours pour le reste. Pour les CVE publiées depuis 2024 : 1 à 2 jours contre 8 à 9.
• Un chiffre sans périmètre ne vaut rien. Le "6 jours" de la première version venait d'un filtre par nom d'éditeur où 23 entrées sur 54 seulement étaient des VPN, pare-feux ou passerelles. Une famille définie avant le calcul, et sa variante, le remplacent.
• Avant le patch, savoir ce qu'on expose est le seul levier durable. Contournements, restriction d'accès et surveillance supposent tous de connaître ses actifs exposés et leurs versions.
• La corrélation bannière vers CVE priorise, elle ne prouve pas. Elle signale une exposition probable ; la confirmation d'exploitabilité demande un test dédié.

Une faille zero-day n'attend pas que vous soyez prêt. La seule chose qui se prépare à l'avance, c'est la connaissance de votre propre surface exposée : quels services, quelles versions, joignables depuis où. C'est ce que la surveillance de surface d'attaque externe tient à jour en continu, prête à recouper la prochaine CVE le jour où elle tombe. Si vous voulez savoir ce qu'un attaquant voit de vous avant lui, parlons-en.

Questions fréquentes sur les failles zero-day