398 correctifs, une seule faille exploitée : comment on choisit

Le 11 août, Microsoft a publié des correctifs pour 398 vulnérabilités, dont 42 classées critiques. Une seule est activement exploitée : CVE-2026-68820, une élévation de privilèges dans afd.sys, le pilote qui porte les connexions socket sur pratiquement tous les postes Windows.

Son score CVSS est de 7,0. C’est-à-dire en dessous du seuil de la catégorie « critique », qui commence à 9,0. Les quarante-deux vulnérabilités classées critiques, elles, ne sont pas exploitées.

Cette configuration n’a rien d’exceptionnel. Elle se répète tous les mois, et elle dit la même chose à chaque fois : le score de gravité ne répond pas à la question qu’on lui pose.

Ce que mesure le CVSS, et ce qu’il ne mesure pas

Le score CVSS décrit la gravité technique intrinsèque d’une vulnérabilité : ce qu’un attaquant obtiendrait s’il l’exploitait, et à quelles conditions. C’est une mesure de conséquence potentielle.

Il ne mesure pas la probabilité que quelqu’un l’exploite chez vous. Il ne dit rien de l’existence d’un code d’attaque public, du fait que des groupes s’en servent déjà, ni du nombre de vos machines réellement atteignables.

CVE-2026-68820 en est une bonne illustration. Son score de 7,0 reflète une complexité d’exploitation élevée : il s’agit d’une situation de compétition qu’il faut rejouer jusqu’à ce que le timing tombe juste. Techniquement, c’est difficile. Concrètement, des acteurs le font, et la société eSentire avait relevé des tentatives dès le 29 juin. La difficulté n’a pas empêché l’exploitation ; elle a seulement fait baisser le score.

Les trois signaux à croiser

Un score seul ne permet pas de décider d’un ordre de passage. Trois éléments, croisés, le permettent.

L’exploitation constatée. Le catalogue KEV de la CISA recense les vulnérabilités dont l’exploitation est avérée. C’est le signal le plus fort et le plus simple à consommer. Une vulnérabilité qui y figure change de catégorie, quel que soit son CVSS.

La probabilité d’exploitation. L’EPSS, publié par le FIRST, estime la probabilité qu’une vulnérabilité soit exploitée dans les trente jours. C’est utile pour trancher entre deux failles également graves et également non exploitées à ce jour.

Votre exposition réelle. C’est le signal que personne ne peut vous fournir. Combien d’instances, exposées comment, avec quelles conditions préalables à l’exploitation. Une élévation de privilèges suppose un accès initial : elle n’est pas une porte d’entrée, c’est une étape deux, après un premier pied obtenu par hameçonnage. Ce qui la rend prioritaire sur les postes de travail, et beaucoup moins sur un serveur applicatif isolé.

Une politique de correction qui tient en cinq lignes

La plupart des politiques de patch que nous lisons en audit reposent sur une seule variable — la criticité éditeur — et fixent un délai unique, en général trente jours, que personne ne tient. Une politique différenciée est plus courte, plus tenable, et défendable devant un auditeur.

Le tableau n’a de valeur que si l’inventaire permet de savoir dans quelle ligne on se trouve. C’est là que le travail se situe réellement, et c’est aussi ce qui explique pourquoi tant d’organisations en restent au délai unique : il ne demande pas de connaître son parc.

Le correctif n’est pas toujours la fin de la remédiation

Deuxième enseignement de l’été, sur un autre produit. Lorsqu’une vulnérabilité permet d’accéder à des secrets stockés sur un serveur — jetons d’intégration, identifiants de service, clés d’API —, appliquer le correctif ne referme rien pour un attaquant déjà passé. Il conserve ce qu’il a pris.

Dans ce cas, la rotation des identifiants fait partie de la remédiation au même titre que la mise à jour. Les serveurs d’intégration continue sont l’exemple type : ils concentrent des secrets d’accès à l’ensemble de la chaîne de production, et ils sont rarement dans le périmètre du patch management classique.

La question à poser après chaque correction n’est donc pas « est-ce à jour », mais « qu’est-ce qui aurait pu être emporté avant ».

Le délai de correction est un élément de conformité

Ce point est régulièrement sous-estimé. L’article 32 du RGPD impose des mesures adaptées au risque, et le délai de correction d’une vulnérabilité activement exploitée en fait partie. Ce n’est pas une exigence formelle : c’est ce qu’une autorité regardera après un incident, en comparant la date de disponibilité du correctif à celle de son application.

Les échéances publiées ailleurs servent de repère implicite. Les agences fédérales civiles américaines devaient appliquer les correctifs d’août au 10 août au titre de la directive BOD 26-04. Cette date n’a aucune portée juridique en Europe. Elle constitue néanmoins un point de comparaison que personne n’a intérêt à ignorer lorsqu’il faut justifier, après coup, d’un délai de six semaines.

Sources

• Microsoft Security Update Guide, publication du 11 août 2026
• CISA — Known Exploited Vulnerabilities Catalog ; directive opérationnelle BOD 26-04
• FIRST — Exploit Prediction Scoring System (EPSS) ; Common Vulnerability Scoring System v4.0
• Règlement (UE) 2016/679 (RGPD), article 32