Le Patch Tuesday d'août de Microsoft a corrigé environ 400 failles, et un vrai incendie

Microsoft a publié le 11 août l'une des plus importantes mises à jour de sécurité de son histoire, corrigeant environ 400 vulnérabilités dans Windows, Office, Azure, Exchange, SharePoint et une longue liste d'autres produits. Le Patch Tuesday d'août 2026 comprend trois failles zero-day (dont une déjà exploitée activement) et au moins une chaîne d'exécution de code à distance non authentifiée entièrement documentée.

À lire aussi: Le Patch Tuesday d'octobre 2026 de Microsoft établit un record avec 1 407 correctifs · Le Patch Tuesday record de Microsoft : 974 failles, deux déjà exploitées.

Le chiffre est si important qu'il est devenu une histoire en soi. C'est la deuxième plus grosse publication mensuelle jamais produite par Microsoft, et le consensus du secteur est que ce volume n'est pas un pic mais la nouvelle norme.

Une publication record, et un problème de comptage

La première chose à savoir sur un Patch Tuesday à 400 CVE, c'est que personne ne s'accorde sur le chiffre exact.

BleepingComputer compte 400 vulnérabilités publiées le jour même, dont 42 classées critiques, 37 d'entre elles étant des exécutions de code à distance. Tenable en compte 398, après avoir exclu deux CVE attribués par MITRE. Cisco Talos en compte 421, dont 62 critiques. Le Zero Day Initiative voit aussi 398 CVE mais compte 62 critiques plutôt que 42, une différence qui tient à la façon dont les mêmes avis sont classés.

L'écart n'est pas un scandale; c'est un symptôme. Les avis de Microsoft couvrent des produits locaux et des services cloud, certains correctifs sortent hors du cycle mensuel, et les évaluations de gravité relèvent autant du jugement que de la mesure. La leçon pratique pour les défenseurs est que le chiffre en une du sujet est un indicateur approximatif, pas un inventaire. Ce qui compte, ce sont les failles précises qui touchent votre environnement.

Celle qui compte : CVE-2026-68820

Parmi des centaines de découvertes, une ressort. CVE-2026-68820 est une faille d'élévation de privilèges dans le Windows Ancillary Function Driver for WinSock (afd.sys), un composant du noyau présent sur pratiquement tous les systèmes Windows. C'est un bug d'utilisation après libération (use-after-free) qui permet à un attaquant authentifié local d'atteindre les privilèges SYSTEM sans interaction de l'utilisateur.

Sa note de gravité est modeste (CVSS 7,0, classée seulement « Important ») mais elle était exploitée activement comme zero-day. Des chercheurs de Check Point ont rapporté que des acteurs nord-coréens, suivis sous le nom de Lazarus, l'ont utilisée pour déployer une nouvelle version de FudModule, leur rootkit en mode noyau, dans une nouvelle vague de la longue campagne Operation Dream Job.

Le schéma est désormais assez familier pour être une règle : la faille exploitée activement est rarement celle la mieux notée. Dans cinq des six dernières publications du Patch Tuesday, la vulnérabilité exploitée n'avait pas la note de gravité la plus élevée. Les programmes qui trient uniquement selon le score CVSS continueront de déployer les correctifs dans le mauvais ordre.

Les zero-days divulguées publiquement

Deux autres failles étaient publiques avant que les correctifs n'existent.

CVE-2026-62832 est une faille d'élévation de privilèges dans le Windows User Profile Service; Microsoft a jugé probable une exploitation à venir. CVE-2026-72971 est une vulnérabilité de falsification dans le Windows Container Isolation FS Filter Driver (unionfs.sys). Help Net Security a aussi noté que CrowdStrike a signalé CVE-2026-62737, une faille d'élévation de privilèges du noyau Windows, comme divulguée publiquement avant la sortie du correctif.

La divulgation publique avant un correctif est dangereuse parce qu'elle lance l'horloge du code d'exploitation fonctionnel avant que les défenseurs puissent agir. Une fois une faille publique, attaquants et chercheurs rivalisent pour l'armer, et la fenêtre entre la disponibilité du correctif et la première exploitation peut se compter en heures. Ces failles relèvent du premier anneau de déploiement, que des attaques aient été observées ou non.

La chaîne SharePoint et l'histoire de la découverte assistée par IA

Le correctif techniquement le plus important n'est pas un zero-day. CVE-2026-63520 est une faille d'instanciation de type .NET non sécurisée dans les Business Connectivity Services de SharePoint, notée CVSS 8,1 et divulguée conjointement par Microsoft et Rapid7. Le chercheur Stephen Fewer a construit la chaîne d'exploitation pour Pwn2Own Berlin.

Enchaînée au contournement d'authentification JWT de juillet (CVE-2026-55040), elle permet une exécution de code à distance complète contre SharePoint Server 2016, 2019 et Subscription Edition locaux, sans aucun identifiant. C'est aussi grave qu'une vulnérabilité exposée au web peut l'être, et cela achève une séquence en deux parties que les défenseurs suivaient depuis le mois précédent.

Il faut noter que les articles sur la divulgation décrivent la recherche sous-jacente comme assistée par IA, un détail qui correspond à la tendance générale. Les chercheurs en sécurité utilisent de plus en plus des outils d'IA pour trouver des bugs, ce qui aide à expliquer pourquoi le volume de découvertes a explosé alors que les zero-days exploités activement, non. La course aux armements des outils se joue désormais des deux côtés de la table de la divulgation.

La pénurie de capacité de correction

Derrière les chiffres se cache une réalité opérationnelle simple : la plupart des organisations ne peuvent pas installer 400 mises à jour en un mois, et encore moins les tester.

Chaque correctif comporte un risque de casser quelque chose, un pilote, une application métier, une intégration personnalisée. C'est pourquoi les entreprises déploient les mises à jour par anneaux, les valident dans un environnement de test et les déploient progressivement. Avec quelques dizaines de failles par mois, ce processus est gérable. Avec 400, il devient une file d'attente, et les files d'attente finissent par devenir des arriérés qui ne se résorbent jamais.

Il en résulte que les équipes de sécurité sont contraintes d'abandonner l'idée d'un correctif exhaustif et d'adopter quelque chose de proche du triage fondé sur le risque. Au lieu de demander « avons-nous tout installé ? », elles demandent « avons-nous installé ce qui peut réellement nous nuire ce mois-ci ? ». C'est la bonne question, mais y répondre exige des données d'inventaire, une analyse d'exposition et du renseignement sur les exploitations, des capacités qui manquent encore à beaucoup d'organisations.

L'automatisation absorbe une partie de la charge : les plateformes de gestion des correctifs, les scanners de configuration et les outils de poste de travail peuvent gérer le déploiement mécanique. Ce que l'automatisation ne peut pas faire, c'est le jugement. Décider qu'une faille CVSS 7,0 dans un pilote du noyau compte plus qu'une faille CVSS 9,8 dans un service que vous n'exécutez pas est une décision contextuelle, et c'est la compétence rare de la gestion moderne des vulnérabilités. Avec un incendie confirmé pour quatre cents découvertes, un programme qui ne sait pas faire cette séparation automatiquement n'accomplit pas quatre cents unités de travail utile : il en accomplit une.

Pourquoi le volume est la vraie histoire

Le nombre même des découvertes masque la tendance plus importante : la découverte a explosé, mais l'exploitation n'a pas suivi.

Sur les cinq publications depuis l'annonce « Glasswing », le volume mensuel s'est établi à environ 167, 120, 200, 570 et 400 CVE, selon l'analyse compilée par Brinqa. Les zero-days exploités activement dans ces mêmes publications ont été de deux, zéro, un, deux et un. On trouve et corrige plus de bugs que jamais; le nombre transformé en arme comme zero-day reste à peu près stable.

Le problème n'est plus que les vulnérabilités soient exploitées plus vite. C'est qu'il y en a plus que ce que n'importe quelle équipe peut trier de façon significative.

Cela recadre le défi. Si une entreprise type voit 400 découvertes par mois et que seule une poignée représente un risque réel et exploitable dans son environnement précis, le goulot d'étranglement n'est pas la capacité de correction en soi, mais la capacité à distinguer les quelques-unes qui comptent des nombreuses qui ne comptent pas. Les notes de gravité seules ne peuvent pas prendre cette décision. Le contexte, l'actif est-il exposé à Internet ? la faille est-elle atteignable ? existe-t-il un exploit public ? le composant est-il même déployé ?, est ce qui sépare une véritable urgence d'une ligne dans une liste.

Réserves et points à surveiller

Quelques réserves s'imposent. Le désaccord sur le comptage est réel mais ne change pas la priorité défensive : le haut de la liste est le même que le total soit de 398 ou de 421. Le cadrage de la « découverte assistée par IA » mérite aussi d'être manié avec prudence, c'est une explication plausible et de plus en plus citée de la hausse des volumes, mais ce n'est pas une mesure formelle, et les fournisseurs ont intérêt à attribuer la croissance à des causes enthousiasmantes.

Séparément, Help Net Security a rapporté qu'un chercheur a publié un exploit de preuve de concept, baptisé « ShieldBreak », qui contournerait selon lui le correctif de juillet de Microsoft pour la faille Defender CVE-2026-50656 (« RoguePlanet »). L'analyste en vulnérabilités Will Dormann a été cité confirmant que le PoC fonctionne avec Defender activé, même si sa portée revendiquée est encore en cours d'évaluation. S'il tient, le correctif de juillet est incomplet, un rappel qu'un correctif n'est un correctif que jusqu'à ce que quelqu'un prouve le contraire.

Il vaut aussi la peine d'être honnête sur ce que signifie « corrigé » lors d'un mois comme celui-ci. Installer la mise à jour est nécessaire mais pas suffisant; les attaquants enchaînent souvent une faille fraîchement corrigée avec une plus ancienne non corrigée, ou exploitent l'écart entre la publication du correctif et le déploiement à l'échelle du parc. Mesurer le délai entre la publication et le déploiement complet (et non le jour où la mise à jour a été approuvée) est la mesure qui réduit réellement l'exposition, et à ce volume, même des équipes bien gérées étirent cette fenêtre.

Le prochain point à surveiller, c'est de savoir si Microsoft change le rythme lui-même. À ce volume, le modèle mensuel est sous tension; certains responsables de la sécurité réclament des mises à jour continues ou à la demande pour les failles les plus graves plutôt qu'un déversement une fois par mois. Si la découverte continue de croître, la question de savoir si le Patch Tuesday peut survivre à son propre succès passera de l'expérience de pensée au problème de planification, et la réponse façonnera la manière dont chaque organisation corrige ses systèmes pendant des années.