Microsoft corrige une RCE à 10.0 dans Entra ID et dit aux clients de ne rien faire
Une vulnérabilité de désérialisation dans Entra ID, le service d’identité cloud de Microsoft, permettait l’exécution de code à distance sans authentification — notée CVSS 10.0 et corrigée côté serveur sans action client. Le RSSI doit comprendre ce que « aucune action requise » exige réellement de lui.
21 août 2026. CVSS 10.0. Désérialisation. Microsoft a corrigé une vulnérabilité d’exécution de code à distance dans Entra ID, son service d’identité cloud — et a demandé aux clients de ne rien faire. La faille, CVE-2026-69836, est notée CVSS 10.0, le score maximal, et porte sur la désérialisation de données non fiables permettant à un attaquant non authentifié d’exécuter du code sur le réseau.
La phrase à retenir n’est pas technique. Elle est dans l’avis de Microsoft : « Cette vulnérabilité a déjà été entièrement corrigée par Microsoft. Il n’y a aucune action à entreprendre pour les utilisateurs de ce service. L’objet de cette CVE est d’apporter davantage de transparence. » Un correctif invisible, pour une faille que personne ne peut vérifier.
La faille au cœur de l’identité
Entra ID — l’ex-Azure Active Directory — est le service qui authentifie les connexions et contrôle l’accès à Microsoft 365, à Azure et à des milliers d’applications tierces connectées. C’est la pièce centrale de l’identité d’entreprise chez la grande majorité des organisations.
Une désérialisation de données non fiables signifie que l’application reconvertit des données sérialisées — contrôlées par l’attaquant — en objets ou structures de code vivants, sans validation suffisante. Ici, la conséquence est la plus grave possible : un attaquant non authentifié peut exécuter du code dans le service d’identité lui-même.
La faille a été découverte par Robert Fitzpatrick, ingénieur principal de sécurité chez Microsoft. Le vecteur est à distance, sans compte, sans interaction utilisateur — le triplet qui justifie le 10.0.
Une chronologie contradictoire
Le récit public est moins net que l’avis ne le laisse paraître. Help Net Security a d’abord titré que la faille était « exploitée dans la nature », avant que Microsoft ne corrige un indicateur « Exploited » associé à la CVE. Le résultat : la vulnérabilité ne figure pas dans le KEV de la CISA, la liste des failles exploitées de référence.
Ce flottement n’est pas anodin. Un indicateur « exploité » retiré après coup, une absence du KEV, et un correctif « déjà appliqué » côté serveur : le RSSI ne dispose d’aucun moyen indépendant de savoir si l’exploitation a réellement eu lieu, ni sur quelle durée.
Microsoft n’a pas divulgué qui était derrière l’éventuelle exploitation, quand elle a commencé, combien d’organisations ont été touchées, ni ce que les attaquants ont fait une fois dans le service. Le « davantage de transparence » s’arrête au constat.
L’opacité du correctif cloud
C’est le point central. Un correctif côté serveur, sur un service multi-tenant que vous ne déployez pas, est par nature invisible : pas de binaire à télécharger, pas de version à vérifier, pas de redémarrage à planifier. Vous ne pouvez pas confirmer que la correction est en place ailleurs qu’en faisant confiance à l’éditeur.
Cette opacité inverse le rapport de force de la sécurité traditionnelle. Sur un produit on-premise, vous contrôlez le correctif ; sur un service cloud, vous contrôlez uniquement vos signaux — les journaux de connexion, les audits, les changements d’autorisation. Le périmètre de votre défense se déplace du patch vers la détection.
C’est aussi une leçon de responsabilité partagée. Microsoft corrige le service ; vous corrigez ce que le service ne peut pas corriger pour vous : les comptes, les rôles, les accès conditionnels et la surveillance.
Ce que « aucune action requise » exige en réalité
La phrase « aucune action requise » est vraie au sens technique du correctif. Elle est fausse au sens opérationnel. Voici ce qu’elle exige réellement d’une équipe qui prend la sécurité de l’identité au sérieux :
- Activer et conserver les journaux de connexion et d’audit d’Entra ID — c’est la seule trace que vous détenez ;
- Chasser les anomalies : connexions à risque, emplacements inhabituels, consentements d’applications inattendus, élévations de privilège ;
- Durcir l’accès conditionnel et la gestion des identités privilégiées (PIM) : un attaquant qui a touché le service d’identité n’a de valeur que s’il peut pivoter vers des comptes à fort privilège ;
- Revoir les consentements OAuth et les applications tierces connectées, vecteur de rebond classique après une compromission d’identité.
// Chasse aux connexions à risque dans les journaux Entra ID (Microsoft Sentinel / Log Analytics)
SigninLogs
| where RiskLevelDuringSignIn == "high" or RiskState == "atRisk"
| project TimeGenerated, UserPrincipalName, AppDisplayName, IPAddress, Location
| order by TimeGenerated descLa requête ne prouve pas l’exploitation de la CVE. Elle prouve ce qui compte davantage : que votre détection fonctionne quand un signal d’identité sort du lot.
La responsabilité partagée, version identité
La vulnérabilité d’Entra ID cristallise un basculement de la sécurité d’entreprise. Pendant deux décennies, le travail du RSSI sur une CVE était clair : identifier, prioriser, patcher, vérifier. La CVE cloud inverse la séquence : rien à patcher, tout à surveiller, et un acte de foi envers l’éditeur comme seul substitut à la vérification.
Le risque résiduel n’est pas la faille — elle est corrigée. C’est l’incertitude : sans détail technique, sans calendrier d’exploitation, sans indicateur d’attribution, impossible de dire si l’incident s’est arrêté au correctif ou s’il a laissé des portes dérobées dans des locataires.
La réponse n’est pas le rejet du cloud. C’est le durcissement du contrôle que vous conservez : une visibilité d’identité suffisante pour détecter ce que vous ne pouvez plus patcher, et un principe de moindre privilège qui limite la casse si l’identité tombe.
Ce que le retrait de l’indicateur « Exploité » révèle
Le flottement sur l’exploitation n’est pas une coquetterie éditoriale. Il révèle une asymétrie de preuve : Microsoft détient la télémétrie du service — connexions, comportements, charges — mais ne la partage pas au-delà d’un indicateur binaire, lui-même révisé. Le client, lui, ne détient que ses propres journaux de locataire.
Cette asymétrie a des conséquences concrètes. Sans calendrier ni périmètre d’exploitation, impossible de répondre à la question que posera immanquablement une direction : « avons-nous été touchés ? » La seule réponse honnête est : « nous n’avons pas d’élément pour le savoir » — une position intenable à long terme.
Deux pistes atténuent le déséquilibre. D’abord, l’attestation externe : les rapports SOC 2, ISO 27001 et les engagements contractuels de notification d’incident deviennent les seuls leviers qui contraignent un éditeur cloud à documenter ce qui s’est passé. Ensuite, la redondance de détection : ne pas se reposer sur le signal de l’éditeur, mais maintenir une télémétrie d’identité indépendante — export des journaux vers un SIEM que vous contrôlez, alertes sur les changements de rôle et les consentements.
Le correctif d’Entra ID est réglé. Ce qui ne l’est pas, c’est la capacité d’une organisation à vérifier un incident qui s’est produit chez un tiers. C’est cette capacité — pas la faille — qui fera la différence lors du prochain épisode.
Verdict
Votre travail n’est pas de patcher — il est de surveiller. Activez et centralisez les journaux de connexion d’Entra ID si ce n’est pas déjà fait, puis chassez les connexions à risque et les changements d’autorisation sur une fenêtre glissante. C’est la seule trace qui vous reste d’un correctif que vous ne verrez jamais.
Ensuite, réduisez la valeur d’une compromission d’identité. Appliquez l’accès conditionnel et la gestion des identités privilégiées jusqu’à ce qu’un compte compromis ne suffise plus à atteindre vos ressources sensibles. La faille d’Entra ID est corrigée ; la vôtre — celle de la visibilité — ne l’est que si vous la traitez.
La leçon tient en une phrase : dans le cloud, le correctif est une affaire de confiance, la détection une affaire de preuves. Un RSSI ne peut pas corriger ce qu’il ne déploie pas — il peut, en revanche, voir ce qui s’y passe.