CVE-2026-69836 Entra ID Vulnérabilité : RCE CVSS 10.0

CVE-2026-69836 Entra ID Vulnérabilité : ce qui s'est passé et pourquoi c'est important

Le 20 août 2026, Microsoft a publié un avis pour CVE-2026-69836, une vulnérabilité dans Microsoft Entra ID qui a obtenu un score CVSS parfait de 10.0. Le titre officiel est sans détour : « Microsoft Entra ID Remote Code Execution Vulnerability » (vulnérabilité d'exécution de code à distance dans Microsoft Entra ID). Selon l'avis de Microsoft lui-même, la cause racine est une désérialisation de données non fiables, et l'impact est une exécution de code à distance par un attaquant non authentifié sur le réseau — sans identifiants, sans interaction utilisateur, sans accès préalable requis.

Pour le fournisseur d'identité d'un locataire, cette combinaison est à peu près ce qu'il y a de pire en matière de notation. Entra ID est le plan de contrôle qui émet chaque jeton, évalue chaque stratégie d'Accès conditionnel et conditionne chaque activation de rôle privilégié dans un environnement Microsoft 365 ou Azure. Une faille d'exécution de code à distance dans ce plan de contrôle, accessible sans authentification, est sur le papier une alerte maximale.

Mais il s'agit aussi d'un CVE de service cloud, ce qui change la donne. Il n'y a pas de correctif à télécharger, pas d'article KB, pas de fenêtre de maintenance. Microsoft a corrigé le code vulnérable côté serveur avant même que la plupart des défenseurs n'aient vu l'avis. Ce seul fait — rien à installer — est précisément ce qui rend ce CVE digne d'une lecture attentive plutôt que d'un simple survol.

À l'intérieur de la faille : désérialisation CWE-502 et un score CVSS parfait

Microsoft classe CVE-2026-69836 sous CWE-502, Deserialization of Untrusted Data (désérialisation de données non fiables). En clair : quelque part dans le service Entra ID, des données entrantes étaient reconverties en objets actifs sans validation suffisante de leur origine ni de leur contenu. Les bugs de désérialisation sont une classe bien connue de primitive d'exécution de code à distance — les attaquants forgent une charge utile sérialisée malveillante qui, une fois reconstruite par le code vulnérable, exécute une logique arbitraire au lieu de simplement réhydrater une structure de données. C'est la même famille de bugs derrière certains des RCE Java et .NET les plus dommageables de la dernière décennie, et elle compte désormais une entrée Entra ID.

Le vecteur de base CVSS 3.1 publié par Microsoft est :

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

Lu de gauche à droite, chaque métrique atteint son maximum de sévérité : AV:N (vecteur d'attaque : réseau — accessible depuis internet), AC:L (complexité de l'attaque : faible — aucune condition particulière requise), PR:N (privilèges requis : aucun — non authentifié), UI:N (interaction utilisateur : aucune), S:C (portée : modifiée — la faille affecte des ressources au-delà du composant vulnérable), et C:H/I:H/A:H (impact élevé sur la confidentialité, l'intégrité et la disponibilité). Cette combinaison produit le score de base de 10.0. Le score temporel de Microsoft se situe à 8.7, reflétant les trois métriques temporelles qu'il ajoute à cette même chaîne vectorielle — E:U (maturité du code d'exploitation : non prouvée), RL:O (niveau de remédiation : correctif officiel) et RC:C (confiance du rapport : confirmée) — superposées à ce RCE réseau non authentifié.

Le revirement sur l'exploitation : ce que Microsoft a corrigé — et pourquoi c'est plus important que le score

Voici le détail qui rend ce CVE réellement instructif, et pas seulement un énième titre de sévérité critique : l'historique des révisions de l'avis Microsoft montre que le statut d'exploitation a changé dès le lendemain.

Révision 1.0 — 20 août 2026 : « Information published. » (Information publiée.)
Révision 1.1 — 21 août 2026 : « Corrected Exploited to No. This vulnerability was not exploited in the wild. This is an informational change only. » (Correction du champ Exploité à Non. Cette vulnérabilité n'a pas été exploitée en conditions réelles. Il s'agit uniquement d'un changement informatif.)

Plusieurs médias ayant couvert la divulgation le 21 août — dont Help Net Security, The Hacker News et The Register — ont rapporté le CVE à un moment où son statut d'exploitation était encore en évolution, avant que Microsoft ne le fixe définitivement à « Exploited: No ». The Register a notamment relevé que Microsoft a qualifié la correction d'« informational only » (informative uniquement), et qu'aucun détail technique d'une chaîne d'attaque réelle n'a été publié où que ce soit.

La position actuelle et corrigée de Microsoft, telle qu'elle figure dans le champ Exploit Status de l'avis, indique :

Publicly Disclosed: No
Exploited: No
Latest Software Release: Exploitation Less Likely

Pourquoi il n'y a pas de correctif à appliquer — et pourquoi ce n'est pas la même chose que « rien à faire »

La FAQ de Microsoft pour CVE-2026-69836 est explicite sur le modèle de remédiation : « This vulnerability has already been fully mitigated by Microsoft. There is no action for users of this service to take. The purpose of this CVE is to provide further transparency. » (Cette vulnérabilité a déjà été entièrement corrigée par Microsoft. Aucune action n'est requise de la part des utilisateurs de ce service. L'objectif de ce CVE est d'offrir davantage de transparence.) L'avis renvoie vers l'explicatif de Microsoft sur la raison d'être de ce fonctionnement pour les CVE de service cloud, « Toward greater transparency: Unveiling Cloud Service CVEs » (aka.ms/MSRC-Cloud-CVEs).

Il s'agit d'un modèle légitime et de plus en plus courant pour les plans de contrôle SaaS : Microsoft possède le code, Microsoft possède le correctif, et le CVE existe uniquement pour que l'industrie dispose d'un enregistrement public attestant qu'une faille critique a existé et a été refermée. Le chercheur crédité pour la découverte, Robert Fitzpatrick, est répertorié dans l'avis de Microsoft comme ayant signalé la faille en collaboration avec Microsoft — elle a été détectée et refermée en interne, et non par une équipe rouge externe publiant un exploit fonctionnel.

Rien de tout cela n'efface le fait que, pendant une certaine fenêtre de temps, une primitive de RCE non authentifiée et accessible sur le réseau existait dans votre fournisseur d'identité. « Entièrement corrigée » décrit la situation de la vulnérabilité à partir de maintenant. Cela ne dit rien de ce qui a pu ou non se produire pendant la fenêtre où elle était ouverte — et bien que Microsoft affirme catégoriquement que la faille « n'a pas été exploitée en conditions réelles », l'éditeur ne publie ni les preuves ni le périmètre derrière cette conclusion.

Détection : traquer sans chaîne d'attaque publiée

Voici la partie inconfortable : Microsoft n'a publié ni IOC, ni règle de détection spécifique à ce CVE, ni aucune description de ce à quoi ressemblerait une tentative d'exploitation de cette faille. Il n'y a rien contre quoi établir une signature. Cela ne signifie pas que la traque est inutile — cela signifie qu'elle doit être construite à partir de ce qu'un RCE réussi contre Entra ID toucherait vraisemblablement, et non à partir d'un playbook fourni par l'éditeur.

Quoi examiner	Où chercher	Pourquoi c'est important ici
Connexions autour du 19–22 août 2026 (UTC)	Journaux de connexion Entra ID / `auditLogs/signIns`	Encadre la fenêtre de divulgation et de correction avec une marge des deux côtés
Connexions à risque signalées par Identity Protection	Rapport de détections de risque Entra ID Protection	Un RCE qui bascule vers l'émission de jetons pourrait se manifester par des signaux de risque même sans signature connue
Inscriptions d'applications ou identifiants de principaux de service nouveaux ou modifiés	Journaux d'audit Entra ID, volet Applications	Un mouvement de persistance classique après avoir obtenu une exécution de code contre un plan de contrôle d'identité
Nouvelles attributions de rôles privilégiés ou activations PIM en dehors des schémas habituels	Historique d'audit PIM, journaux d'attribution de rôles d'annuaire	Les octrois de privilèges inattendus figurent parmi les rares artefacts que laisserait une compromission du plan de contrôle
Octrois de consentement à des applications inconnues ou récemment enregistrées	Journaux de consentement des applications d'entreprise Entra ID	Le consentement OAuth est une étape latérale courante dès qu'un attaquant dispose d'un point d'ancrage dans la couche d'identité

Pourquoi la rétention des journaux passe en premier

Avant même d'envisager tout cela, votre locataire a besoin de journaux qui couvrent réellement la fenêtre concernée. Si la rétention des journaux d'audit Entra ID de votre locataire est courte, tout cet exercice devient sans objet au-delà de quelques jours en arrière.

Extraire les données brutes

# Extraire les journaux de connexion couvrant la fenêtre de divulgation/correction (horodatages UTC).
# Nécessite la permission AuditLog.Read.All. Les espaces à l'intérieur de $filter doivent être
# encodés en pourcentage : curl rejette une URL contenant des espaces bruts avant même d'envoyer quoi que ce soit.
curl -H "Authorization: Bearer $TOKEN" \
  "https://graph.microsoft.com/v1.0/auditLogs/signIns?\$filter=createdDateTime%20ge%202026-08-19T00:00:00Z%20and%20createdDateTime%20le%202026-08-22T00:00:00Z"

Injectez le résultat dans le processus de revue d'anomalies que vous utilisez déjà pour les données de connexion — l'objectif n'est pas une requête magique, mais de s'assurer que la fenêtre est effectivement interrogeable.

Remediation : une checklist de contrôles compensatoires, pas un correctif

Il n'existe aucun correctif éditeur à déployer pour CVE-2026-69836. Ce que vous pouvez faire, c'est vous assurer que les contrôles capables de détecter les conséquences d'une compromission du fournisseur d'identité — celle-ci ou la prochaine — sont réellement activés.

Identity Protection et Accès conditionnel

Activez une stratégie de risque de connexion dans Identity Protection. Sans cela, Entra ID calcule des signaux de risque, mais rien n'agit dessus.
Appuyez-la sur une stratégie d'Accès conditionnel basée sur le risque qui renforce l'authentification ou bloque l'accès lorsque le risque de connexion est élevé, plutôt que de s'appuyer uniquement sur le score de risque. Consultez notre analyse des lacunes courantes de couverture de la stratégie de base d'Accès conditionnel pour voir à quoi ressemble un ensemble de stratégies complet.
Activez la réponse automatisée au risque pour que les sessions à risque soient traitées quasiment en temps réel plutôt que d'attendre un cycle de revue manuel — pour aller plus loin, consultez notre guide sur les stratégies de risque d'Identity Protection dans Entra ID.

Journalisation et revue continue

Étendez la rétention des journaux d'audit à une fenêtre qui prend réellement en charge la traque rétrospective, et pas seulement le dépannage au quotidien. Notre article sur la journalisation, la rétention et les paramètres de diagnostic dans Entra ID couvre la configuration pratique.
Passez en revue les principaux de service à privilèges élevés et leur activité de connexion pour repérer tout élément inattendu autour de la fenêtre de divulgation — notre article sur la détection d'anomalies de connexion des principaux de service détaille à quoi ressemble une base de référence pour les identités de charge de travail.
Abonnez-vous aux notifications de mise à jour des avis MSRC. Le statut d'exploitation de ce CVE a changé le lendemain de sa publication — si vous n'avez lu que le titre du jour de la divulgation, vous avez manqué la correction.

Ce n'est pas le premier CVE Entra ID cette année à être livré avec « aucune action client requise ». Nous avons couvert le même schéma zéro-correctif dans CVE-2026-62869, une vulnérabilité d'usurpation d'identité dans Entra ID, et à nouveau dans CVE-2026-50481, une faille d'élévation de privilèges dans Azure Active Directory — un CVSS 9.9 également livré avec une liste de remédiation vide et Customer Action Required: No. Le schéma devient routinier : Microsoft déploie le correctif, et la seule chose qui reste aux locataires est de décider jusqu'où regarder en arrière.

Comment EtcSec détecte cela

L'audit Azure d'EtcSec ne détecte pas — et ne peut pas détecter — l'exploitation d'un CVE côté service comme CVE-2026-69836 ; cette visibilité se situe entièrement à l'intérieur de la propre infrastructure de Microsoft. Ce qu'il vérifie, ce sont précisément les lacunes qui transforment un incident comme celui-ci en angle mort : l'existence ou non d'une stratégie de risque de connexion, si ce risque est appuyé par une stratégie d'Accès conditionnel basée sur le risque, si les réponses au risque sont automatisées plutôt que manuelles, si la rétention des journaux d'audit est suffisamment longue pour permettre une traque rétrospective, et si des principaux de service détiennent des privilèges administratifs sans revue continue.