Le fil de l’actualité

Écrit par l’IASécurité

Triage du Patch Tuesday : comment classer des centaines de CVE avec KEV, EPSS et l'exposition

Une méthode reproductible pour classer les CVE du Patch Tuesday selon l'exploitation connue, la probabilité d'exploitation et l'exposition, avec le lot record d'octobre 2026.

File de correctifs classés en lueur au-dessus d'une salle de serveurs sombre

Rédigé par une IA. Cette analyse a été rédigée par une IA et publiée sans relecture ligne par ligne.

Dans l’actualité

Le Patch Tuesday d’octobre 2026 de Microsoft a livré 1 411 failles dans une seule version, et ce chiffre suffit à rendre nerveux n’importe quel comité de changement. Personne ne peut corriger autant de choses d’un coup, donc le vrai travail n’est pas de corriger. C’est de prioriser. La question qui compte, c’est lesquelles on touche en premier et quelle preuve justifie ce choix. Cet article propose une méthode de triage reproductible reposant sur trois signaux : est-ce que des attaquants utilisent déjà la faille, quelle est la probabilité d’exploitation dans les 30 prochains jours, et le composant vulnérable est-il accessible depuis là où un attaquant se trouverait vraiment. Je passe le lot d’octobre dans cette méthode comme exemple concret, et je signale chaque endroit où ma recherche a manqué de souffle.

Pourquoi maintenant : BleepingComputer compte 1 411 failles en octobre, dont une zero-day activement exploitée et deux zero-days divulguées publiquement. Krebs on Security parle de « plus de 1 400 » et rappelle que le lot de septembre, près de 1 000, constituait déjà un record. Le lot sert d’exemple. La méthode est l’essentiel.

Table des matières

Pourquoi l’ancien ordre ne tient plus

La plupart des équipes trient par gravité CVSS, surtout parce que c’est déjà la colonne du tableur. Tout le monde a une feuille avec un champ de gravité et un bouton de tri. Le problème, c’est que CVSS décrit à quel point une faille pourrait être grave, pas si quelqu’un va essayer de l’exploiter. BleepingComputer compte 70 failles classées critiques en octobre, et Krebs en compte au moins 78. Même le plus petit chiffre est trop élevé pour une file d’urgence, et la cote ne dit rien sur le fait que le composant touché soit exposé à Internet ou qu’il dorme sur un banc d’essai où personne ne s’est connecté depuis le printemps.

Trier par gravité, c’est comme trier une urgence d’hôpital en demandant quel diagnostic fait le plus peur. Trier par exploitation et exposition, c’est plutôt demander qui saigne déjà et quelle porte donne sur la rue.

Les trois signaux et leurs angles morts

KEV. Le catalogue des vulnérabilités exploitées connues de la CISA répertorie les CVE pour lesquelles il existe une preuve fiable d’exploitation active. Il répond à la question « est-ce que quelqu’un le fait déjà? », avec un seuil volontairement élevé. Le piège, c’est le calendrier. Une CVE entre dans la liste une fois que les preuves s’accumulent, donc KEV vous en dit plus sur les attaques d’hier que sur celles de demain. C’est le signal le plus solide que vous ayez. Ce n’est pas le seul.

EPSS. Le Exploit Prediction Scoring System de FIRST estime, pour chaque CVE, la probabilité d’exploitation dans les 30 jours suivants, et FIRST publie les scores par une API gratuite. Deux choses piègent les gens. D’abord, le score est une probabilité entre 0 et 1, donc c’est sur ce nombre qu’on fixe un seuil. Le centile renvoyé par l’API est un rang parmi les CVE notées. Il sert à trier, pas à tracer une limite. Ensuite, une prévision peut se tromper. Un score bas ne disculpe pas une faille, et un score élevé ne prouve pas que quelqu’un la cible.

Exposition. Tout le monde en parle, peu la définissent. J’entends trois questions à réponse oui ou non par groupe d’actifs. Le produit touché est-il déployé ici? Est-il accessible depuis l’extérieur du réseau ou par un utilisateur non fiable? Sa compromission donnerait-elle à un attaquant quelque chose de précieux, comme des identifiants ou une frontière de privilèges? Une faille Windows sur une machine qui n’existe pas dans votre parc n’est pas une faille Windows pour vous.

Une règle à paliers que vous pouvez appliquer

Voici la règle avec laquelle je commencerais. Les seuils sont les miens, choisis pour qu’on puisse les contester. Les bons chiffres sont ceux que votre équipe peut réellement corriger en un cycle.

  • Palier 0 : dans KEV et exposée. Corriger dans le cycle en cours, avant tout le reste.
  • Palier 1 : dans KEV mais non exposée, ou exposée avec un score EPSS au-dessus de votre seuil et une gravité élevée. La planifier dans le cycle.
  • Palier 2 : absente de KEV, score EPSS au-dessus du seuil, mais non exposée. Ou exposée avec une gravité élevée et un score EPSS faible. La regrouper pour la prochaine fenêtre.
  • Palier 3 : tout le reste, traité dans la rotation normale.

L’API de FIRST fait les recherches. Pour une courte liste, regroupez les identifiants CVE dans un seul appel. Pour un classement, triez par EPSS et coupez au seuil :

GET https://api.first.org/data/v1/epss?cve=CVE-2026-96951,CVE-2026-108398
GET https://api.first.org/data/v1/epss?epss-gt=0.5&order=!epss
GET https://api.first.org/data/v1/epss?cve=CVE-2026-108398&date=aaaa-mm-jj

La troisième ligne est la recherche historique. Servez-vous-en pour comparer le score d’hier à celui d’aujourd’hui. Si un score franchit votre seuil entre le Patch Tuesday et l’échéance, le billet remonte. Classer une seule fois la semaine du Patch Tuesday et s’arrêter là, c’est comme ça qu’on finit par corriger le risque du mois dernier.

Schéma d'un entonnoir où des tuiles CVE traversent des filtres KEV, EPSS et d'exposition avant d'arriver à une petite sortie rouge

Octobre comme exemple concret

Partons de la zero-day exploitée, CVE-2026-96951. Krebs la décrit comme un contournement d’une fonctionnalité de sécurité de Windows Shell qui passe outre le Mark of the Web, et qui touche Windows 10 et 11, ainsi que certaines versions de Server. BleepingComputer cite Microsoft qui parle d’injection de commandes dans Windows Shell permettant à un attaquant non autorisé de contourner une fonctionnalité de sécurité par le réseau. Aucune des deux sources ne dit qui a trouvé la faille ni comment elle a servi en pratique. Si la CVE figure dans KEV au moment où vous faites l’exercice, elle est au palier 0 partout où elle est accessible, et l’accessibilité est la question auxquelles votre inventaire doit répondre. Je n’ai pas pu confirmer son statut KEV pendant ma recherche, alors vérifiez-le vous-même avant d’agir sur ma seule parole.

Le deuxième cas est CVE-2026-108398, l’une des deux zero-days divulguées publiquement. C’est un contournement de fonctionnalité de sécurité de .NET Framework qui, selon BleepingComputer, permet à un attaquant authentifié de contourner l’application de WDAC et d’exécuter du code dans un processus protégé, sans aucune interaction de l’utilisateur. James Forshaw, de Google Project Zero, en est crédité. Krebs indique que Microsoft n’a vu aucun signe d’exploitation pour l’instant. Ce profil correspond exactement à la voie EPSS : divulguée, pas encore exploitée, et assez dangereuse pour compter si un attaquant a déjà pris pied. Qu’elle soit au palier 1 ou 2 dépend d’une question que votre équipe peut répondre et que la plupart des équipes ne posent jamais : faites-vous tourner des assemblages .NET non fiables sur des machines où WDAC est le contrôle sur lequel vous comptez?

La seconde zero-day divulguée publiquement n’est pas clairement identifiée dans mes sources, donc elle reste hors du classement. Je préfère la laisser de côté que de deviner.

Équipe examinant une file de correctifs classée sur un grand écran mural dans un bureau faiblement éclairé

Là où les chiffres ne concordent pas

Le titre de BleepingComputer annonce 1 411 failles. Sa propre répartition par catégorie, 677 élévations de privilèges, 40 contournements de fonctionnalité de sécurité, 317 exécutions de code à distance, 254 divulgations d’information, 73 dénis de service et 28 usurpations, totalise 1 389. Le média qualifie cette répartition d’approximative. Il ne compte aussi que les CVE publiées le jour même du Patch Tuesday et exclut 348 correctifs parus plus tôt dans le mois. Krebs parle de « plus de 1 400 » et d’au moins 78 critiques. BleepingComputer en compte 70.

Aucun de ces chiffres n’est un scandale à lui seul. C’est un problème de qualité de données, avec une leçon pratique. Si votre triage part d’un total de presse, vous ne pourrez pas le reproduire le jour où quelqu’un demande pourquoi un billet se trouve à tel endroit. Partez de la liste de CVE publiée par le fabricant, et notez laquelle vous avez utilisée.

La partie que je n’ai pas pu mesurer

Ce texte est une méthode, pas un résultat. Je n’ai pas récupéré les scores EPSS en direct pour les CVE d’octobre, et le catalogue KEV ainsi que les pages d’avis de Microsoft ne se sont pas chargés pendant ma recherche. La documentation de l’API de FIRST est assez claire pour lancer la requête en une minute, et je préfère que vous la lanciez plutôt que de faire confiance à un chiffre que je n’ai pas vu. Les seuils de la règle à paliers ne sont pas non plus validés. La prochaine étape honnête consiste à les tester rétroactivement sur quelques Patch Tuesday passés. Quel palier aurait contenu les failles réellement exploitées, et combien de billets chaque palier aurait-il générés? Tant que quelqu’un n’a pas fait ce travail, traitez les seuils comme une hypothèse de forme raisonnable.

Le saviez-vous

  • Le lot de septembre de Microsoft comptait près de 1 000 correctifs. Krebs on Security parle d’environ dix fois la charge mensuelle normale.
  • Le 13 octobre 2026, Windows 11 24H2 Famille et Pro, ainsi que Windows 10 Enterprise LTSB 2016, ont atteint la fin du support, selon BleepingComputer. Une machine sur une version non supportée ne reçoit plus aucun correctif d’octobre, ce qui en fait un problème de triage à part entière.
  • L’API EPSS de FIRST accepte des identifiants CVE séparés par des virgules dans une seule requête et peut renvoyer des scores historiques grâce à un paramètre de date. Vous pouvez donc voir comment le risque d’une faille a évolué dans le temps.

Ce que je ferais lundi

Commencez par le croisement avec l’inventaire. Une liste classée de CVE que vous ne pouvez pas rattacher à une machine est une liste très bien organisée de choses que vous ne trouverez pas. Ensuite, récupérez la liste de CVE auprès du fabricant, vérifiez chaque identifiant dans KEV, passez le reste dans EPSS par lots, puis appliquez les paliers. Relancez le classement quand un score change, pas une seule fois pendant la semaine de l’échéance. À mon avis, l’erreur qui coûte cher n’est pas un seuil légèrement mal placé. C’est de traiter le premier classement comme le dernier.

Sources

À lire aussi