Défenseur sous le feu : Deux failles activement exploitées et l’angle mort dans le SOC

Microsoft Defender, qui fonctionne comme une couche de protection sur des millions de systèmes Windows, présente deux vulnérabilités activement exploitées. L’une d’elles permet une élévation locale des privilèges. La CISA a intégré ces deux failles dans son catalogue des vulnérabilités exploitées et a fixé une échéance au 3 juin pour les agences fédérales. Pour les SOC de la région DACH, ce cas n’est pas tant une alerte qu’un rappel : même l’outil qui protège constitue une surface d’attaque.

En lien :Le Time-to-Exploit chute à 24-48 heures  /  Responsabilité cyber dans l’administration

Ce qui est précisément exploité

Qu’est-ce qu’une faille d’élévation de privilèges ? Une vulnérabilité permettant une escalade des droits permet à un attaquant, qui dispose déjà d’un accès restreint à un système, d’obtenir des privilèges plus élevés, jusqu’au contrôle total dans le pire des cas. Elle n’est rarement la première étape d’une attaque, mais presque toujours la décisive.

La plus critique des deux failles porte la référence CVE-2026-41091 et affiche un score CVSS de 7,8. Il s’agit d’une erreur de type *link-following* : Defender suit, dans certaines conditions, un lien manipulé et accède à un fichier auquel l’attaquant ne devrait normalement pas avoir accès avec des privilèges élevés. Le résultat est une élévation locale des privilèges. Celui qui a déjà un pied dans le système, par exemple via du phishing ou une autre faille, peut l’étendre pour en prendre le contrôle total.

La seconde faille, CVE-2026-45498, est bien moins critique avec un score CVSS de 4,0. Elle permet un déni de service, c’est-à-dire la mise hors service ciblée du service. Désagréable, mais pas une porte d’entrée pour une prise de contrôle. Selon Microsoft, ces deux vulnérabilités recoupent des zero-days révélés en avril, connus sous les noms de RedSun et UnDefend.

L’ajout *« activement exploité »* fait toute la différence. Une faille théorique est un risque sur le papier. Une faille exploitée signifie qu’il existe déjà, quelque part, du code capable de l’activer. La CISA n’intègre pas une vulnérabilité dans son catalogue parce qu’elle *pourrait* être dangereuse, mais parce qu’elle est *prouvée* comme étant utilisée à mauvais escient. C’est précisément cette distinction qui doit guider la priorisation en interne. Une faille notée 7,8 sans exploit peut attendre ; la même faille avec une exploitation active, non.

Pourquoi la correction automatique n’est pas un blanc-seing

Microsoft souligne que les deux failles sont distribuées via les mises à jour de définitions de Defender. Pour la plupart des systèmes, aucune intervention manuelle n’est nécessaire. C’est la bonne nouvelle. Elle est vraie. Mais c’est aussi là que commence la négligence.

Les mises à jour automatiques ne fonctionnent que si le mécanisme est opérationnel. En pratique, il existe suffisamment de systèmes où ce n’est pas le cas : réseaux de production isolés sans accès à Internet, machines avec des versions figées, appareils dont le service de mise à jour a été limité pour des raisons de performance. Ce sont précisément ces systèmes qui sont souvent critiques. Ceux qui se fient à la mise à jour silencieuse sans vérifier confondent probabilité et certitude.

Les versions pertinentes sont documentées. La correction pour l’élévation de privilèges porte la version de plateforme 1.1.26040.8, tandis que celle pour le déni de service a la version de moteur 4.18.26040.7. Un rapide contrôle du parc informatique révèle si la flotte est effectivement protégée ou si certains systèmes sont à la traîne.

L’angle mort s’appelle la confiance

Le véritable enseignement ne réside pas dans les deux numéros CVE. Il réside dans l’hypothèse que font implicitement de nombreuses organisations : le produit de protection lui-même serait sûr. La protection des terminaux s’exécute avec des droits élevés, en profondeur dans le système, avec un accès à presque tout. C’est précisément ce qui en fait une cible de choix. Une faille dans le gardien pèse plus lourd qu’une faille dans une application quelconque.

Ce n’est pas un argument contre Defender ou contre la protection des terminaux en général. C’est un argument en faveur d’un inventaire sobre. Les logiciels de sécurité doivent suivre le même rythme de correctifs et de surveillance que toute autre composante critique. Ils ne méritent pas une confiance aveugle simplement parce que leur finalité est de protéger. Ceux qui les excluent de la gestion des vulnérabilités créent un angle mort à l’endroit le plus sensible.

Le délai fixé par la CISA jusqu’au 3 juin ne s’applique formellement qu’aux agences fédérales américaines. Mais il constitue un signal valable partout. Lorsqu’une autorité tenue de réagir priorise une faille, cela fournit un repère utile pour tout acteur de la zone DACH. La question n’est pas de savoir si votre organisation doit respecter ce délai. La question est de savoir si elle en serait capable.

Ce que les SOC doivent vérifier concrètement dès maintenant

La première étape consiste à faire un état des lieux, pas à appliquer des correctifs par réflexe. Un SOC doit savoir quelles versions de plateforme et de moteur Defender sont actuellement déployées. Ce n’est qu’avec cette vue d’ensemble qu’il peut déterminer si la mise à jour automatique a bien couvert l’ensemble du parc ou si certains segments sont à la traîne. Sans cette visibilité, les correctifs sont appliqués à l’aveugle, et une faille n’est remarquée que lorsqu’elle est exploitée.

La deuxième étape concerne la télémétrie. Une élévation de privilèges locale laisse des traces : accès inhabituels aux composants de Defender, liens manipulés, processus s’exécutant avec des droits inattendus. Ces signaux doivent être intégrés aux règles de détection, non pas après l’incident, mais dès maintenant. Un EDR qui ne surveille pas sa propre intégrité est aveugle à l’endroit le plus sensible.

La troisième étape est organisationnelle. Les logiciels de sécurité nécessitent un responsable désigné pour leur niveau de correctifs, au même titre qu’un serveur de base de données ou une passerelle web. Tant que personne n’est explicitement chargé de veiller à ce que Defender soit à jour, cette tâche disparaît dans l’hypothèse que le système s’en occupe déjà seul. Cette hypothèse est confortable. Elle explique aussi pourquoi de telles failles survivent pendant des semaines.

Foire aux questions

Chaque question est verrouillée. Un clic déverrouille la réponse.