En bref. Selon l'analyse publiée par Microsoft le 2 novembre 2026, environ 2000 CVE ont été liées à une exploitation réelle sur environ 383000 publiées depuis 1999, soit environ 0,5 %. Ces failles exploitées se concentrent sur la prise de contrôle : exécution de code à distance, élévation de privilèges, contournement d'authentification, qui représentent 78 % des cas exploités. Pendant ce temps, le correctif médian prend plus d'un mois sur les serveurs Windows et plus d'un an sur les équipements réseau. Pour une équipe DevSecOps, la conséquence est un tri par impact et par exposition plutôt que par volume ou par score seul.
Ce que dit l'analyse
Microsoft a classé les CVE (Common Vulnerabilities and Exposures, l'identifiant public des vulnérabilités) publiées jusqu'en septembre 2026 dans son catalogue, selon deux axes : la classe d'impact (ce qu'un attaquant obtient) et la plateforme touchée (Windows, Linux/Unix, mobile, équipements réseau, IoT/OT, hyperviseurs, paquets de développement). Chaque CVE est rangée dans l'impact le plus grave qu'elle permet directement : une faille qui contourne l'authentification et mène directement à l'exécution de code est classée en exécution de code à distance (RCE, remote code execution).
Un petit nombre de failles, très concentrées
Environ 77 % des CVE publiées touchent du code applicatif (serveurs, applications web, navigateurs, bibliothèques), 23 % du code système (noyaux, pilotes, firmware).
Le sous-ensemble exploité, 2056 CVE dans la figure de Microsoft, a un profil très différent :
| Classe d'impact | Part des CVE publiées | Part des CVE exploitées | |---|---|---| | RCE côté serveur | 20 % | 37 % | | Élévation locale de privilèges | 11 % | 18 % | | RCE côté client | 4 % | 13 % | | XSS (script intersite) | 15 % | 4 % | | Déni de service | 16 % | 7 % |
Le code système passe de 23 % des CVE publiées à 41 % des CVE exploitées.
Microsoft ajoute une nuance utile : la classification déclarée d'une faille ne reflète pas toujours ce qu'un attaquant obtient en pratique. Certaines failles décrites comme des RCE ne produisent qu'un déni de service en conditions réelles. L'impact démontré compte plus que l'impact annoncé.
Corriger est lent, exploiter est rapide
Selon les données 2026 de Microsoft Security Exposure Management, le délai médian de correctif est d'environ deux semaines sur les postes Windows, de plus d'un mois sur les serveurs Windows, de plus de dix semaines sur les serveurs Linux et les applications macOS, et de plus d'un an sur les équipements réseau. Les systèmes les plus critiques restent exposés le plus longtemps.
Côté attaquants, Microsoft cite deux sources :
- selon VulnCheck, 29 % des exploits de 2025 ont été lancés dans la journée suivant la publication de la CVE ;
- selon la CISA (l'agence américaine de cybersécurité), le délai moyen entre la publication d'une CVE et son entrée au catalogue KEV (Known Exploited Vulnerabilities, la liste des failles exploitées) est passé de 89 jours pour les CVE publiées en 2024 à 57 jours pour celles de 2025. Pour les CVE de 2026 publiées jusqu'en septembre, il tombe à 20 jours, avec une médiane de 3 jours.
Microsoft indique que des travaux du secteur désignent les progrès de l'IA comme un facteur important de la réduction du temps nécessaire pour développer un exploit.
Le critère : impact et exposition
Microsoft retient deux critères pour mesurer la valeur d'une faille pour un attaquant :
- l'impact : ce que l'exploitation donne, comme l'exécution de code ou une élévation de privilèges ;
- l'exposition : la position de l'actif dans l'environnement, définie par les identités, privilèges et connexions accessibles depuis lui.
Les deux combinés donnent le rayon d'impact. Microsoft souligne que les serveurs utilisent souvent des comptes de service ou des identités cloud aux permissions supérieures à leurs besoins : compromettre un tel serveur ouvre l'accès à d'autres ressources.
En deuxième rang, Microsoft cite deux cas qui dépendent du contexte : le déni de service sur un actif dont la disponibilité est vitale, et la divulgation de secrets ou d'identifiants, qui rejoint le chemin des identités privilégiées.
Qui est concerné
Toute équipe qui gère un flux de vulnérabilités supérieur à sa capacité de correction, c'est-à-dire presque toutes. En particulier :
- les équipes DevSecOps dont les scanners (SCA, conteneurs, infrastructure) produisent des centaines d'alertes par semaine ;
- les équipes d'exploitation qui gèrent des serveurs Linux et des équipements réseau, là où les délais médians sont les plus longs ;
- les RSSI qui doivent justifier un ordre de priorité devant la direction ou un auditeur.
Méthode de priorisation : contrôles et vérification
Microsoft présente ensuite ses propres produits. Les étapes ci-dessous traduisent l'analyse en méthode indépendante de l'outillage ; ce sont des bonnes pratiques, pas des consignes de Microsoft.
1. Ajouter la classe d'impact à chaque alerte
Le score CVSS (Common Vulnerability Scoring System) seul mélange des failles de nature très différente. Ajoutez à vos tickets un champ « classe d'impact » avec au moins quatre valeurs : RCE serveur, RCE client, élévation de privilèges, contournement d'authentification. Ces quatre classes portent l'essentiel de l'exploitation observée.
Vérification : sur vos 50 tickets de vulnérabilité les plus anciens, quelle part relève de ces classes ? Si elle est élevée, l'ordre de traitement est à revoir.
2. Croiser avec l'exploitation connue
Le catalogue KEV de la CISA est public et téléchargeable. Une faille présente dans KEV et dans votre inventaire passe en tête de file, quel que soit son score. Avec une médiane de 3 jours entre publication et entrée au catalogue pour les CVE de 2026, ce croisement doit être automatique et quotidien.
Vérification : mesurez le délai entre l'ajout d'une CVE au catalogue KEV et l'ouverture du ticket chez vous. Au-delà de 24 heures, l'automatisation manque.
3. Qualifier l'exposition de chaque actif
Pour chaque serveur et équipement : est-il joignable depuis Internet ? Quelles identités porte-t-il, avec quels droits ? Un même CVE sur un serveur exposé portant une identité cloud privilégiée et sur un serveur interne isolé ne mérite pas le même délai.
Vérification : prenez trois serveurs critiques et listez les permissions effectives de leurs comptes de service. Toute permission inutilisée réduit le rayon d'impact sans attendre de correctif.
4. Fixer des délais par classe, pas un délai unique
Une politique du type « critique : 30 jours » est inadaptée quand l'exploitation suit la publication en quelques jours. Définissez des délais différenciés : très courts pour une faille de prise de contrôle exploitée sur un actif exposé, plus longs pour un déni de service sur un actif non critique.
Vérification : comparez vos délais réels de correctif par type de plateforme aux médianes publiées par Microsoft. Les équipements réseau sont souvent le point le plus en retard.
5. Prévoir les compensations pour ce qui ne se corrige pas
Microsoft rappelle que certains systèmes anciens ou hors support ne peuvent pas être corrigés. Pour eux : isolement réseau, réduction des identités et des droits, surveillance renforcée. Ces mesures doivent être documentées comme des exceptions avec une date de revue.
6. Intégrer le tri dans la chaîne CI/CD
Dans le pipeline, le même principe s'applique aux dépendances : bloquer la fusion sur une dépendance qui porte une faille connue comme exploitée, et traiter le reste par lot planifié. Cela évite de bloquer les équipes sur des alertes à faible risque tout en arrêtant les plus dangereuses.
FAQ
Quelle part des CVE est réellement exploitée ?
Selon Microsoft, environ 2000 CVE sur environ 383000 publiées entre 1999 et septembre 2026 ont été liées à une exploitation réelle, soit environ 0,5 %.
Quelles vulnérabilités les attaquants exploitent-ils le plus ?
Les failles de prise de contrôle : exécution de code à distance, élévation locale de privilèges et contournement d'authentification. Elles représentent 78 % des vulnérabilités exploitées dans l'analyse de Microsoft.
En combien de temps une faille est-elle exploitée ?
Microsoft cite VulnCheck : 29 % des exploits de 2025 ont été lancés dans la journée suivant la publication de la CVE. Pour les CVE de 2026 publiées jusqu'en septembre, le délai médian avant entrée au catalogue KEV de la CISA est de 3 jours.
Le score CVSS suffit-il pour prioriser ?
Microsoft recommande de prioriser au-delà du seul CVSS, en tenant compte de l'exploitabilité, de l'exposition à Internet et de la criticité de l'actif.
Sources
- Microsoft Security Blog, What exploited vulnerabilities have in common: A data-driven analysis of real-world attacks, 2 novembre 2026 : https://www.microsoft.com/en-us/security/blog/2026/11/02/exploited-vulnerabilities-common-data-driven-analysis-real-world-attacks
- CISA, catalogue Known Exploited Vulnerabilities : https://www.cisa.gov/known-exploited-vulnerabilities-catalog
Pour mettre en place un tri des vulnérabilités fondé sur l'exploitation et l'exposition dans votre chaîne de développement, WeeSec accompagne les équipes sur le DevSecOps.