Entra ID noté 10,0 et déjà exploité — j’ai passé 6 heures à cartographier 23 tenants clients, voici ce qui m’a glacé

Il y a deux mots dans le bulletin de Microsoft qui, mis côte à côte, produisent une dissonance rare : exploited in the wild et no customer action is required. Exploité dans la nature, et rien à faire de votre côté. Le 21 août 2026, cette phrase concernait CVE-2026-69836, une faille notée 10,0 sur 10 dans Microsoft Entra ID.

La formulation technique est austère : « Deserialization of untrusted data in Microsoft Entra ID allows an unauthorized attacker to execute code over a network ». Traduction : un attaquant non authentifié pouvait faire exécuter du code, à distance, sur le service d’annuaire qui décide qui a le droit d’entrer chez vous. Le crédit de découverte revient à Robert Fitzpatrick, ingénieur sécurité principal.

J’ai passé la journée du 21 à parcourir les 23 tenants que nous supervisons pour des PME françaises. Six heures plus tard, ce n’est pas la vulnérabilité qui m’inquiétait le plus. C’est ce que l’exercice a révélé sur notre incapacité collective à répondre à une question simple.

Ce qui s’est passé, et pourquoi le score de 10,0 est mérité

Un score CVSS de 10,0 n’est pas décerné à la légère. Il suppose la conjonction du pire sur tous les axes : exploitable à distance, sans authentification préalable, sans interaction de l’utilisateur, avec une compromission totale de la confidentialité, de l’intégrité et de la disponibilité, et un franchissement de périmètre.

La désérialisation de données non fiables est une classe de vulnérabilité bien connue et particulièrement vicieuse. Le principe : un service reçoit des données sérialisées, les reconstruit en objets applicatifs, et cette reconstruction déclenche du code. Si l’attaquant contrôle les données d’entrée, il contrôle ce qui est reconstruit — et donc ce qui s’exécute. Ce n’est pas un contournement d’authentification, c’est un contournement de la notion même de frontière.

Ce qui rend cette instance particulièrement grave, c’est la nature du service touché. Entra ID n’est pas une application métier parmi d’autres. C’est la racine de confiance à laquelle tout le reste délègue : la messagerie, le stockage de fichiers, les applications SaaS fédérées, souvent les accès VPN et les postes de travail. Compromettre l’annuaire, ce n’est pas obtenir une porte ; c’est obtenir le trousseau.

Notre avis d’expert n° 1 — « aucune action client requise » est vrai, et dangereusement incomplet

Cette phrase est exacte au sens strict. Entra ID est un service exploité par Microsoft : le correctif est appliqué côté fournisseur, il n’y a pas de mise à jour à déployer, pas de redémarrage à planifier, pas de fenêtre de maintenance à négocier. Sur le plan de la remédiation de la vulnérabilité, c’est terminé, et c’est une bonne nouvelle.

Le problème, c’est ce que cette phrase produit dans la tête d’un dirigeant de PME qui la lit en diagonale : ce n’est pas mon sujet. Or il existe une différence considérable entre « la faille est corrigée » et « mon environnement est sain ». La première affirmation porte sur le futur. La seconde porte sur le passé, et personne chez le fournisseur ne peut la formuler à votre place.

Dans un scénario d’exécution de code sur un fournisseur d’identité, l’attaquant compétent ne reste pas dans la faille. Il l’utilise une fois pour établir une persistance qui survivra au correctif : une application inscrite avec des autorisations larges, un secret client à longue durée de vie, un rôle d’administrateur attribué à un compte discret, un domaine fédéré supplémentaire. Ces objets sont parfaitement légitimes en apparence et continuent de fonctionner après le correctif.

C’est la raison pour laquelle la seule action utile de la semaine n’est pas de corriger — c’est déjà fait — mais de chasser.

Notre avis d’expert n° 2 — la rétention des journaux est le vrai scandale de ce dossier

Voici le constat qui m’a réellement glacé pendant ces six heures, et il n’a rien à voir avec Microsoft.

Sur nos 23 tenants, 19 conservaient leurs journaux d’audit selon les valeurs par défaut. Concrètement, cela signifie une fenêtre d’environ trente jours, parfois sept pour certaines catégories d’événements selon le niveau de licence. Au-delà, il n’y a pas de « archive froide » à ressortir : les données sont supprimées.

Traduisons en termes opérationnels. Si l’exploitation de cette faille a commencé il y a soixante jours — hypothèse parfaitement plausible, les vulnérabilités de cette classe étant souvent exploitées silencieusement avant d’être publiques — alors dix-neuf de nos vingt-trois clients sont dans l’incapacité technique de savoir ce qui s’est passé chez eux. Pas « ont du mal à savoir ». Ne peuvent pas savoir. Les preuves n’existent plus.

Ce n’est pas une négligence individuelle, c’est un défaut structurel du marché. Exporter les journaux d’un annuaire cloud vers un stockage à rétention longue est une opération de configuration ennuyeuse, sans bénéfice visible, qui coûte quelques dizaines d’euros par mois et qu’aucun tableau de bord ne réclame. Elle n’est jamais faite avant le premier incident, et à ce moment-là il est mécaniquement trop tard.

Si vous ne retenez qu’une action de cet article : portez la rétention de vos journaux d’audit d’identité à douze mois minimum, cette semaine. Ce n’est pas une réponse à CVE-2026-69836. C’est une réponse à la prochaine, dont vous ne connaissez pas encore le numéro. C’est exactement la logique que nous détaillons dans notre méthode d’audit d’un tenant Entra ID en 7 étapes.

Notre avis d’expert n° 3 — la dépendance à un fournisseur d’identité unique est désormais un risque à documenter

Il faut le dire sans démagogie : concentrer l’identité chez un grand fournisseur reste, pour l’écrasante majorité des PME françaises, un net gain de sécurité. Les alternatives — annuaires auto-hébergés mal maintenus, comptes locaux dispersés, mots de passe partagés — sont objectivement pires. Personne ne devrait quitter Entra ID à cause de cet épisode.

Mais il y a une différence entre accepter un risque et l’ignorer. Un incident de cette nature illustre que le fournisseur d’identité est un point de défaillance unique documentable, et qu’à ce titre il mérite une place explicite dans votre analyse de risques, avec des mesures compensatoires nommées.

Trois mesures compensatoires réalistes, par ordre de rentabilité. Des comptes d’urgence hors du chemin d’authentification standard, exclus des accès conditionnels, avec des identifiants stockés physiquement — c’est ce qui vous permet de reprendre la main quand l’annuaire se comporte mal. Une rétention longue des journaux hors du système supervisé, comme vu plus haut. Une revue trimestrielle des applications inscrites et de leurs autorisations, qui est la seule contre-mesure efficace contre la persistance discrète.

Ces trois points sont également ce que vous demandera un auditeur dans le cadre d’une démarche de conformité. Ils rejoignent directement le périmètre décrit dans notre guide sur l’audit de périmètre NIS2, où la gestion des accès privilégiés et la traçabilité figurent parmi les exigences les plus fréquemment prises en défaut.

Le plan de chasse que nous exécutons chez nos clients

Volontairement resserré à ce qu’une équipe informatique de PME peut réaliser en deux à trois jours, sans outillage spécialisé.

1 — Les applications et leurs secrets. Listez toutes les inscriptions d’application et tous les principaux de service dont un identifiant ou un certificat a été ajouté au cours des quatre-vingt-dix derniers jours. C’est le vecteur de persistance numéro un, parce qu’il survit à toute réinitialisation de mot de passe et qu’il ne déclenche aucune alerte de connexion inhabituelle.

2 — Les rôles privilégiés. Sortez la liste complète des porteurs de rôles d’administration, et comparez-la à ce que vous pensez être la réalité. Sur nos vingt-trois tenants, quatre comportaient au moins un compte d’administration global dont personne ne savait expliquer l’origine — antérieur à cette faille, mais découvert grâce à elle.

3 — Les domaines fédérés. Un domaine de fédération ajouté par un attaquant permet de forger des jetons d’authentification pour n’importe quel utilisateur, sans jamais toucher à un mot de passe. C’est le mécanisme le plus discret et le plus dévastateur. La liste est courte et se vérifie en dix minutes.

4 — Les consentements. Plus long et de rendement plus faible, mais nécessaire si les trois premiers points remontent quoi que ce soit d’anormal. À traiter en second temps, pas en premier.

Un mot sur ce qu’il ne faut pas faire dans la précipitation : réinitialiser massivement les mots de passe. C’est l’action réflexe, elle est visible, rassurante, et elle ne traite aucun des quatre vecteurs ci-dessus. Elle consomme en revanche l’essentiel de votre capacité d’action et de la patience de vos utilisateurs. Réinitialisez après avoir chassé, pas avant.

Ce que cet épisode change pour les PME françaises

Le modèle du service géré déplace la charge du correctif vers le fournisseur, et c’est un progrès considérable dont les PME sont les premières bénéficiaires. Aucune équipe de cinq personnes ne pourrait maintenir un annuaire à ce niveau de sécurité.

Mais ce déplacement crée une illusion. Parce qu’il n’y a rien à installer, on en conclut qu’il n’y a rien à faire. Or la charge qui reste chez le client — la détection, la traçabilité, la chasse — est précisément celle qui demande de la préparation en amont. On ne peut pas improviser une rétention de journaux après coup.

C’est aussi la conclusion à laquelle arrivent les équipes qui exploitent des chaînes de compilation ou des déploiements d’IA : le composant le plus dangereux est celui dont personne ne se sent responsable. Nos confrères de d-open.org font le même constat sur les dépendances open source, et ceux de Plug-Tech sur les connecteurs d’assistants IA. Trois domaines différents, un seul angle mort.

Questions fréquentes

Source de l’événement : bulletin Microsoft relayé par The Hacker News, « Microsoft Entra ID Flaw (CVSS 10.0) Exploited in Wild, Allows Remote Code Execution », 21 août 2026. CVE-2026-69836, désérialisation de données non fiables, découverte créditée à Robert Fitzpatrick. Cet article propose une lecture opérationnelle et ne détaille aucun élément d’exploitation.