Microsoft corrige près de 1 000 failles de sécurité, et les équipes de correctifs font face au goulot d’étranglement

Microsoft corrige près de 1 000 failles de sécurité dans sa mise à jour de septembre, dont deux vulnérabilités Windows déjà exploitées par des attaquants. Ce lot record couvre Windows, Office, Exchange Server, SharePoint, SQL Server, Azure et plusieurs outils de développement. Il transforme également Patch Tuesday en un test de la capacité des défenseurs à convertir rapidement les données sur les vulnérabilités en mises à jour sûres pour la production.

Le fait marquant n’est pas seulement que Microsoft a trouvé davantage de défauts. Microsoft affirme que l’intelligence artificielle aide désormais ses chercheurs à examiner du code complexe à une échelle que les revues manuelles ne pourraient pas soutenir. Cette capacité accrue peut révéler les vulnérabilités plus tôt, mais elle génère aussi davantage de correctifs que les clients doivent évaluer, tester, planifier et surveiller.

Cela crée une course déséquilibrée. L’IA peut accélérer la découverte au sein d’un éditeur logiciel, tandis que le déploiement reste limité par les inventaires, les fenêtres de maintenance, les tests de compatibilité et les validations humaines. Microsoft peut produire des correctifs plus vite que de nombreuses organisations ne peuvent les absorber en toute sécurité. L’avantage en matière de sécurité dépend donc de la capacité des opérations de correctifs à suivre ce nouveau rythme de découverte.

Microsoft corrige près de 1 000 failles de sécurité en une seule publication

La publication de septembre établit un record, mais ses risques les plus urgents sont concentrés dans un groupe bien plus restreint de vulnérabilités.

Microsoft a publié ses mises à jour de sécurité mensuelles le 8 septembre, traitant 974 Microsoft Common Vulnerabilities and Exposures, ou CVE. Une CVE est un identifiant standardisé pour une faille de sécurité divulguée publiquement. Ce lot était la plus importante collection mensuelle jamais publiée par Microsoft.

Les décomptes indépendants diffèrent légèrement, car les chercheurs appliquent des règles d’inclusion distinctes. Certains excluent les failles déjà traitées ou séparent les vulnérabilités héritées de Chromium. Cela explique les chiffres allant du milieu des 960 au bas des 970, plutôt que l’existence de plusieurs publications distinctes de correctifs.

Les notes de publication de Microsoft fournissent l’inventaire officiel des produits, tandis que des chercheurs indépendants affinent ces données pour une utilisation opérationnelle. Le chiffre principal reste clair malgré ces différences de comptage. Il s’agissait d’une publication de sécurité Microsoft sans précédent, quelle que soit la méthodologie couramment employée.

Le lot record de correctifs comprenait des centaines de vulnérabilités dans Windows et Office. SecurityWeek a compté 723 failles Windows et 222 dans la famille Office, dont 111 affectant Office 2016.

Microsoft a également traité 62 vulnérabilités SQL Server, 22 dans les outils de développement, 16 dans SharePoint Server et 12 dans Azure. Skype for Business et Exchange Server en représentaient respectivement 10 et neuf autres.

Ces totaux ne signifient pas que chaque client utilise 974 produits vulnérables. L’exposition d’une entreprise dépend de ses systèmes d’exploitation, applications installées, services cloud, rôles serveur, configurations et de l’accessibilité réseau. De nombreuses organisations constateront que seule une partie de la publication s’applique à leur environnement.

L’étendue reste néanmoins importante. Les entreprises exploitent rarement une seule génération de Windows ou une unique configuration Office standardisée. Elles maintiennent souvent simultanément des postes de travail de développeurs, des machines virtuelles, des serveurs de bases de données, des plateformes de collaboration et d’anciennes applications métier.

Deux vulnérabilités Windows exigent une attention immédiate, car Microsoft a identifié une exploitation active. CVE-2026-85880 affecte Windows Advanced Local Procedure Call, ou ALPC. Windows utilise ALPC pour les communications à haut débit entre processus sur un même ordinateur.

La vulnérabilité implique un dépassement de tampon basé sur le tas. Microsoft indique qu’un attaquant disposant d’une exécution de code dans un AppContainer à faibles privilèges peut sortir de cet environnement restreint et obtenir des privilèges System. L’exploitation ne requiert aucune interaction supplémentaire de l’utilisateur après que l’attaquant a établi la position locale nécessaire.

La seconde faille exploitée, CVE-2026-81963, affecte Windows Update Stack. Cet ensemble de composants installe et maintient les mises à jour Windows. La faiblesse concerne le suivi de liens, lorsqu’un logiciel accède à un fichier ou à un emplacement référencé sans résoudre sa destination de manière sûre.

Un attaquant peut utiliser cette faille pour élever ses privilèges locaux au niveau System. Son emplacement au sein du mécanisme de mise à jour lui confère une importance opérationnelle supplémentaire, même si Microsoft n’a pas révélé qui l’exploite. Les informations publiques n’établissent pas non plus l’ampleur ni les cibles des attaques.

CISA a ajouté ces deux vulnérabilités à son catalogue des failles exploitées. Cette inclusion confirme l’existence de preuves d’exploitation, mais ne prouve pas que les attaques soient généralisées.

Cette distinction doit guider la réponse. Le total record décrit la charge de travail, tandis que les preuves d’exploitation identifient le danger immédiat. Traiter chaque entrée comme étant aussi urgente consommerait le temps nécessaire pour les vulnérabilités déjà utilisées par les attaquants.

La publication de septembre modifie donc davantage qu’une statistique mensuelle. Elle fait de la priorisation le contrôle de sécurité central. Les organisations doivent identifier les vulnérabilités applicables, accessibles et exploitées avant que leur volume ne submerge leur processus de déploiement.

La découverte de vulnérabilités par l’IA élargit la chaîne de correctifs

Les publications plus importantes de Microsoft reflètent un système de découverte capable d’inspecter davantage de code, mais trouver une faille ne reste que la première étape.

Microsoft intègre l’assistance de l’IA à la recherche de vulnérabilités dans Windows, Azure, les systèmes d’identité et d’autres flux d’ingénierie. L’entreprise décrit ce travail comme un moyen d’examiner des surfaces de code nécessitant une expertise et un temps considérables pour être auditées manuellement.

Un système Microsoft, connu sous le nom de code MDASH, analyse des composants complexes tels que le noyau Windows, Hyper-V, les réseaux et Active Directory. Ces zones appliquent des frontières de confiance et gèrent les ressources entre processus, machines ou environnements virtuels.

Selon Microsoft, le système combine un raisonnement centré sur le code avec des flux de validation et de remédiation. Les résultats confirmés peuvent apparaître dans GitHub Advanced Security, Azure DevOps et Microsoft Defender. Les ingénieurs peuvent alors attribuer un responsable, créer des éléments de travail, examiner les correctifs et bloquer les builds affectés.

Cette intégration compte, car une alerte générée par l’IA n’est pas automatiquement une vulnérabilité. Les équipes de sécurité doivent reproduire le comportement, déterminer si les attaquants peuvent y accéder, évaluer l’impact et distinguer les défauts des faux positifs. Une découverte valide doit ensuite passer la revue de code et les tests de régression.

Le workflow de sécurité IA publié par Microsoft souligne que les humains restent impliqués. L’entreprise affirme que l’IA étend la portée des chercheurs plutôt qu’elle ne remplace les spécialistes qui comprennent le comportement des systèmes de bas niveau.

Microsoft avait précédemment indiqué que des modèles récents approchaient les chercheurs humains expérimentés dans certaines tâches de découverte de vulnérabilités. L’entreprise a également déclaré que les systèmes d’IA pouvaient fonctionner en continu, principalement limités par les ressources informatiques disponibles. Il s’agit d’affirmations de l’entreprise, et l’évaluation indépendante à long terme reste incomplète.

Le lot de septembre apporte néanmoins des éléments indiquant un changement opérationnel majeur. Microsoft traite un nombre de découvertes bien supérieur à ce qu’exigeait son rythme mensuel antérieur. Cette hausse s’inscrit dans la continuité d’autres publications exceptionnellement importantes en 2026.

En juillet, les notes de publication officielles de Microsoft recensaient 663 CVE Microsoft. Ars Technica a rapporté que des chercheurs externes avaient compté environ 570 vulnérabilités nouvellement corrigées selon des règles plus restrictives. Août a apporté une autre publication contenant des centaines de correctifs.

En septembre, le volume mensuel avait encore augmenté. Ars a estimé que Microsoft avait corrigé 2 760 vulnérabilités en 2026 à la date de la publication de septembre. Ce total représentait déjà plus du double de son décompte pour l’année précédente selon la méthodologie de la publication.

Cette tendance ne prouve pas que les logiciels Microsoft sont soudainement devenus moins sûrs. Les décomptes de vulnérabilités mélangent les nouveaux bugs et les défauts plus anciens que les chercheurs n’ont découverts que récemment. Une meilleure découverte peut faire paraître les chiffres publiés d’un produit plus mauvais tout en réduisant son risque caché.

L’analogie d’un entrepôt aide à expliquer ce renversement. Installer un éclairage plus puissant peut révéler davantage de stocks endommagés sans en être la cause. L’opérateur fait alors face à une file de réparations plus importante, car des problèmes auparavant invisibles deviennent exploitables.

L’IA change également la quantité de code pouvant faire l’objet d’une attention soutenue. Les revues de sécurité manuelles tendent à se concentrer sur les composants exposés ou historiquement problématiques. L’analyse automatisée peut inspecter de manière répétée des chemins obscurs, des interfaces héritées et des interactions à travers une vaste base de code.

Cette couverture plus large est précieuse pour Windows, qui doit prendre en charge d’importantes exigences de compatibilité matérielle, applicative et d’entreprise. Elle devrait également maintenir les décomptes de correctifs à un niveau élevé pendant que Microsoft examine du code accumulé sur de nombreuses générations de produits.

Toutefois, le débit de découverte n’est qu’une mesure du succès. Microsoft doit valider les découvertes, produire des correctifs exacts et éviter les régressions. Les clients doivent déployer ces correctifs avant que les attaquants ne transforment les informations divulguées en exploits fiables.

Microsoft corrige près de 1 000 failles de sécurité décrit donc la production d’une chaîne de sécurité plus vaste. Cela n’établit pas que l’ensemble de cette chaîne, y compris le déploiement chez les clients, s’est accéléré au même rythme.

Le véritable goulot d’étranglement passe de la découverte des bugs au déploiement des correctifs

L’IA peut augmenter la capacité de découverte de Microsoft, mais les correctifs en entreprise avancent encore au rythme des tests, de l’attribution des responsabilités et du contrôle des changements.

Une mise à jour de sécurité ne protège pas une organisation simplement parce que Microsoft la publie. La protection commence lorsqu’une organisation identifie les actifs concernés, obtient la mise à jour, la teste, la déploie et confirme que l’installation a réussi.

Chaque étape comporte des frictions. Les inventaires d’actifs peuvent être incomplets, notamment lorsque les équipes gèrent des ordinateurs distants, des charges de travail cloud, des systèmes de laboratoire et des unités opérationnelles acquises. Des logiciels non pris en charge peuvent rester connectés parce qu’un projet de remplacement n’est pas achevé.

Les tests introduisent une autre contrainte. Les mises à jour Windows et Office peuvent affecter l’authentification, les pilotes de périphériques, les macros, les composants de navigateur, les connexions aux bases de données ou des applications métier spécialisées. Les équipes opérationnelles ont besoin de preuves qu’un correctif n’interrompra pas les revenus, la production industrielle, les soins de santé ou d’autres activités essentielles.

Une publication de 974 CVE ne nécessite pas 974 installations distinctes. Microsoft distribue de nombreux correctifs Windows via des packages cumulatifs, qui combinent des corrections actuelles et antérieures. Ce modèle de distribution simplifie l’installation, mais n’élimine pas l’évaluation des risques.

Les équipes de sécurité doivent toujours associer les vulnérabilités individuelles aux actifs et aux services métier. Elles doivent déterminer si une mise à jour cumulative atteint chaque système concerné. Elles ont également besoin de plans de secours lorsqu’une mise à jour provoque des problèmes de compatibilité.

La publication de septembre comprenait de nouvelles Servicing Stack Updates pour plusieurs plateformes plus anciennes. La pile de maintenance est le composant Windows qui installe les mises à jour du système d’exploitation. Des problèmes à ce niveau peuvent empêcher l’installation correcte de correctifs de sécurité ultérieurs.

Les environnements plus anciens méritent une attention particulière, car leurs processus de maintenance sont souvent plus complexes. Une organisation peut nécessiter des contrats de support étendu, des fenêtres d’indisponibilité très limitées ou l’accord d’un éditeur d’applications. La machine la plus exposée est parfois aussi la plus difficile à modifier.

C’est pourquoi le décompte mensuel peut devenir trompeur. Une faille de faible gravité sur un poste de travail isolé peut mériter moins d’attention qu’une faiblesse exploitée sur un serveur exposé à Internet. Une note critique ne révèle pas non plus automatiquement si un attaquant peut atteindre le composant concerné.

La répartition des vulnérabilités a identifié 20 failles que les chercheurs considéraient comme potentiellement exploitables par un ver. Une vulnérabilité exploitable par un ver peut permettre l’exécution de code à distance sans authentification ni interaction utilisateur, autorisant un logiciel malveillant à se propager entre les systèmes.

Le caractère potentiellement exploitable par un ver ne signifie pas qu’un ver fonctionnel existe déjà. Les exigences de configuration, l’exposition réseau et la fiabilité de l’exploit peuvent limiter le risque pratique. Ces failles justifient néanmoins une analyse rapide, car une exploitation réussie peut s’étendre au-delà d’un seul appareil compromis.

CVE-2026-55007 dans Exchange Server illustre cette préoccupation. Des chercheurs ont indiqué qu’un attaquant distant pourrait tenter d’exécuter du code en envoyant une pièce jointe Visio malveillante. L’infrastructure de messagerie est souvent exposée et assure une fonction centrale pour l’entreprise, ce qui complique la maintenance d’urgence.

CVE-2026-69525 affecte Remote Desktop Services et a reçu un score de gravité de 9,8. Remote Desktop peut fournir un accès administratif précieux, mais les déploiements exposés ou largement accessibles créent également des vecteurs d’attaque attractifs.

SharePoint, SQL Server et les composants d’identité créent des contraintes différentes. Ils hébergent souvent des informations sensibles, relient plusieurs applications ou soutiennent des flux de travail internes. Une mise à jour précipitée pourrait interrompre des services dépendants, tandis qu’une mise à jour retardée peut laisser une cible de valeur exposée.

La réponse n’est pas de tester chaque correctif pendant la même durée. Les programmes matures créent des anneaux de déploiement. Ils mettent d’abord à jour un petit groupe représentatif, observent les résultats, étendent le déploiement à des groupes plus larges et prévoient un traitement particulier pour les systèmes critiques.

Les vulnérabilités d’urgence nécessitent une voie plus rapide. Les systèmes touchés par une exploitation active ne devraient pas attendre derrière les correctifs de postes de travail habituels. Les responsables de la sécurité et des opérations doivent avoir l’autorité de raccourcir les cycles d’approbation lorsque l’exposition et l’impact métier le justifient.

Le Center for Internet Security recommande une remédiation fondée sur les risques. Ses recommandations associent des mises à jour rapides à des tests, à une gestion automatisée des correctifs, à l’analyse des vulnérabilités et à des contrôles de moindre privilège.

Le moindre privilège est particulièrement pertinent pour les failles Windows exploitées. Toutes deux peuvent aider un attaquant local à obtenir des privilèges System. Restreindre les privilèges initiaux des utilisateurs et des applications ne peut pas éliminer ces vulnérabilités, mais peut réduire les points d’entrée disponibles et limiter certaines chaînes d’attaque.

Les contrôles compensatoires peuvent également faire gagner du temps. La segmentation réseau peut restreindre l’accès aux services vulnérables. Les contrôles applicatifs peuvent bloquer le code non approuvé. La détection sur les terminaux peut surveiller les changements de privilèges suspects pendant que les équipes valident les correctifs.

Aucun de ces contrôles ne remplace la mise à jour. Leur objectif est de gérer l’intervalle entre la divulgation et le déploiement vérifié. Cet intervalle devient plus important à mesure que la découverte de vulnérabilités s’accélère.

Un décompte record ne signifie pas une vague d’attaques record

Le volume de correctifs signale une visibilité accrue, mais les défenseurs ne disposent toujours pas de preuves que l’exploitation progresse au même rythme.

Le lot de septembre invite à deux erreurs opposées. La première est la complaisance, car la plupart des vulnérabilités ne toucheront pas toutes les organisations. L’autre est la panique, car un titre à quatre chiffres peut donner l’impression qu’une priorisation méthodique est impossible.

Les équipes de sécurité doivent poser une question plus ciblée : quelles vulnérabilités créent des vecteurs d’attaque crédibles dans cet environnement ? Y répondre exige davantage que des scores de gravité. Les équipes ont besoin du statut d’exploitation, de l’exposition des actifs, des privilèges requis, de l’interaction utilisateur et de la valeur des systèmes touchés.

Deux vulnérabilités font l’objet d’une exploitation confirmée. Cette preuve les place avant les failles dont l’impact reste seulement théorique. Le catalogue de la CISA fournit un signal de priorisation solide, car il exige des preuves que des acteurs malveillants ont exploité le problème.

Toutefois, l’exploitation confirmée ne révèle pas tout. Microsoft n’a pas publiquement identifié les attaquants, les victimes, l’ampleur de la campagne ni les méthodes d’accès initial associées aux deux zero-days Windows. Les défenseurs devraient éviter d’inventer le récit d’une campagne à partir de données incomplètes.

De même, les 20 vulnérabilités potentiellement exploitables par un ver méritent un examen attentif sans être décrites comme des vers actifs. Une vulnérabilité peut remplir les conditions techniques d’une propagation automatisée tout en restant difficile à exploiter de manière fiable dans des réseaux réels.

Les chercheurs ont également averti que des publications de correctifs plus importantes créent des bottes de foin plus grandes. Satnam Narang de Tenable a soutenu que le nombre de problèmes affectant une organisation typique reste bien inférieur au total mensuel. Son observation plaide pour un triage contextualisé plutôt qu’un simple comptage brut.

Le défi consiste à déterminer quelles aiguilles comptent avant que les attaquants ne les trouvent. La publication fournit les détails techniques dont les défenseurs ont besoin, mais ces détails peuvent aussi aider les développeurs d’exploits. Les outils d’IA peuvent raccourcir le temps d’analyse pour les deux camps.

Cette dynamique à double usage explique pourquoi Microsoft investit dans une découverte plus rapide. Identifier et corriger une faille avant son exploitation donne aux défenseurs une longueur d’avance. Publier des centaines de correctifs à la fois répartit toutefois l’attention sur une file d’attente beaucoup plus vaste.

La valeur à long terme de la recherche de bugs assistée par l’IA demeure incertaine. Les critiques remettent en question les coûts des modèles, les taux de faux positifs, la conception des benchmarks et l’effort humain nécessaire pour valider les résultats. Les fournisseurs ont également intérêt à présenter les systèmes de sécurité basés sur l’IA comme la preuve de la valeur de leurs investissements plus larges.

Les partisans soulignent la hausse du nombre de découvertes validées dans de grands projets logiciels. Ils estiment que les vulnérabilités cachées restent dangereuses, que les chercheurs puissent les voir ou non. Selon cette perspective, une publication importante représente une visibilité longtemps attendue plutôt qu’une baisse de qualité.

Les deux positions peuvent être partiellement vraies. L’IA peut identifier de véritables vulnérabilités tout en produisant un bruit coûteux. Un système productif doit améliorer le ratio entre les découvertes exploitables et le temps des analystes, et non simplement maximiser le nombre d’alertes.

Microsoft indique qu’il transmet les découvertes validées vers ses systèmes d’ingénierie existants, avec des responsables désignés et des modifications de code. Cette approche répond à une défaillance fréquente de l’automatisation de la sécurité, où les résultats des scanners s’accumulent sans atteindre les développeurs responsables de la remédiation.

Les organisations clientes ont besoin d’une boucle fermée similaire. Un enregistrement de vulnérabilité doit être relié à un actif, à un responsable, à un service métier, à une décision de déploiement et à une preuve de réalisation. Sans ces liens, une détection plus rapide ne fait qu’augmenter l’arriéré.

Les divergences de décompte renforcent également le besoin de précision. Le débat sur le décompte mensuel a produit des totaux de 972, 974 ou d’autres chiffres voisins. Les chercheurs divergeaient sur les correctifs Chromium, les entrées republiées et les vulnérabilités déjà traitées.

Ces différences ne remettent pas en cause la publication. Elles montrent que les totaux de CVE sont des synthèses comptables, et non des mesures directes du risque client. Un tableau de bord utile devrait distinguer les problèmes nouvellement divulgués, les produits applicables, l’exploitation confirmée, l’exposition et l’état du déploiement.

Les organisations devraient également mesurer la qualité des correctifs. Une mise à jour qui s’installe correctement mais perturbe une application critique crée un risque opérationnel. Un correctif qui semble déployé mais laisse un composant plus ancien actif crée un faux sentiment de sécurité.

Les taux de retour en arrière, les installations échouées, les exceptions d’urgence et les actifs exposés non corrigés révèlent davantage que le décompte mensuel des CVE. Ces indicateurs montrent si un programme de sécurité peut absorber le rythme accru de Microsoft sans perdre le contrôle.

La publication de septembre ne prouve donc pas que les attaquants ont déjà atteint une accélération équivalente. Elle montre que la découverte et la divulgation de vulnérabilités sont entrées dans une phase de volume plus élevé. L’issue défensive reste incertaine.

Ce que les équipes de sécurité devraient surveiller après septembre

Trois signaux montreront si cette publication record améliore la sécurité ou agrandit simplement l’arriéré de correctifs.

Le premier signal est l’activité d’exploitation autour de CVE-2026-85880 et CVE-2026-81963. De nouvelles recommandations de la CISA, des indicateurs publics de compromission ou des signalements d’incidents plus larges augmenteraient leur priorité au-delà des preuves actuelles.

Les organisations devraient surveiller les actifs Windows concernés afin de détecter une élévation de privilèges suspecte et des changements inhabituels autour des composants de mise à jour. Elles devraient également vérifier le déploiement plutôt que de s’appuyer uniquement sur l’état indiqué par la console de gestion. Une installation signalée n’est utile que si la version protégée est réellement en cours d’exécution.

Si Microsoft ou la CISA relie l’une ou l’autre faille à de vastes campagnes, la publication de septembre devient un événement actif de gestion des incidents. Si l’exploitation reste limitée, les équipes doivent tout de même procéder rapidement à la remédiation, mais elles peuvent conserver une séquence de déploiement maîtrisée.

Le deuxième signal est la fiabilité des mises à jour de septembre. Des problèmes de compatibilité, des erreurs d’installation ou des révisions d’urgence hors bande ralentiraient l’adoption par les entreprises. Des packages cumulatifs stables soutiendraient l’affirmation de Microsoft selon laquelle son pipeline d’ingénierie peut gérer un volume de découvertes plus important.

Les équipes chargées des correctifs devraient suivre les taux de réussite par groupe d’appareils et catégorie d’applications. Elles devraient comparer les échecs entre les postes de travail standard, les machines de développeurs, les serveurs et les systèmes spécialisés. Ces données peuvent révéler où les tests ou la responsabilité doivent être améliorés.

Un premier anneau de déploiement réussi devrait déclencher une extension, et non une période d’observation indéfinie. Les organisations perdent souvent du temps entre des tests réussis et une approbation élargie. Des seuils clairs peuvent empêcher un processus prudent de devenir un retard non géré.

Le troisième signal est la taille et la composition des prochaines publications de Microsoft. Un autre mois exceptionnellement important suggérerait que la découverte assistée par l’IA a durablement modifié le rythme. Un déclin rapide soutiendrait l’idée que Microsoft résorbe un inventaire accumulé de défauts cachés.

La composition importe davantage que le total. Les défenseurs devraient surveiller la part des failles exploitables à distance, des attaques confirmées, des composants d’infrastructure critique et des vulnérabilités découvertes grâce aux systèmes d’IA de Microsoft. Ces catégories indiqueront si le bénéfice de sécurité devient plus significatif sur le plan opérationnel.

Microsoft doit également démontrer que la prévention s’améliore parallèlement à la découverte. Trouver d’anciens bugs est précieux, mais le résultat le plus solide consiste à empêcher des défauts similaires avant la livraison du code. Des catégories de failles récurrentes suggéreraient que la remédiation n’a pas encore suffisamment modifié les pratiques de développement.

Pour les dirigeants d’entreprise, la leçon immédiate est pratique. Microsoft comble près de 1 000 failles de sécurité, mais les clients n’ont pas besoin de 974 projets d’urgence identiques. Ils ont besoin d’un processus défendable qui identifie systématiquement le petit ensemble nécessitant une action immédiate.

Commencez par les deux vulnérabilités Windows exploitées. Examinez ensuite les vecteurs accessibles d’exécution de code à distance, les serveurs exposés, les systèmes d’identité et les services de données à forte valeur. Faites passer les autres mises à jour applicables par des anneaux de déploiement testés, avec des responsables clairement désignés.

Posez une dernière question après la clôture de la fenêtre de correctifs : votre organisation peut-elle prouver quels systèmes exposés restent vulnérables, pourquoi ils le restent et quand cette situation prendra fin ? Si la réponse dépend de feuilles de calcul, d’inventaires incomplets ou d’exceptions informelles, la publication record de septembre a révélé une lacune de processus aussi importante que n’importe quelle CVE individuelle.