Ce que Microsoft a divulgué, et ce que signifie le score
Un score CVSS de 10.0 est aussi grave que l’échelle le permet, et il est rare. Microsoft a attribué exactement cela à la CVE-2026-69836, une vulnérabilité d’exécution de code à distance dans Entra ID détaillée par Help Net Security après la divulgation du 21 août 2026. L’avis de Microsoft décrit clairement la cause racine : « La désérialisation de données non fiables dans Microsoft Entra ID permet à un attaquant non autorisé d’exécuter du code sur un réseau. » En termes simples, la faille aurait pu permettre à un attaquant sans identifiants valides d’exécuter du code arbitraire à distance contre le service.
Le score maximal n’est pas arbitraire. Le CVSS atteint 10.0 seulement lorsqu’une vulnérabilité combine les pires valeurs sur chaque dimension : exploitable sur le réseau, ne nécessitant aucun privilège, aucune interaction utilisateur, et compromettant totalement la confidentialité, l’intégrité et la disponibilité. Une faille de désérialisation qui offre à un attaquant distant non authentifié l’exécution de code coche toutes ces cases. La vulnérabilité a été découverte par Robert Fitzpatrick, ingénieur principal de sécurité chez Microsoft, et l’avis a d’abord été publié le 21 août puis mis à jour le 24 août 2026.
L’endroit où vit ce bug est ce qui l’élève de grave à systémique. Comme l’a noté The Register dans sa couverture, Entra ID est le service cloud de gestion des identités et des accès de Microsoft — le système qui vérifie les connexions et contrôle l’accès à Microsoft 365, Azure et aux applications tierces connectées. Une compromission de la couche d’identité n’est pas la compromission d’une application ; c’est potentiellement la compromission de tout ce qui fait confiance à cette couche pour dire qui est un utilisateur.
La classe de bug de désérialisation — et pourquoi l’identité est le pire endroit pour elle
La désérialisation non sûre est une classe de vulnérabilité bien comprise et dangereuse. La désérialisation est le processus par lequel une application transforme des données stockées ou transmises en objets vivants en mémoire. Lorsqu’une application fait cela sur une entrée contrôlée par un attaquant sans validation suffisante — le schéma de désérialisation de données non fiables que l’avis même de Microsoft cite comme cause racine — une charge utile fabriquée peut tromper l’application pour qu’elle construise des objets exécutant du code que le développeur n’avait jamais prévu. La technique a produit certaines des vulnérabilités les plus graves de la dernière décennie à travers les logiciels d’entreprise.
La raison pour laquelle une RCE de désérialisation dans Entra ID est particulièrement alarmante est le rayon d’impact du plan d’identité. Les entreprises modernes fédèrent l’authentification : un fournisseur d’identité unique émet les jetons qui accordent l’accès à la messagerie, aux fichiers, à l’infrastructure cloud et aux applications SaaS. Si un attaquant peut exécuter du code à l’intérieur de ce service d’identité, les hypothèses de confinement habituelles s’effondrent — il n’y a pas de « une application est compromise, les autres vont bien », car le composant compromis est celui auquel toutes les autres applications font confiance. C’est précisément pourquoi les divulgations d’infrastructure d’identité attirent une attention démesurée même lorsque, comme ici, le fournisseur ne signale aucune exploitation dans la nature.
Le drapeau « exploité » qui a basculé
La divulgation comportait une particularité inhabituelle, elle-même instructive. Le bulletin de sécurité de Microsoft a d’abord marqué le champ « Exploité » comme « Oui », impliquant des attaques actives, avant de corriger le statut en « Non » après que The Hacker News a contacté l’entreprise, déclarant que la vulnérabilité « n’a pas été exploitée dans la nature ». L’épisode souligne le poids que les défenseurs accordent à ce seul champ — une étiquette « exploité » déclenche généralement des cycles de correctifs d’urgence et des listes gouvernementales de vulnérabilités exploitées — et comment une erreur d’étiquetage sur un bug d’identité au score parfait peut envoyer les équipes de sécurité paniquer avant que les faits ne se stabilisent.
Fait crucial, comme Entra ID est un service cloud exploité par Microsoft plutôt qu’un logiciel que les clients installent et corrigent eux-mêmes, la voie de correction était différente d’une CVE typique. Comme l’a rapporté Petri, Microsoft a déclaré : « Cette vulnérabilité a déjà été entièrement atténuée par Microsoft. Il n’y a aucune action à entreprendre pour les utilisateurs de ce service. » C’est l’avantage du modèle de responsabilité partagée pour l’identité cloud — le fournisseur peut corriger une faille sur chaque locataire d’un coup — mais c’est aussi le compromis : les clients dépendent entièrement du fournisseur à la fois pour trouver et pour corriger les bugs les plus profonds de la couche qu’ils ne peuvent toucher.
Publicité
Ce que cela signifie pour les équipes de sécurité s’appuyant sur l’identité cloud
1. Cartographiez votre rayon d’impact d’identité avant le prochain 10 parfait
Inventoriez exactement ce qui fait confiance à votre fournisseur d’identité cloud — chaque application SaaS, chaque charge de travail Azure, chaque tiers fédéré. Vous ne pouvez pas corriger une faille côté fournisseur, mais vous pouvez savoir, à l’avance, ce qu’une compromission hypothétique de la couche d’identité exposerait, afin que si la prochaine divulgation est exploitée dans la nature, vous puissiez raisonner sur l’impact en minutes plutôt qu’en jours.
2. Ne laissez pas « aucune action client requise » devenir « aucune conscience client »
Une correction côté serveur signifie que vous n’avez rien à installer, mais cela ne signifie pas que vous devriez ignorer la divulgation. Enregistrez la CVE, notez le service affecté, et confirmez que votre surveillance ferait remonter un comportement anormal dans le plan d’identité — émission inhabituelle de jetons, octrois de consentement administrateur inattendus, connexions depuis des lieux impossibles — car ce sont les signaux qui comptent lorsque les contrôles propres du fournisseur sont la dernière ligne.
3. Vérifiez vous-même le statut « exploité » avant de déclencher une réponse d’urgence
Le drapeau d’exploitation basculé sur la CVE-2026-69836 rappelle que les champs des avis fournisseurs peuvent être erronés à la première publication. Intégrez une étape de vérification rapide dans votre procédure de réponse aux vulnérabilités : recoupez le bulletin fournisseur avec le catalogue national pertinent de vulnérabilités exploitées et des rapports indépendants avant de consommer une fenêtre de changement d’urgence, afin qu’une erreur d’étiquetage ne vous coûte pas un week-end.
La leçon structurelle : la concentration est la surface d’attaque moderne
La CVE-2026-69836 était, selon Microsoft, un quasi-accident — trouvée en interne, notée au maximum, et corrigée avant que quiconque ne l’exploite. La leçon plus durable ne porte pas sur ce seul bug mais sur l’architecture qui le rend important. La même consolidation qui rend l’identité cloud efficace — un fournisseur émettant les jetons pour tout un parc — concentre aussi le risque dans un composant que les clients ne peuvent ni inspecter ni corriger. Lorsque ce composant obtient un score CVSS parfait, la seule chose qui sépare « atténué sans action requise » d’une brèche catastrophique est la rapidité et la diligence du fournisseur lui-même. Pour les responsables de la sécurité, la conclusion est de traiter les fournisseurs d’identité comme la dépendance la plus précieuse du parc : exigez de la transparence sur leur gestion des vulnérabilités, comprenez précisément la ligne de responsabilité partagée, et construisez des plans de surveillance et de réponse qui supposent que la couche d’identité est à la fois indispensable et, occasionnellement, la chose même qui est en danger.
Questions Fréquemment Posées
Qu’est-ce que la CVE-2026-69836 et quelle est sa gravité ?
La CVE-2026-69836 est une vulnérabilité d’exécution de code à distance dans Microsoft Entra ID, divulguée le 21 août 2026. Elle porte un score CVSS de 10.0 — le maximum — car elle pourrait permettre à un attaquant non authentifié d’exécuter du code sur le réseau sans interaction utilisateur. La cause racine était une désérialisation non sûre de données non fiables.
Les clients doivent-ils faire quelque chose pour la corriger ?
Non. Comme Entra ID est un service cloud exploité par Microsoft plutôt qu’un logiciel que les clients installent, Microsoft a atténué la vulnérabilité côté serveur sur tous les locataires. Microsoft a déclaré que la faille « a déjà été entièrement atténuée » et qu’« il n’y a aucune action à entreprendre pour les utilisateurs de ce service ». Microsoft a également confirmé qu’elle n’a pas été exploitée dans la nature.
Pourquoi une faille dans Entra ID est-elle plus grave qu’une faille dans une seule application ?
Entra ID est le service d’identité cloud de Microsoft qui vérifie les connexions et contrôle l’accès à Microsoft 365, Azure et aux applications tierces connectées. Parce que tant d’applications lui font confiance pour authentifier les utilisateurs, une compromission de la couche d’identité pourrait se propager à tout ce qui en dépend — contrairement à une faille dans une seule application, qui reste confinée à cette application.
Sources et lectures complémentaires
- Microsoft patches critical Entra ID vulnerability (CVE-2026-69836) — Help Net Security
- Microsoft Patches Severe Entra ID Flaw (CVSS 10.0) Allowing Remote Code Execution — The Hacker News
- Microsoft sounds alarm as perfect-10 Entra ID flaw — The Register
- Microsoft Fixes Critical Entra ID Remote Code Execution Flaw — Petri













