28 vulnérabilités exploitées en treize jours : signal KEV

Entre le 8 et le 24 septembre 2026, la CISA a ajouté 28 vulnérabilités à son catalogue des vulnérabilités exploitées (KEV), selon notre décompte du fichier JSON du catalogue, version du jour (2026.09.24). Treize jours ouvrables, 28 CVE, presque toutes sur des équipements de bordure du réseau ou de l'identité. Pour ces actifs, un cycle mensuel de correctifs ne tient plus.

Ce que disent les sources

Le catalogue KEV. Le fichier JSON de la CISA donne, pour chaque entrée, la date d'ajout et la date limite. Du 8 au 24 septembre 2026, la séquence se lit comme un inventaire de bordure :

Windows, Chromium V8, N-able, JFrog, GitLab, Cisco Secure Email Gateway et Google Pixel complètent les 28. Sur le champ de date limite, 23 entrées donnent trois jours après l'ajout, les cinq autres (deux Windows, Chromium V8, deux JFrog) quatorze jours. La page du catalogue renvoie chaque consigne à la directive BOD 26-04 et rend chaque organisation responsable d'évaluer l'exposition Internet de ses actifs. L'alerte de la CISA du 22 septembre 2026, qui ajoute F5, Check Point et Arista, rappelle que BOD 26-04 impose aux agences fédérales de corriger en priorité les CVE du catalogue.

Le Centre canadien pour la cybersécurité a publié quatre alertes dans la fenêtre : AL26-020 sur MikroTik RouterOS (10 septembre), AL26-021 sur Cisco ISE (17 septembre), AL26-022 sur F5 BIG-IP APM (22 septembre) et AL26-023 sur Microsoft SharePoint Server, CVE-2026-65660 (24 septembre). Cette dernière confirme une exploitation active et rappelle que SharePoint Server 2016 et 2019 sont en fin de vie depuis le 15 juillet 2026. Côté européen, l'avis CERT-EU 2026-013 du 22 septembre classe la faille F5 en critique (CVSS 9,8), exploitation confirmée par le fournisseur.

L'ENISA a publié le 22 septembre 2026 son Threat Landscape, qui couvre l'année 2025. Deux chiffres : parmi les accès non autorisés dont le vecteur d'intrusion a pu être identifié (5 % des cas), 60 % passaient par l'exploitation d'une vulnérabilité ; et 2025 a vu la publication de plus de 48 000 CVE, en hausse de 22 % sur l'année précédente.

Pourquoi ça compte

Trois constats.

D'abord, la cible. NetScaler, Fortinet, ISE, BIG-IP APM, Check Point, ScreenConnect : des passerelles VPN, des serveurs de politiques d'accès, des consoles d'administration. Elles voient passer les identifiants, sont exposées par conception et n'accueillent pas d'agent de détection. Une compromission là ne déclenche aucune alerte : elle donne un accès qui ressemble à un accès légitime.

Ensuite, le rythme. Vingt-huit entrées en treize jours ouvrables, plus de deux par jour, avec une échéance de trois jours pour la majorité. Une organisation qui corrige par lot mensuel arrive structurellement après la date limite que la CISA fixe à ses agences et, plus grave, après les attaquants, puisque l'inscription au catalogue atteste que l'exploitation a commencé.

Enfin, le tri. Le CVSS mesure ce qu'un attaquant obtient s'il réussit, pas s'il essaie ; le catalogue KEV répond à la seconde question. Avec plus de 48 000 CVE publiées en 2025 selon l'ENISA, personne ne corrige tout : l'exploitation avérée est le premier critère de tri, l'exposition de l'actif le second.

Pour l'auditeur, cela se traduit en preuves attendues : ISO 27001:2022, mesure A.8.8, veut des vulnérabilités techniques connues et traitées à temps ; NIS 2, article 21(2)(e), exige des politiques de traitement et de divulgation des vulnérabilités ; le contrôle 7 de CIS v8 vise la gestion continue des vulnérabilités. Aucun ne fixe « trois jours », mais tous demandent un délai défini, justifié et démontré.

Ce que nous en pensons chez Sentrix

Ce mois de septembre est l'argument le plus concret que nous ayons vu pour passer à la gestion continue de l'exposition. Dans l'ordre :

1. Tenez l'inventaire des actifs exposés à part. Passerelles, VPN, consoles d'administration, serveurs de fédération, portails, avec version et propriétaire. Quand une entrée KEV tombe, « sommes-nous concernés ? » doit trouver réponse en minutes.
2. Prenez le catalogue KEV comme déclencheur, pas comme lecture hebdomadaire. Le flux JSON est public et daté ; comparez-le chaque jour à l'inventaire. Le CVSS ordonne ensuite ce qui reste.
3. Adoptez l'étalon de trois jours pour un actif exposé inscrit au catalogue, et mesurez l'écart. Un délai raté et documenté vaut mieux qu'aucun délai.
4. Traitez la fin de vie comme une vulnérabilité permanente. Un SharePoint 2016 ou 2019 exposé après le 15 juillet 2026 n'a plus de correctif à venir : date de sortie au registre des risques, isolation en attendant.
5. Collectez la preuve une seule fois. Date d'inscription au catalogue, date de détection dans l'inventaire, date de correction et exception signée forment un seul enregistrement, présenté ensuite en A.8.8, en article 21(2)(e) ou en contrôle 7 sans le reconstruire.

C'est le rôle de notre module CTEM d'exposition continue ; notre page sur la gestion des vulnérabilités et des correctifs décrit l'approche. Nos articles sur la priorisation avec le catalogue KEV et l'EPSS et sur les cinq étapes du CTEM détaillent la méthode.

La prochaine étape

Prenez les 28 CVE de septembre et, pour chacune, écrivez une ligne : concernés ou non, date de correction, écart par rapport à trois jours. Si une ligne reste vide faute d'inventaire, commencez par là. Notre veille suit les prochaines entrées ; pour faire l'exercice avec nous, contactez-nous.