Vulnérabilité Entra Provisioning Service CVE-2026-59115 : deux failles critiques d'élévation de privilèges dans SyncFabric

Qu'est-ce que la vulnérabilité Entra Provisioning Service CVE-2026-59115

Cet article propose une analyse technique de la vulnérabilité Entra Provisioning Service CVE-2026-59115, une faille critique d'élévation de privilèges divulguée par Microsoft le 6 août 2026 dans Microsoft Entra Provisioning Service — également connu sous le nom de SyncFabric, le moteur cloud qui crée, met à jour et supprime les identités sur Entra ID, les sources RH, les applications SaaS connectées via SCIM, et les cibles de synchronisation inter-tenants. Il s'agit de la deuxième faille critique d'élévation de privilèges découverte dans ce même composant en cinq semaines : CVE-2026-57100, un problème connexe de falsification de requête côté serveur (SSRF), a été corrigé discrètement lors du cycle de mises à jour de juillet 2026 de Microsoft.

Aucune des deux CVE n'a nécessité d'article KB ni de correctif à déployer côté client — les deux ont été corrigées côté service, car Entra Provisioning Service s'exécute entièrement dans le cloud de Microsoft. Mais « pas de correctif à déployer » ne signifie pas « rien à vérifier ». Cet article couvre ce qui est publiquement confirmé sur les deux failles, à quoi ressemble réellement la détection pour un service hébergé par Microsoft que vous ne pouvez pas instrumenter directement, et les mesures de durcissement concrètes qui réduisent votre exposition, quelle que soit la suite des divulgations de Microsoft.

Comment fonctionnent les deux vulnérabilités SyncFabric

Les deux CVE résident dans le même composant et partagent un intitulé MSRC identique — « permet à un attaquant autorisé d'élever ses privilèges via le réseau » — mais il s'agit de deux classes de bugs distinctes.

Sources : NVD — CVE-2026-59115, NVD — CVE-2026-57100, GitHub Advisory Database — GHSA-w2pm-fvgr-6r6g, Tenable — CVE-2026-57100.

CVE-2026-59115 est une faille de traversée de chemin (path traversal). Le motif de séquence .../...// derrière la CWE-35 décrit une entrée qui se résout vers un emplacement situé hors d'un répertoire restreint. Dans un pipeline de provisioning qui lit et écrit des objets d'identité à travers des frontières de confiance — annuaire source, moteur de synchronisation, application cible — une primitive de traversée non bornée constitue une voie d'élévation de privilèges, pas seulement un bug de divulgation de fichiers : elle est notée S:C (changement de périmètre), ce qui signifie qu'une exploitation réussie peut affecter des ressources au-delà du composant vulnérable lui-même. À l'heure de la rédaction, l'avis de Microsoft ne publie ni méthode d'attaque, ni liste des builds affectés, ni numéro KB, ni recommandations d'atténuation au-delà du simple vecteur CVSS — une lacune relevée indépendamment par plusieurs observateurs (Windows Forum). La NVD n'a pas non plus encore publié sa propre évaluation CVSS indépendante pour cette CVE — le score affiché sur sa fiche est la notation CNA de Microsoft, pas une réévaluation NVD.

CVE-2026-57100 est une falsification de requête côté serveur (SSRF) : le service de provisioning, agissant pour le compte de l'attaquant, peut être contraint d'émettre des requêtes choisies par ce dernier. La notation CNA propre à Microsoft (9.9, périmètre modifié) et la réévaluation indépendante de la NVD (8.8, périmètre inchangé) divergent sur la question de savoir si la faille franchit une frontière de sécurité — un écart de notation qui apparaît lorsque le rayon d'impact d'un SSRF dépend d'une topologie de service interne que la NVD ne peut pas vérifier intégralement à partir de l'avis public. Les deux notations s'accordent sur le fait que la faille est exploitable via le réseau avec une faible complexité d'attaque et sans interaction utilisateur, ne différant que sur le rayon d'impact. La couverture du Patch Tuesday de juillet par Microsoft confirme que le correctif a été « entièrement atténué sur l'infrastructure de Microsoft, et qu'aucune action client n'est requise » (CrowdStrike).

Ce que signifie « attaquant autorisé » ici

Les deux failles requièrent PR:L — les avis de Microsoft décrivent l'acteur comme un « attaquant autorisé », ce qui n'équivaut pas à un « utilisateur anonyme d'Internet ». Cela signifie que le point de départ est un accès de base préexistant au tenant cible ou à sa configuration de provisioning : un compte utilisateur peu privilégié mais compromis, un administrateur délégué disposant de droits de provisioning restreints, ou des identifiants appartenant à un principal de service qui dialogue déjà avec le pipeline de provisioning. C'est un modèle de menace nettement différent d'un exploit distant non authentifié — l'accent est mis sur la rigueur avec laquelle vous contrôlez qui et quoi détient un accès lié au provisioning en premier lieu, ce qui est précisément l'objet des mesures de remédiation ci-dessous. Ni l'avis de l'éditeur ni les observateurs consultés pour cet article ne signalent de preuve d'exploitation active pour l'une ou l'autre CVE à l'heure de la rédaction.

Détection

Voici la partie inconfortable : SyncFabric est un service cloud exploité par Microsoft, pas un rôle Windows Server sur lequel vous pouvez déployer un agent EDR ou une configuration Sysmon. Il n'existe aucun ID d'événement côté Entra, aucune requête Sentinel ni aucun IOC publié pour l'une ou l'autre CVE, parce que le code vulnérable ne s'exécute pas dans votre tenant — il s'exécute chez Microsoft. Toute recommandation de détection prétendant se déclencher spécifiquement sur l'exploitation de CVE-2026-59115 ou CVE-2026-57100 inventerait un signal qui n'existe pas dans le registre public.

Ce que vous pouvez faire, c'est renforcer la supervision autour du rayon d'impact du pipeline de provisioning, puisque PR:L signifie que l'attaque part d'un accès dont vous contrôlez l'attribution :

(Sources : Journaux de provisioning Microsoft Entra, référence des activités des journaux d'audit.)

Les journaux de provisioning sont conservés 30 jours sur un tenant premium (7 jours sur un tenant gratuit) — routez-les vers Azure Monitor / Log Analytics via les paramètres de diagnostic si vous avez besoin d'une rétention plus longue ou souhaitez générer des alertes. Vous pouvez interroger directement l'activité de provisioning via Microsoft Graph :

GET https://graph.microsoft.com/v1.0/auditLogs/provisioning?$filter=provisioningStatusInfo/status eq 'failure'&$orderby=activityDateTime desc&$top=50

Synchronisation inter-tenants et provisioning B2B

Le même moteur SyncFabric pilote également la synchronisation inter-tenants de Microsoft Entra — la fonctionnalité qui provisionne automatiquement les identités invitées depuis un tenant partenaire. Selon la documentation de Microsoft elle-même, les modifications de configuration de la synchronisation inter-tenants apparaissent dans les journaux d'audit sous la même catégorie ProvisioningManagement que le provisioning d'application classique, tandis que les événements de création/mise à jour/suppression des comptes invités synchronisés eux-mêmes se retrouvent dans les journaux de provisioning. Si votre tenant utilise la synchronisation inter-tenants, la même revue des permissions de connecteur détaillée dans la section Remédiation ci-dessous s'y applique — il s'agit du même service sous-jacent, seul l'appariement source/cible diffère.

Remédiation

1. Inventoriez qui et quoi est « autorisé » vis-à-vis de votre configuration de provisioning. PR:L signifie que le point de départ des deux CVE est un privilège déjà existant — un rôle d'administration, une permission déléguée, ou un principal de service compromis disposant de droits sur les jobs de provisioning. Passez en revue l'appartenance aux rôles pouvant lire ou modifier la configuration de provisioning (Hybrid Identity Administrator, Application Administrator, et tout rôle personnalisé disposant de permissions sur la configuration de provisioning) — y compris les comptes d'accès d'urgence break-glass, qui portent souvent un privilège permanent étendu par conception et sont faciles à oublier dans une revue ciblée comme celle-ci.
2. Placez les rôles d'administration liés au provisioning derrière PIM, plutôt qu'en attribution permanente, afin qu'un compte compromis n'obtienne pas un accès durable au pipeline de provisioning. PIM nécessite une licence Entra ID P2 — voir les fonctionnalités d'Azure AD Premium P2 si vous n'êtes pas certain qu'elle soit activée — et comment auditer la sécurité de Microsoft Entra ID pour une checklist de revue plus large couvrant Conditional Access et PIM.
3. Vérifiez le ou les principaux de service qui portent vos connecteurs de provisioning — provisioning piloté par la RH, applications SCIM, synchronisation inter-tenants — à la recherche d'identifiants excessifs, de secrets obsolètes ou d'attributions de rôle de niveau admin. Un bug SSRF ou de traversée de chemin dans le chemin de provisioning est plus dangereux lorsque l'identité même du connecteur est sur-privilégiée.
4. Diffusez les journaux de provisioning et d'audit vers Log Analytics si ce n'est pas déjà fait, afin de disposer de plus de 30 jours d'historique la prochaine fois qu'un avis de ce type sera publié.
5. Suivez directement l'avis MSRC pour CVE-2026-59115. Microsoft n'ayant pas encore publié de liste des configurations affectées ni de recommandations d'atténuation, revérifiez la page de l'avis elle-même plutôt que de vous fier à un instantané — plusieurs observateurs ont signalé cette lacune, qui pourrait être comblée après la publication initiale.

Si vous utilisez un provisioning piloté par la RH ou inter-tenants

La revue de l'étape 3 compte davantage, pas moins, pour le provisioning piloté par la RH (Workday, SuccessFactors) et les connecteurs de synchronisation inter-tenants, car ils s'exécutent en général, par conception, avec des droits étendus de création/mise à jour/suppression sur l'ensemble de votre population d'utilisateurs. Confirmez que les identifiants du connecteur sont restreints aussi étroitement que l'intégration le permet, faites tourner tout jeton porteur ou secret client antérieur à cette fenêtre de divulgation, et — spécifiquement pour la synchronisation inter-tenants — passez en revue vos politiques de rédemption automatique entrante et sortante afin qu'un événement de provisioning d'invité inattendu ne passe pas inaperçu.

Comment EtcSec détecte cela

EtcSec ne voit pas davantage que vous à l'intérieur du service SyncFabric de Microsoft — mais il vérifie en continu les deux éléments qui déterminent l'ampleur des dégâts qu'un « attaquant autorisé » peut causer si l'une de ces CVE, ou la prochaine dans ce même composant, se transforme en exploit fonctionnel : si des principaux de service détiennent des rôles de niveau admin (PA_SERVICE_PRINCIPAL_ADMIN) et si des rôles privilégiés — y compris ceux disposant de permissions liées au provisioning — se trouvent en dehors de PIM avec une attribution permanente (PA_PIM_NOT_ENABLED). Resserrer ces deux points réduit l'écart entre « un attaquant obtient un point d'ancrage » et « un attaquant escalade à travers le pipeline de provisioning ».