Time-to-exploit : quand les 0-day brûlent en quelques heures

En janvier 2018, le délai moyen entre la publication d’une CVE et sa première exploitation dans la nature était de 771 jours. En 2023, ce chiffre était tombé à 63 jours. En mars 2026, CVE-2026-33017 sur Langflow a été exploitée 20 heures après sa divulgation publique. CVE-2026-20131 sur Cisco FMC a été exploitée 36 jours avant même sa divulgation. Nous avons franchi un seuil. Le concept de fenêtre de réponse — ce laps de temps entre la publication d’une vulnérabilité et le début de son exploitation — sur lequel repose toute la stratégie de patch management traditionnelle, est en train de disparaître. Pour les équipes de sécurité, cela signifie que les processus de remédiation construits autour de cycles de validation mensuels sont devenus structurellement incompatibles avec la réalité du threat landscape actuel. Ce n’est pas un problème de moyens, c’est un problème d’architecture de la réponse.

Ce qui a changé : l’industrialisation de l’exploitation

La réduction du time-to-exploit n’est pas un phénomène naturel. Elle est le résultat direct de l’industrialisation des capacités offensives. Trois facteurs se combinent aujourd’hui pour comprimer ce délai à des niveaux inédits. Premier facteur : les IA génératives permettent à des attaquants non spécialisés de développer des PoC exploitables en quelques heures à partir d’une description de vulnérabilité. Ce que cela prenait des semaines de reverse engineering peut désormais être prototype en quelques heures. Deuxième facteur : les groupes cybercriminels ont industrialisé leurs pipelines de surveillance des divulgations CVE — des bots automatiques parcourent les flux NVD, GitHub et les publications de chercheurs pour détecter et analyser les nouvelles vulnérabilités en quasi-temps-réel. Troisième facteur : les équipements de sécurité périmétrique (firewalls, VPN, load balancers) sont devenus la cible prioritaire, car leur exploitation donne accès direct aux réseaux d’entreprise. Notre analyse de CVE-2026-20131 sur Cisco FMC est un cas d’école : 36 jours d’exploitation avant la divulgation publique, sur l’équipement censé protéger le périmètre.

Le patch management traditionnel est mort

J’entends encore des RSSI qui planifient leurs cycles de patch sur des fenêtres de maintenance mensuelles. Je comprends la contrainte opérationnelle : patcher en production sans tester, c’est risquer des régressions et des interruptions de service. Mais ce raisonnement suppose qu’on dispose d’un mois pour réagir. Ce n’est plus vrai pour les CVE critiques sur les équipements exposés. Voici les faits bruts de ce mois : CVE-2026-33017 sur Langflow — 20 heures entre la divulgation et l’exploitation active. CVE-2025-32975 sur Quest KACE SMA — couvert dans notre analyse dédiée — exploité en moins de 48 heures. CVE-2026-22557 sur Ubiquiti UniFi — couvert dans notre article sur ce CVSS 10.0 — ciblé activement dès le lendemain de la divulgation. La fenêtre de remédiation sur les CVE critiques exposées est maintenant mesurée en heures. Le catalogue CISA KEV constitue la liste minimale des vulnérabilités à traiter en urgence.

Ce que ça implique concrètement pour les équipes défensives

La réponse ne peut pas être "patcher plus vite" — c’est nécessaire mais insuffisant. Trois axes concrets. D’abord, la réduction de la surface d’exposition : chaque équipement dont l’interface de management est accessible depuis Internet sans nécessité absolue est une cible potentielle. L’isolation des plans de management sur des réseaux d’administration dédiés, les bastions d’accès avec authentification forte, la suppression des accès directs non essentiels — ces mesures réduisent l’impact d’un zero-day indépendamment du patch. Ensuite, la détection comportementale en temps réel : si vous ne pouvez pas patcher en quelques heures, vous devez au minimum détecter l’exploitation en cours via des règles sur les comportements post-exploitation (exécution de processus enfants depuis des services web, connexions sortantes anormales, création de fichiers dans des répertoires système) plutôt que de simples signatures de CVE connues. Enfin, la segmentation réseau : la compromission d’un équipement périmétrique ne doit pas équivaloir à la compromission du réseau entier. Pour une mise en œuvre pratique, notre guide sur les vulnérabilités OWASP Top 10 offre un cadre applicable au renforcement de la posture défensive.

Le cas particulier des pipelines IA

CVE-2026-33017 sur Langflow n’est pas un incident isolé. Il illustre une tendance lourde : les composants d’infrastructure IA (frameworks d’agents, plateformes RAG, orchestrateurs LLM) sont devenus des cibles de premier rang, précisément parce qu’ils sont intégrés rapidement en production sans la maturité de sécurité des logiciels d’entreprise traditionnels. Notre analyse des risques de sécurité dans les pipelines IA identifiait déjà ce risque systémique. Le time-to-exploit sur ces composants sera structurellement court : les chercheurs offensifs ciblent en priorité les nouvelles surfaces d’attaque, et les pipelines IA en sont actuellement la plus dynamique.

Sources et références : CERT-FR · MITRE ATT&CK

Conclusion

Le time-to-exploit continuera de baisser. L’automatisation de l’analyse de vulnérabilités par les IA offensives va s’améliorer. Les attaquants les plus sophistiqués exploitent avant divulgation — c’est désormais documenté. Les stratégies défensives doivent évoluer d’une logique réactive (patch les CVE publiées) vers une logique préventive (réduire la surface exposée, détecter comportementalement, limiter l’impact par la segmentation). Ce n’est pas une question de budget, c’est une question de priorités architecturales. Et ces priorités doivent être réévaluées maintenant.

EPSS vs CVSS : Révolutionner la Priorisation des Patches

Le CVSS (Common Vulnerability Scoring System) a longtemps été l'unique référence pour prioriser les corrections de vulnérabilités. Son problème fondamental : il mesure la sévérité théorique d'une vulnérabilité, pas la probabilité qu'elle soit exploitée. Résultat, les équipes sécurité passent du temps à corriger des CVE critiques (CVSS 9+) qui ne seront jamais exploitées en pratique, pendant que des CVE modérées activement exploitées passent sous les radars.

EPSS : Probabilité d'Exploitation à 30 Jours

L'Exploit Prediction Scoring System (EPSS), développé par le FIRST, calcule la probabilité qu'une CVE soit exploitée dans les 30 prochains jours. Le modèle v3 (2023) utilise 1 400+ features dont les mentions sur les réseaux sociaux, les exploits publiés, la présence dans des frameworks offensifs (Metasploit, Nuclei), et les données de détection IDS/IPS de GreyNoise et Shodan. Chaque CVE reçoit un score EPSS entre 0 et 1 (0 = jamais exploité, 1 = exploitation certaine dans 30j).

# Récupérer les scores EPSS via API FIRST
import requests

# Score d'une CVE spécifique
resp = requests.get('https://api.first.org/data/1.0/epss?cve=CVE-2024-21762')
data = resp.json()['data'][0]
print(f"CVE-2024-21762 EPSS: {data['epss']} (percentile: {data['percentile']})")
# Output: CVE-2024-21762 EPSS: 0.97 (percentile: 0.99)

# Top 100 CVEs par score EPSS (à patcher en urgence)
resp = requests.get('https://api.first.org/data/1.0/epss?order=!epss&limit=100')
for cve in resp.json()['data']:
    print(f"{cve['cve']} - EPSS: {cve['epss']} - CVSS: {cve.get('cvss','N/A')}")

La corrélation EPSS/CVSS révèle des insights contre-intuitifs : en 2024, seulement 6,9% des CVE avec un score CVSS critique (≥9) avaient un EPSS supérieur à 0,1 (10% de chance d'exploitation dans 30j). Inversement, 4,2% des CVE avec EPSS>0,5 avaient un CVSS inférieur à 7. Prioriser uniquement sur le CVSS revient à corriger 93% de CVE probablement jamais exploitées.

Modèle de Priorisation CVSS + EPSS + KEV

La stratégie optimale combine trois sources : CVSS (sévérité), EPSS (probabilité d'exploitation), et CISA KEV (Known Exploited Vulnerabilities) catalogue. La matrice de priorité :

Priorité P0 (patch sous 24h) : CVE dans CISA KEV ET CVSS ≥7. Exploitation confirmée en production. FortiGate CVE-2024-21762 (EPSS 0.97, KEV) ou Ivanti CVE-2024-21887 entrent dans cette catégorie.

Priorité P1 (patch sous 72h) : EPSS >0,4 ET CVSS ≥7. Exploitation probable imminente. Ce seuil EPSS 0,4 capture 95% des CVE effectivement exploitées selon l'analyse rétrospective FIRST sur 2022-2024.

Priorité P2 (patch sous 30 jours) : CVSS ≥7 ET EPSS 0,01-0,4. Risque modéré.

Priorité P3 (cycle normal) : CVSS <7 ET EPSS <0,01. Traitement dans le cycle de release standard.

Études de Cas : Time-to-Exploit Mesuré

Exchange ProxyLogon (CVE-2021-26855) : TTX Inférieur à 2 Heures

Le cas ProxyLogon reste la référence absolue en matière de vitesse d'exploitation. Microsoft publie le patch le 2 mars 2021 à 19h UTC. Les premiers PoC fonctionnels apparaissent sur GitHub et Pastebin à 20h47 UTC, soit 1h47 après la publication. Les scans massifs de Shodan détectent 250 000 serveurs Exchange vulnérables exposés sur Internet. À 23h, les premières webshells sont déposées sur des serveurs non patchés. Le TTX (Time to eXploit) moyen entre la publication du CVE et la première exploitation réussie sur un système non patchés : 1h52.

La leçon technique : ProxyLogon est une chaîne de 4 CVE (SSRF, plaintext password, path traversal, arbitrary file write). Le SSRF (CVE-2021-26855) permet d'authentifier n'importe quel utilisateur ; les autres CVE permettent ensuite l'exécution de code. La complexité apparente de la chaîne n'a pas ralenti les attaquants car des chercheurs avaient partiellement documenté les primitives vulnérables dans des présentations de conférence avant la publication.

FortiGate CVE-2024-21762 : EPSS 0.97 en 48 Heures

Fortinet publie un advisory pour CVE-2024-21762 (out-of-bounds write dans FortiOS SSL-VPN) le 8 février 2024. Le score CVSS est 9.6 (Critical). Dans les 48 heures suivant la publication, le score EPSS passe de 0,12 à 0,97 — signalant que des exploits actifs circulaient dans des forums privés avant même la publication officielle. CISA ajoute la CVE au catalogue KEV le 9 février. Les analyses de Shodan indiquent 150 000+ instances FortiGate exposées sur Internet à ce moment.

Cette CVE illustre le phénomène de "silent patching" : Fortinet avait inclus le fix dans une version précédente sans documenter la CVE, permettant à des chercheurs adversariaux de reverse-engineer le patch et développer un exploit avant la divulgation officielle. Le TTX effectif était donc négatif — l'exploit existait avant le CVE officiel.

Automatisation de l'Exploitation : Nuclei et Metasploit

Comprendre les outils d'exploitation automatisée est essentiel pour les équipes défensives : ce sont les mêmes outils qu'utilisent les attaquants pour scanner et compromettre massivement.

Nuclei : Templates CVE et Scanning à Grande Échelle

# Installer Nuclei
go install -v github.com/projectdiscovery/nuclei/v3/cmd/nuclei@latest

# Scanner avec les templates CVE récents
nuclei -u https://target.com -t cves/ -severity critical,high

# Scanner spécifiquement CVE-2024-21762 (FortiGate)
nuclei -u https://fortigate.target.com   -t cves/2024/CVE-2024-21762.yaml   -v

# Scanner un scope complet depuis un fichier IP
nuclei -l ips.txt   -t cves/   -severity critical   -rate-limit 100   -o results.txt   -json

# Pipeline complet : découverte + exploitation detection
subfinder -d target.com | httpx -silent |   nuclei -t cves/ -severity critical,high -o vulns.jsonl

Le repository nuclei-templates contient 9 000+ templates CVE maintenus par la communauté. Le temps entre la publication d'une CVE et l'apparition d'un template Nuclei fonctionnel est en moyenne 3,7 jours en 2024, contre 11 jours en 2022. Cette accélération reflète la professionnalisation des opérations offensives.

Metasploit Framework : Modules CVE en Production

# Rechercher les modules CVE récents dans Metasploit
msfconsole -q
msf6 > search cve:2024 type:exploit rank:excellent

# Exemple : exploiter ProxyLogon
msf6 > use exploit/windows/http/exchange_proxylogon_rce
msf6 exploit(exchange_proxylogon_rce) > set RHOSTS 192.168.1.100
msf6 exploit(exchange_proxylogon_rce) > set LHOST 10.0.0.1
msf6 exploit(exchange_proxylogon_rce) > check
# [+] 192.168.1.100:443 - The target is vulnerable.
msf6 exploit(exchange_proxylogon_rce) > run

La présence d'un module Metasploit de rang "excellent" pour une CVE fait systématiquement monter le score EPSS au-dessus de 0,7. C'est un signal fort pour les équipes patch management : si votre CVE a un module Metasploit "excellent", considérez-la comme activement exploitée.

Métriques Industrielles : MTTD, MTTR et TTX

Trois métriques définissent la posture de réponse aux vulnérabilités :

MTTD (Mean Time To Detect) : temps moyen entre la disponibilité d'un patch et sa détection dans votre inventory. Pour les organisations matures avec un outil de gestion des vulnérabilités (Tenable, Qualys, Rapid7), le MTTD est inférieur à 24h. Sans outil automatisé, il dépasse souvent 30 jours.

MTTR (Mean Time To Remediate) : temps moyen entre la détection et l'application du patch. Selon le rapport Ponemon 2024, le MTTR médian est de 60 jours pour les grandes entreprises et 45 jours pour les PME (qui ont moins de contraintes de processus). Pour les CVE critiques, l'objectif ANSSI recommandé est MTTR < 72h.

TTX (Time to eXploit) : temps entre la publication publique et la première exploitation. Pour les CVE avec des assets populaires exposés sur Internet (Exchange, Fortinet, Citrix, Cisco), le TTX médian 2024 est de 5,4 jours selon Mandiant Threat Intelligence. Pour les top 10 vulnérabilités les plus exploitées, ce TTX descend à 1,2 jour.

Programme de Patch Management Accéléré

Réduire le MTTR sous les 72h pour les CVE critiques nécessite une transformation organisationnelle et technique profonde. Les étapes clés d'un programme mature :

Inventaire continu : CMDB à jour en temps réel (pas en mode projet annuel). Des outils comme Tenable.io, Qualys VMDR ou CrowdStrike Spotlight maintiennent un inventaire des assets et leur état de patching en continu. Sans cela, la priorisation EPSS/CVSS ne peut pas être opérationnalisée.

Automatisation du déploiement : les patches OS (Windows Update, yum/apt) doivent être déployés automatiquement pour les sévérités critiques sur les systèmes non critiques (postes de travail, serveurs de développement). Les systèmes de production utilisent un processus accéléré avec fenêtre de maintenance de 4h maximum et rollback automatique en cas d'échec.

Escalade hors-cycle : un processus d'urgence clair pour les CVE type ProxyLogon ou FortiGate. Qui approuve un patch d'urgence hors cycle ? En combien de temps ? Qui teste la compatibilité ? Ces questions doivent avoir des réponses documentées avant l'incident, pas pendant.

Métriques et reporting : un tableau de bord MTTD/MTTR par sévérité, par système, par équipe, mis à jour quotidiennement. Les organisations soumises à NIS 2 (directive applicable depuis octobre 2024) doivent démontrer leur capacité à patcher sous 72h les vulnérabilités critiques affectant leurs systèmes essentiels, sous peine de sanctions financières pouvant atteindre 10 millions d'euros ou 2% du CA mondial.

Renforcez votre posture de sécurité

Audit, pentest, formation, conseil — une approche sur-mesure adaptée à votre contexte.

Demander un devis [email protected]

Zero-day exploitation en 2026 : le marché et l'économie de l'exploitation

Le passage de 771 jours en 2018 à des exploitations en heures en 2026 n'est pas seulement une évolution technique. C'est le reflet d'un marché de l'exploitation qui a maturé, professionnalisé ses acteurs et réduit ses coûts de production de façon spectaculaire. Comprendre cette économie est indispensable pour calibrer les investissements défensifs.

Le marché des zero-days : structure et acteurs en 2026

Le marché des zero-days s'est structuré en trois segments distincts avec des acteurs, des prix et des motivations différentes :

• Le marché gris (bug bounty et programmes de divulgation responsable) : les programmes de bug bounty des grandes entreprises tech (Google VRP, Microsoft Bug Bounty, Apple Security Research) paient entre 5 000 et 1 million de dollars pour des zero-days selon la criticité. Ces programmes ont considérablement amélioré les incitations à la divulgation responsable, mais les montants restent inférieurs au marché noir pour les vulnérabilités les plus critiques.
• Le marché blanc légal (courtiers d'exploits gouvernementaux) : des entreprises comme Zerodium, NSO Group ou Candiru achètent des zero-days pour des prix allant jusqu'à 2,5 millions de dollars (iOS zero-click, prix affiché Zerodium 2024) et les revendent à des gouvernements. Ce marché est légal dans la plupart des juridictions mais éthiquement contesté.
• Le marché noir criminel : les groupes ransomware, les Initial Access Brokers et les acteurs de la cybercriminalité échangent des zero-days et des exploits contre des paiements en cryptomonnaies sur des forums underground. Les prix sont généralement inférieurs au marché blanc (10 000 à 200 000 dollars selon la criticité) mais les transactions ne nécessitent pas d'identification.

Pourquoi le time-to-exploit s'est effondré

La réduction spectaculaire du délai entre la publication d'une CVE et son exploitation active résulte de plusieurs évolutions convergentes sur la période 2020-2026 :

• Publication automatique des PoC : des bots surveillent en permanence les nouvelles entrées NVD et les bulletins de sécurité des éditeurs. Quand une CVE est publiée avec suffisamment de détails techniques, des développeurs commencent immédiatement à produire des PoC. Nuclei et ses templates communautaires permettent de passer d'une description de CVE à un scanner fonctionnel en quelques heures.
• IA assistée pour la production d'exploits : les LLM réduisent la compétence technique requise pour adapter un PoC à un exploit fonctionnel. Un attaquant qui comprend les bases de la programmation peut utiliser des LLM pour combler les lacunes techniques, réduisant le délai de production d'exploit de jours à heures.
• Marchés d'accès initiaux : les Initial Access Brokers ont créé un marché liquide pour les accès initiaux. Cela crée une demande immédiate pour les nouveaux exploits dès leur publication.
• Infrastructure d'exploitation as-a-service : des plateformes comme C2-as-a-service (Cobalt Strike as a service, Sliver as a service) réduisent l'infrastructure nécessaire à l'exploitation. Un attaquant peut louer une infrastructure C2 complète et se concentrer sur l'exploitation sans gérer la logistique post-compromission.

Les catégories de vulnérabilités exploitées en moins de 24h en 2026

Toutes les CVE ne sont pas exploitées aussi rapidement. L'analyse des incidents de 2025-2026 révèle que les exploitations ultra-rapides (moins de 24h) se concentrent sur des catégories spécifiques :

• RCE non authentifié sur des services exposés Internet : Langflow (20h), cPanel, serveurs Exchange. Ces vulnérabilités permettent une exploitation directe sans credentials et sur des cibles accessibles depuis Internet.
• Authentication bypass sur des portails d'entreprise : VPN, passerelles web, portails B2B. L'accès initial qu'ils fournissent est immédiatement monétisable via les IAB.
• Escalade de privilèges dans les environnements cloud : des CVE sur les plateformes de gestion cloud (AWS, Azure, GCP) ou les outils d'orchestration (Kubernetes, Terraform) permettent une escalade latérale vers des ressources cloud critiques.
• Vulnérabilités dans les solutions de sauvegarde et de management : Veeam, Veritas, Kaseya, SolarWinds — ces outils ont accès à des données critiques et sont des cibles prioritaires pour les opérateurs ransomware.

Foire aux questions — Time-to-exploit et zero-days

Comment prioriser la réponse face à un zero-day publié sans patch ?

Quand un zero-day est publié sans patch (full disclosure ou à l'expiration d'un délai de responsible disclosure), activez votre processus d'urgence : identifiez en moins de 2 heures tous les systèmes affectés dans votre SI, évaluez leur exposition réseau (Internet vs interne), et implémentez des mesures compensatoires immédiates (isolation réseau, désactivation du service vulnérable si possible, règles WAF). Contactez l'éditeur pour un ETA sur le patch. Souscrivez aux alertes CERT-FR et au catalogue KEV CISA pour les zero-days activement exploités — ces sources publient des IoC et des recommandations de mitigation quand elles sont disponibles.

Les assurances cyber couvrent-elles les pertes liées aux zero-days ?

La couverture dépend des termes spécifiques de chaque police. La plupart des assurances cyber couvrent les pertes résultant d'une compromission, y compris via des zero-days, à condition que l'organisation puisse démontrer qu'elle avait mis en œuvre des mesures de sécurité raisonnables. Certaines polices excluent les "known vulnerabilities" (CVE publiées) si un patch était disponible et n'a pas été appliqué dans un délai raisonnable. La définition de "délai raisonnable" est souvent floue et peut être sujette à litige après un incident. Consultez votre assureur pour clarifier ces termes avant un incident.