Le catalogue KEV de la CISA recense les vulnérabilités dont l’exploitation dans la nature est avérée. C’est l’un des meilleurs filtres pour décider quoi corriger en premier, à condition de savoir ce qu’il contient. Nous avons téléchargé le fichier officiel (1 728 entrées, version du 27 septembre 2026) et l’avons passé au crible : qui est concerné, à quelle vitesse, quelles failles servent aux rançongiciels, et ce que change la nouvelle directive de juin 2026.
Ce qu’il faut retenir
- Le rythme s’accélère : environ 27 ajouts par mois en 2026 contre 20 en 2025, soit un tiers de plus. Septembre 2026 (mois non terminé) est déjà à 41.
- Microsoft pèse 22,5 % du catalogue (389 entrées, dont 172 pour Windows), mais aucun éditeur n’est épargné : 1 728 entrées réparties sur 283 éditeurs.
- Les failles récentes dominent : depuis 2023, environ deux entrées sur trois portent un identifiant CVE de l’année de leur ajout. Mais 96 entrées ont dix ans d’écart ou plus.
- 361 entrées (20,9 %) sont marquées « utilisées par des rançongiciels », avec des taux très élevés chez les éditeurs d’accès distants et de pare-feu : SonicWall 68 %, Fortinet 47 %, Palo Alto Networks 40 %. Chez Apple et Google : 0 %.
- Depuis la directive BOD 26-04 (10 juin 2026), 88 des 111 ajouts ont un délai de trois jours, et 69 exigent un « triage forensique » : on ne corrige plus seulement, on vérifie si on a déjà été compromis.
Le KEV en deux minutes, et ce qu’il ne dit pas
Chaque entrée du KEV (« Known Exploited Vulnerabilities ») associe un identifiant CVE à un éditeur, un produit, une date d’ajout, une échéance de correction fixée par la CISA et deux indicateurs : l’utilisation connue par des rançongiciels et, depuis juin 2026, l’exigence d’un triage forensique. Le critère d’entrée est l’exploitation active avérée, pas la gravité théorique : un score CVSS de 9,8 n’y figure pas tant que personne n’a exploité la faille, alors qu’un score de 7 y entre dès qu’une campagne est observée.
Trois précautions avant de tirer des conclusions :
- Absent du KEV ne veut pas dire « pas exploité ». Le catalogue reflète ce que la CISA a pu documenter, avec un tropisme américain et une couverture inégale des produits moins répandus.
- Le nombre d’entrées d’un éditeur n’est pas une note de qualité : il dépend de la taille de son parc, de l’intérêt des attaquants et de l’attention des chercheurs.
- Le fichier ne contient ni la date de publication du CVE ni celle du correctif : impossible d’y lire un délai réel entre correctif et exploitation. Nous utilisons l’année de l’identifiant CVE comme indicateur grossier de fraîcheur.
Méthode
Source : le fichier JSON officiel publié par la CISA (catalogue), version 2026.09.27, premières entrées datées du 3 novembre 2021. Tous les chiffres ci-dessous sont calculés sur ce fichier par un court script Python ; les regroupements (familles de faiblesses, éditeurs comptant au moins 15 entrées) sont détaillés là où ils servent. Aucune donnée externe n’est mélangée : ce qui n’est pas dans le fichier n’est pas affirmé.
1. Le rythme s’accélère
Le catalogue a été lancé en novembre 2021 avec un important stock de failles anciennes, ce qui explique les deux premières années : 311 ajouts pour les deux derniers mois de 2021, puis 555 en 2022, dont une part de rattrapage. Depuis 2023, le flux est plus régulier :
| Année d’ajout | Entrées | Part avec un CVE de la même année | Part marquée « rançongiciel » |
|---|---|---|---|
| 2021 (nov.-déc.) | 311 | 39 % | 27 % |
| 2022 | 555 | 16 % | 24 % |
| 2023 | 187 | 65 % | 23 % |
| 2024 | 186 | 62 % | 24 % |
| 2025 | 245 | 62 % | 13 % |
| 2026 (au 27/09) | 244 | 67 % | 11 % |
Rapporté au mois, 2026 tourne autour de 27 ajouts contre 20 en 2025. Le catalogue ne permet pas de dire si les attaquants exploitent davantage de failles ou si elles sont mieux détectées et signalées : les deux hypothèses produisent la même courbe.
2. Qui : Microsoft en tête, et tout le monde derrière
| Éditeur | Entrées au KEV | Dont « rançongiciel » |
|---|---|---|
| Microsoft | 389 | 117 |
| Cisco | 99 | 7 |
| Apple | 94 | 0 |
| Adobe | 82 | 11 |
| 75 | 0 | |
| Oracle | 46 | 13 |
| Apache | 40 | 8 |
| Ivanti | 35 | 12 |
| Linux (noyau) | 31 | 2 |
| Fortinet | 30 | 14 |
Windows à lui seul totalise 172 entrées, devant les produits multiples d’Apple (53) et le moteur V8 de Chromium (41). Deux lignes du classement rappellent que le passé ne disparaît pas : Internet Explorer (36 entrées) et Adobe Flash Player (33) sont des produits abandonnés par leurs éditeurs et figurent pourtant au catalogue.
À retenir côté défense : la moitié des éditeurs du haut du tableau sont des produits que tout le monde possède (système, navigateur, bureautique). Le « patch Tuesday » et les mises à jour automatiques des navigateurs peuvent en principe couvrir une grande part du KEV. Le point faible le plus fréquent est alors celui des équipements que personne ne met à jour automatiquement (routeurs, pare-feu, passerelles VPN, hyperviseurs).
3. Des failles récentes, mais un passé qui ne meurt pas
Depuis 2023, entre 62 % et 67 % des entrées ajoutées une année donnée portent un identifiant CVE de cette même année. Autrement dit, la plupart des failles du catalogue sont exploitées dans les mois qui suivent leur découverte. Le délai dont vous disposez pour corriger se compte en semaines, pas en trimestres.
À l’autre bout, 96 entrées (5,6 %) ont un identifiant CVE datant d’au moins dix ans avant leur ajout. Exemple : la faille SMBv1 CVE-2017-0144 n’a été ajoutée qu’en février 2022, et elle est marquée comme utilisée par des rançongiciels. Un parc contient presque toujours un vieux système oublié : l’inventaire compte autant que la rapidité.
4. Rançongiciels : ce que le drapeau révèle
Le champ « Known Ransomware Campaign Use » vaut « Known » pour 361 des 1 728 entrées (20,9 %). Son interprétation demande deux précautions.
- Le drapeau est posé après coup. La part d’entrées marquées passe d’environ 24 % pour 2022-2024 à 13 % pour 2025 et 11 % pour 2026. Ce n’est pas un recul des rançongiciels : les entrées récentes ont simplement eu moins de temps pour être rattachées à une campagne. Les chiffres récents sont sous-estimés.
- Un drapeau « Unknown » n’est pas une absence d’usage, seulement l’absence de confirmation publique.
Le classement est net. Les éditeurs de pare-feu, VPN et accès distants (SonicWall, Fortinet, Palo Alto Networks, Ivanti, VMware, Citrix) sont marqués dans un tiers à deux tiers des cas. Microsoft, avec 117 entrées marquées, fournit à lui seul 32 % de tous les drapeaux. Apple, Google et Samsung sont à 0 % : des failles de navigateur ou de mobile mènent plutôt à des postes individuels qu’à un réseau d’entreprise, ce qui est cohérent avec la logique des rançongiciels (hypothèse plausible, que le catalogue seul n’établit pas).
Nous avons aussi regardé le type de faiblesse (champ CWE, renseigné pour 1 553 entrées). Les failles de corruption mémoire (CWE-119, 122, 125, 190, 415, 416, 476, 787, 843) représentent 27 % des entrées non marquées mais seulement 13 % des entrées marquées rançongiciel. À l’inverse, les erreurs de traitement des entrées (injection de commande, de code ou SQL, désérialisation, traversée de chemin, téléversement, validation d’entrée) pèsent 38 % contre 33 %, et les failles d’authentification ou de contrôle d’accès 16 % contre 11 %. Le profil type d’une faille de rançongiciel est donc une faille logique, sans authentification, sur un service exposé plutôt qu’un exploit mémoire de laboratoire. Attention : les CWE sont attribués de façon parfois approximative, lisez ces pourcentages comme un ordre de grandeur.
Des failles marquées « Known » que vous reconnaîtrez : Log4Shell (CVE-2021-44228), ProxyLogon (CVE-2021-26855), MOVEit Transfer (CVE-2023-34362), Citrix Bleed (CVE-2023-4966), PAN-OS (CVE-2024-3400). Une faille très médiatisée peut au contraire rester « Unknown » : la faille Cisco IOS XE CVE-2023-20198 en est un exemple.
5. Juin 2026 : la directive BOD 26-04 change les règles
Le 10 juin 2026, la CISA a publié la directive opérationnelle contraignante BOD 26-04 « Prioritizing Security Updates Based on Risk ». Elle s’impose aux agences civiles fédérales américaines, pas aux entreprises, mais elle fixe une méthode que n’importe quelle organisation peut reprendre. Son constat de départ : l’usage de l’IA par les attaquants « peut réduire encore le temps dont disposent les défenseurs pour réagir entre la publication d’un correctif et l’exploitation éventuelle » (notre traduction).
Le principe : au lieu d’un délai unique par entrée du KEV, le délai dépend de quatre questions posées pour chaque actif :
- l’actif est-il exposé publiquement (accessible sans authentification depuis Internet) ?
- la faille est-elle dans le KEV ?
- l’exploitation est-elle automatisable par l’attaquant ?
- l’impact technique est-il un contrôle total (exécution de code, droits administrateur, fuite d’identifiants) ou seulement partiel (déni de service, par exemple) ?
La CISA publie elle-même les réponses aux questions 2, 3 et 4 pour chaque CVE (programme Vulnrichment) ; la question 1 est propre à votre inventaire. La table officielle compte seize lignes. Voici la version condensée :
| Situation de l’actif | Délai |
|---|---|
| Exposé, dans le KEV, impact total | 3 jours + triage forensique |
| Exposé, dans le KEV, impact partiel | 3 jours si automatisable, sinon 14 jours |
| Non exposé, dans le KEV, automatisable et impact total | 3 jours + triage forensique |
| Non exposé, dans le KEV, autres cas | 14 jours |
| Exposé, hors KEV, automatisable et impact total | 3 jours |
| Exposé, hors KEV, un seul de ces deux critères | 14 jours |
| Exposé, hors KEV, ni l’un ni l’autre | 60 jours |
| Non exposé, hors KEV, automatisable | 60 jours |
| Non exposé, hors KEV, non automatisable | à la prochaine mise à niveau du système |
Deux détails de la directive valent la peine d’être retenus. Les délais partent de l’ajout au KEV (ou de la détection de la faille sur l’actif, si elle est antérieure). Et les délais sont dynamiques : retirer un équipement d’Internet le fait passer de « exposé » à « non exposé » et allonge d’autant son délai, ce qui fait de la réduction de la surface d’attaque une mesure de correction à part entière.
Que disent les données ? Depuis le 10 juin, 111 entrées ont été ajoutées : 88 avec un délai de 3 jours (contre 31 sur les 1 617 précédentes) et 23 avec 14 jours. Le champ « triage forensique » vaut « Yes » pour 69 d’entre elles, alors qu’il valait « No » pour toutes les entrées antérieures. Avant juin, le délai dominant était de 21 jours (63 % des entrées). À l’heure où nous écrivons, les deux dernières entrées (27 septembre 2026) sont deux failles Citrix NetScaler avec échéance à trois jours et triage forensique.
Le triage forensique, en pratique
C’est la nouveauté la plus intéressante pour les équipes de défense, et elle recoupe ce que nous décrivons dans l’article sur le sanity check après incident. Pour une faille de la ligne « 3 jours + triage », on ne se contente pas de corriger : on vérifie que le système n’a pas déjà été compromis. La CISA détaille six étapes, avec des durées cibles indicatives (l’exigence est qu’un triage adéquat soit fait, pas de respecter ces durées) :
- Cadrer (dans les 2 premières heures) : identifier les actifs concernés, mobiliser l’équipe, ouvrir un canal de communication hors bande, qui ne dépend pas d’une infrastructure potentiellement compromise.
- Préserver et collecter les preuves (2 à 24 h) : données volatiles d’abord (mémoire, cache), et « ne pas modifier ni corriger les systèmes avant la collecte lorsque c’est possible », avec un journal de collecte.
- Corriger et stabiliser (2 à 24 h) : appliquer les correctifs après la collecte, car le correctif peut détruire des artefacts.
- Contenir (6 à 24 h) : isoler sans alerter l’attaquant, en coordination avec la collecte (un confinement prématuré détruit des preuves).
- Analyser (24 à 48 h) : accès non autorisé, mouvement latéral, persistance, préparation ou exfiltration de données, indicateurs de compromission à rechercher ailleurs.
- Décider de l’escalade (48 à 72 h) : rapport chronologique, puis « aucune compromission constatée », « compromission confirmée » ou « suspectée ».
Le point contre-intuitif est l’étape 2 : on collecte avant de corriger. C’est l’inverse du réflexe habituel (« on patche tout de suite »), et c’est ce qui permet de savoir si l’attaquant est déjà entré.
6. En faire une politique interne
Une PME n’a pas à copier la directive, mais elle peut en garder l’ossature en cinq points :
- Inventorier ce qui est exposé à Internet (l’exposition est la variable que personne d’autre ne peut renseigner à votre place) : un scan de votre plage publique et la liste des redirections de ports sur votre box ou votre pare-feu suffisent pour commencer.
- Surveiller le KEV automatiquement et le croiser avec l’inventaire (script ci-dessous), plutôt que de lire des bulletins.
- Fixer trois vitesses : 72 heures pour « exposé et dans le KEV », 14 jours pour « dans le KEV mais non exposé », le reste dans le cycle normal.
- Prévoir la collecte de preuves avant de patcher sur les équipements de périmètre (capture mémoire ou journaux exportés hors de l’équipement), et écrire qui décide de couper l’accès.
- Mesurer : nombre d’entrées KEV touchant votre inventaire, délai moyen de traitement, nombre d’équipements exposés sans propriétaire identifié.
Un script de veille (lecture seule)
Ce script télécharge le catalogue officiel, ne garde que les entrées récentes qui touchent votre inventaire (mots-clés à adapter) et signale celles qui exigent un triage forensique ou sont liées à des rançongiciels. Il n’écrit rien et n’utilise que la bibliothèque standard de Python. Nous l’avons exécuté sur le catalogue du 27 septembre 2026.
#!/usr/bin/env python3
"""kev-watch.py : croise le catalogue KEV de la CISA avec votre inventaire.
Usage : ./kev-watch.py [jours] (défaut : entrées ajoutées ces 14 derniers jours)"""
import json, sys, urllib.request, datetime as dt
URL = "https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json"
# À adapter : un mot-clé par ligne, cherché dans « éditeur + produit » (minuscules).
INVENTAIRE = ["fortinet", "fortios", "citrix", "netscaler", "ivanti", "palo alto", "sonicwall",
"microsoft exchange", "microsoft windows", "veeam", "vmware", "cisco ios xe", "apache"]
jours = int(sys.argv[1]) if len(sys.argv) > 1 else 14
depuis = (dt.date.today() - dt.timedelta(days=jours)).isoformat()
req = urllib.request.Request(URL, headers={"User-Agent": "kev-watch/1.0"})
kev = json.load(urllib.request.urlopen(req, timeout=60))
print(f"Catalogue {kev['catalogVersion']} : {kev['count']} entrées. Ajouts depuis {depuis} qui touchent votre inventaire :\n")
n = 0
for v in sorted(kev["vulnerabilities"], key=lambda v: v["dateAdded"], reverse=True):
if v["dateAdded"] < depuis:
break
cible = f"{v['vendorProject']} {v['product']}".lower()
if not any(k in cible for k in INVENTAIRE):
continue
n += 1
drapeaux = []
if v.get("forensicTriage") == "Yes":
drapeaux.append("TRIAGE FORENSIQUE")
if v.get("knownRansomwareCampaignUse") == "Known":
drapeaux.append("RANSOMWARE")
print(f"{v['dateAdded']} {v['cveID']:<16} {v['vendorProject']} / {v['product']}")
print(f" échéance CISA : {v['dueDate']} {' | '.join(drapeaux)}")
print(f" {v['vulnerabilityName']}\n")
print(f"{n} entrée(s) à traiter." if n else "Rien de nouveau pour votre inventaire.")À placer dans un cron quotidien, avec l’envoi du résultat par e-mail ou vers votre outil de tickets. Pour un inventaire précis, remplacez les mots-clés par la sortie de votre outil de gestion de parc ou de votre scanner de vulnérabilités.
Les pièges à éviter
- Traiter le KEV comme une liste exhaustive. Une faille critique absente du KEV sur un équipement exposé mérite le même sérieux ; la directive elle-même prévoit 3 jours pour une faille exposée, hors KEV, automatisable et à impact total.
- Confondre « corrigé » et « sain ». Un correctif installé après l’exploitation n’expulse pas l’attaquant : c’est toute la raison du triage forensique.
- Oublier les équipements sans mise à jour automatique : pare-feu, VPN, hyperviseurs, NAS, imprimantes, caméras. Ce sont ceux qui affichent les taux « rançongiciel » les plus élevés.
- Fixer des délais sans propriétaire. Un délai de 72 heures n’a de sens que si une personne nommée peut décider d’un arrêt de service.
- Lire les pourcentages comme des probabilités. « 47 % des failles Fortinet du KEV sont liées à des rançongiciels » ne signifie pas que votre Fortinet a 47 % de chances d’être attaqué : c’est une statistique sur un catalogue, pas sur un parc.
En résumé
Le KEV répond à une question que le score CVSS ne pose pas : quelles failles sont réellement utilisées ? Ses 1 728 entrées montrent un flux en hausse, une majorité de failles récentes, un fort tropisme des rançongiciels pour les équipements d’accès distant, et une nouvelle doctrine américaine où l’exposition à Internet, l’automatisation de l’exploit et l’impact déterminent le délai. La bonne réponse locale tient en trois gestes : savoir ce qui est exposé, surveiller le KEV automatiquement, et vérifier qu’on n’est pas déjà entré avant de déclarer qu’on est corrigé.
Transparence : cet article a été rédigé avec l’aide d’un assistant Claude. Les chiffres sont calculés sur le fichier officiel du KEV (version 2026.09.27) ; le script est fourni à titre d’exemple et doit être adapté à votre environnement. Les références ci-dessous ont été consultées en septembre 2026.
À lire aussi
- Rançongiciels : ce qui se passe avant le chiffrement : deux intrusions réelles, de 2 heures à 9 jours, et les failles KEV qu’elles utilisent.
- Sauvegardes : la règle 3-2-1-1-0 : pourquoi les attaquants visent d’abord les sauvegardes, et comment prouver qu’on sait restaurer.
Sources
- CISA, Known Exploited Vulnerabilities Catalog (fichier JSON, version 2026.09.27) : cisa.gov
- CISA, BOD 26-04 « Prioritizing Security Updates Based on Risk » (10 juin 2026) : cisa.gov
- CISA, Implementation Guidance BOD 26-04 (Table 1, étapes du triage forensique) : cisa.gov
- CISA, guide SSVC (méthode dont s’inspire la Table 1) : cisa.gov
- CISA, programme Vulnrichment (KEV, automatisable, impact technique publiés dans les enregistrements CVE) : github.com/cisagov/vulnrichment
- MITRE, Common Weakness Enumeration (classification des faiblesses) : cwe.mitre.org