KEV : Le catalogue des vulnérabilités qui brûlent (vraiment)

Après avoir vu comment EPSS prédit l’exploitation, passons à KEV : le catalogue qui ne prédit rien du tout, parce qu’il est déjà trop tard.

KEV, c’est la liste des CVE qui sont activement exploitées dans la nature. Si votre système est vulnérable à une CVE dans KEV, vous n’êtes pas “à risque”, vous êtes déjà en danger.

C’est le coup de fil des pompiers qui vous dit : “Monsieur, votre maison brûle. Maintenant.”

Qu’est-ce que KEV ?

KEV (Known Exploited Vulnerabilities) est un catalogue public maintenu par la CISA (Cybersecurity and Infrastructure Security Agency, USA).

C’est une liste de CVE qui ont été confirmées comme exploitées dans des attaques réelles.

La différence cruciale

Indicateur	Ce qu’il mesure
CVSS	Sévérité technique (théorique)
EPSS	Probabilité d’exploitation (prédiction)
KEV	Exploitation réelle (confirmée)

Analogie :

• CVSS = “Ce revolver est dangereux” (description de l’arme).
• EPSS = “Il y a 85% de chances que quelqu’un tire avec” (prédiction).
• KEV = “Quelqu’un est déjà en train de vous tirer dessus” (fait avéré).

Pourquoi c’est important

Si une CVE est dans KEV, ça signifie :

1. Des preuves concrètes : Des rapports d’incidents, des analyses forensiques, des captures de malwares.
2. Une menace active : Ce n’est pas un PoC théorique, c’est une attaque en cours.
3. Un délai imposé : La CISA donne un “Due Date” pour patcher (généralement 2-3 semaines).

Règle d’or : Une CVE dans KEV = priorité P0, quel que soit son score CVSS.

👉 Lien direct : CISA KEV Catalog

Comment une CVE entre dans KEV ?

KEV n’est pas automatisé comme le NVD. C’est un travail curatorial fait par des analystes humains de la CISA (et c’est l’un des problemes de cette base américaine…).

Les critères stricts

Pour qu’une CVE soit ajoutée à KEV, elle doit remplir trois conditions :

1. Preuve d’exploitation réelle

Il faut des rapports fiables :

• Incidents confirmés par des entreprises ou des gouvernements.
• Analyses forensiques (logs, memory dumps, captures réseau).
• Malwares décompilés contenant l’exploit.
• Rapports de CTI (Cyber Threat Intelligence) de sources crédibles.

Ce qui ne suffit PAS :

• Un PoC publié sur GitHub.
• Une alerte “possible exploitation” non confirmée.
• Des rumeurs sur les forums.

2. Impact potentiel

La vulnérabilité doit pouvoir affecter :

• Des infrastructures critiques (énergie, santé, finance, transport).
• Des organisations (entreprises, administrations, universités).

Ce qui est exclu :

• Les CVE ultra-nichées (logiciels utilisés par 3 personnes dans le monde).
• Les vulnérabilités théoriques sans vecteur d’attaque réaliste.

3. Existence d’une solution

Il doit y avoir une action possible :

• Un patch officiel du vendor.
• Un workaround documenté.
• Une mitigation (désactivation d’une fonctionnalité, firewall, WAF…).

Si aucune solution n’existe, la CVE n’entre pas dans KEV (mais elle sera surveillée de près).

Le processus de validation

1. Détection : La CISA reçoit des signalements (CTI, CERT, entreprises, chercheurs).
2. Vérification : Les analystes vérifient les preuves.
3. Ajout : Si les 3 critères sont remplis, la CVE est ajoutée à KEV avec un “Due Date”.
4. Notification : Les agences fédérales US sont notifiées (obligation légale de patcher avant le Due Date).

À quelle fréquence c’est mis à jour ?

En continu.

La CISA ajoute des CVE dès qu’elle a confirmation d’exploitation. Parfois, c’est :

• 1 CVE par semaine (période calme).
• 5-10 CVE par jour (pendant une grosse campagne de ransomware ou une vague d’APT).

Les pics d’ajouts coïncident souvent avec :

• Des campagnes de ransomware massives (LockBit, BlackCat, ALPHV…).
• Des exploits zero-day révélés publiquement (genre Log4Shell).
• Des vagues d’APT étatiques (groupes chinois, russes, nord-coréens).

Les champs KEV (ce que contient chaque entrée)

Chaque CVE dans KEV a plusieurs métadonnées essentielles :

1. CVE ID

L’identifiant unique de la vulnérabilité.

Exemple : CVE-2024-1234

2. Vendor / Product

Le logiciel ou matériel concerné.

Exemples :

• Microsoft Windows Server
• Apache HTTP Server
• Fortinet FortiOS
• Cisco IOS XE

3. Description

Un résumé de ce que fait la vulnérabilité.

Exemple :

“Remote code execution vulnerability in Microsoft Exchange Server allows an unauthenticated attacker to execute arbitrary code via crafted HTTP requests.”

4. Date Added

La date à laquelle la CVE a été ajoutée au catalogue.

Utilité : Permet de savoir depuis combien de temps la CVE est exploitée.

Exemple : 2024-03-15

5. Due Date ⚠️

C’est le champ le plus important.

La CISA impose un délai pour patcher les systèmes :

• Agences fédérales US : Obligation légale (Binding Operational Directive 22-01).
• Entreprises privées : Fortement recommandé (surtout secteurs critiques).

Délais typiques :

• 2 semaines : Pour les CVE “standard”.
• 3 semaines : Si le patch est complexe.
• Immédiat : Pour les zero-days en exploitation massive.

Exemple : Si Date Added = 2024-03-15 et Due Date = 2024-03-29, vous avez 14 jours pour patcher.

6. Required Action

L’action à prendre.

Exemples :

• Apply updates per vendor instructions.
• Apply mitigations per vendor instructions or discontinue use.
• The impacted product is end-of-life and should be disconnected if still in use.

7. Known Ransomware Use

Nouveau champ ajouté en 2023.

Indique si la CVE est connue pour être utilisée par des ransomwares.

Valeurs :

• Known : Oui, détectée dans des ransomwares.
• Unknown : Pas (encore) de preuve.

Utilité : Si vous êtes dans un secteur ciblé par les ransomwares (santé, éducation, collectivités), c’est un signal d’alarme supplémentaire.

8. Notes (optionnel)

Informations complémentaires, liens vers des advisories, précisions sur l’exploitation.

L’historique KEV

Le lancement (novembre 2021)

Le catalogue a été créé en novembre 2021, suite à la directive BOD 22-01 de la CISA.

Objectif : Obliger les agences fédérales à patcher rapidement les CVE réellement exploitées (au lieu de courir après toutes les “Critical” CVSS).

À son lancement, KEV contenait environ 300 CVE (un backlog de vulnérabilités exploitées les années précédentes).

L’explosion (2022-2026)

Aujourd’hui (début 2026), KEV contient environ 1 500 CVE.

Pourquoi cette explosion ?

1. Meilleure détection : Les outils de CTI (honeypots, SIEM, EDR) sont plus sophistiqués.
2. Transparence accrue : Les entreprises et les chercheurs partagent plus d’infos (via des ISAC, des CERT, des bug bounties).
3. Ransomware-as-a-Service (RaaS) : Les gangs de ransomwares recyclent constamment de vieilles CVE pour atteindre des organisations mal patchées.

Les vagues notables

Quelques pics d’ajouts dans KEV :

• Décembre 2021 : Log4Shell (CVE-2021-44228) et ses variantes.
• Février 2022 : Vulnérabilités Fortinet exploitées par des APT chinois.
• Mars 2023 : Failles 0-day dans Cisco IOS XE (exploitation massive).
• Septembre 2024 : Vulnérabilités VMware ESXi ciblées par ransomwares.

Un exemple concret : CVE-2026-0544

Reprenons notre chère CVE-2026-0544 (l’injection SQL du Nouvel An).

Imaginons qu’elle soit exploitée massivement par un ransomware en février 2026.

Le scénario

1. Semaine 1 : La CVE est publiée. CVSS 9.8, EPSS 0.15 (faible).
2. Semaine 2 : Un chercheur publie un PoC sur GitHub. EPSS monte à 0.65.
3. Semaine 3 : Le ransomware “DarkVortex” utilise l’exploit pour compromettre 50 organisations.
4. Semaine 4 : La CISA ajoute la CVE à KEV.

Les données KEV

Champ	Valeur
CVE ID	CVE-2026-0544
Vendor	News0ft Analytics
Product	Analytics Module v2.3
Date Added	2026-02-01
Due Date	2026-02-15 (14 jours)
Required Action	Apply updates per vendor instructions
Ransomware Use	Known
EPSS	0.95 (après ajout KEV)

Votre réaction

Si vous utilisez ce produit :

1. Jour 1 (ajout KEV) : ALERTE ROUGE. Priorisation immédiate.
2. Jour 2-3 : Identification des systèmes vulnérables (inventaire d’assets).
3. Jour 4-7 : Tests du patch en pré-prod.
4. Jour 8-14 : Déploiement en prod avant le Due Date.

Si vous ratez le Due Date :

• Vous n’êtes pas conforme (si vous êtes une agence US).
• Vous augmentez drastiquement votre risque de compromission.
• Votre assurance cyber pourrait refuser de couvrir un incident lié à cette CVE (négligence).

Les pièges à éviter

1. Croire que KEV est exhaustif

Erreur : “Ce n’est pas dans KEV, donc ce n’est pas exploité.”

Réalité : KEV ne contient que les CVE publiquement connues comme exploitées et entrées par la CISA (organisme étatique américain).

Ce qui manque :

• Les zero-days non divulgués.
• Les exploits très ciblés (APT sur des cibles spécifiques).
• Les exploitations “silencieuses” (espionnage, pas de ransomware bruyant).

Solution : Utilisez aussi vos propres sources de CTI (threat intelligence privée, ISAC de votre secteur, partenaires).

2. Ignorer les “vieilles” CVE

Erreur : “Cette CVE de 2019 ? Personne ne l’utilise plus.”

Réalité : Les ransomwares recyclent constamment de vieilles CVE parce que des milliers d’organisations ne patchen jamais.

Exemple : CVE-2017-0144 (EternalBlue / WannaCry) est toujours dans KEV en 2026 parce qu’elle est toujours exploitée.

3. Sous-estimer le “Known Ransomware Use”

Erreur : “On n’est pas ciblés par les ransomwares, on est trop petits.”

Réalité : Les ransomwares modernes sont automatisés. Ils scannent Internet et exploitent tout ce qui est vulnérable, sans distinction de taille.

Si KEV dit “Known Ransomware Use”, c’est que vous êtes dans le radar de dizaines de gangs.

4. Patcher sans tester

Erreur : “C’est dans KEV, on patche direct en prod !”

Réalité : Un patch qui casse la prod, c’est pire qu’une CVE.

Solution :

1. Isolez le système vulnérable (firewall, segmentation).
2. Testez le patch en pré-prod.
3. Déployez si OK, sinon appliquez des mitigations temporaires.

Comment surveiller KEV

1. Flux JSON

La CISA publie KEV au format JSON machine-readable :

👉 https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json

2. Script d’automatisation

import requests
import pandas as pd

# Récupérer le KEV
kev_url = "https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json"
kev_data = requests.get(kev_url).json()

# Convertir en DataFrame
kev_df = pd.DataFrame(kev_data['vulnerabilities'])

# Filtrer les CVE ajoutées cette semaine
import datetime
today = datetime.date.today()
week_ago = today - datetime.timedelta(days=7)

kev_df['dateAdded'] = pd.to_datetime(kev_df['dateAdded'])
recent_cve = kev_df[kev_df['dateAdded'] >= str(week_ago)]

print(f"CVE ajoutées cette semaine : {len(recent_cve)}")
print(recent_cve[['cveID', 'vendorProject', 'product', 'dateAdded']])

Ressources :

• CISA KEV Catalog
• KEV JSON Feed
• BOD 22-01 Directive
• CVE
• CVSS
• EPSS