Alerte d'abus nOAuth : Prise de contrôle totale des comptes des applications SaaS d'Entra Cross-Tenant

Principales conclusions

• En testant 104 applications, Semperis en a trouvé 9 (soit environ 9 %) qui étaient vulnérables aux abus de nOAuth.
• Comme l'abus a déjà été divulgué, la capacité d'effectuer des nOAuth est peu complexe.
• L'abus de nOAuth exploite les vulnérabilités entre locataires et peut conduire à l'exfiltration, à la persistance et au déplacement latéral des données des applications SaaS.
• Les abus sont difficiles à détecter pour les utilisateurs d'applications vulnérables et il leur est impossible de se défendre contre ces abus.
• Les chercheurs de Semperis considèrent cette vulnérabilité comme potentiellement SEVERE en raison de la faible complexité de l'attaque et de la difficulté de la détection et de la défense.

La vulnérabilité nOAuth expose une faille d'authentification critique dans les applications SaaS (Software-as-a-Service) vulnérables. Avec seulement l'accès à un locataire Entra - une barrière faible - et l'adresse électronique de l'utilisateur cible, un attaquant peut prendre le contrôle du compte de cet utilisateur dans l'application vulnérable. De là, le pirate peut accéder à toutes les données auxquelles la cible a accès dans cette application.

Nous avons rapidement fait part de nos conclusions aux fournisseurs d'applications et au Microsoft Security Response Center (MSRC) en décembre 2024 ; le MSRC a accusé réception du rapport et a ouvert le dossier 93209. En mars 2025, nous avons notifié au CSEM notre intention de divulguer. Le CSEM a clôturé le dossier en avril 2025. En mai et juin 2025, nous avons continué à contacter les fournisseurs d'applications qui étaient vulnérables et avons partagé les détails avec le CSEM. En juin 2025, nous avons reçu un retour du CSEM réitérant que les vendeurs devaient suivre les recommandations et que ceux qui ne le faisaient pas étaient susceptibles d'être retirés de l'Entra App Gallery.

Il est difficile, voire impossible, de détecter une attaque utilisant abusivement nOAuth. Les clients ne disposent d'aucune option de remédiation ou d'atténuation, si ce n'est de demander aux fournisseurs d'applications des mises à jour pour rendre les applications invulnérables à l'abus de nOAuth. En raison de la simplicité de cet abus, de la complexité de la détection et de l'existence d'applications activement vulnérables, Semperis considère cette vulnérabilité comme un risque grave pour les clients d'Entra ID.

Cet article détaille l'exploration de nOAuth par l'équipe de recherche en sécurité de Semperis, qui s'est concentrée sur les applications de la Microsoft Entra App Gallery. Nous avons découvert neuf applications vulnérables, y compris celles qui pourraient contenir des informations personnelles identifiables (PII).

Qu'est-ce que nOAuth ?

Le 20 juin 2023, Omer Cohen de Descope a publié la communication "nOAuth : How Microsoft OAuth Misconfiguration Can Lead to Full Account Takeover" (nOAuth : comment la mauvaise configuration de Microsoft OAuth peut conduire à la prise de contrôle totale d'un compte). Le problème fondamental qui conduit à nOAuth est l'utilisation par les développeurs d'applications d'anti-modèles relatifs à la mise en œuvre d'OpenID Connect (OIDC). Ces anti-modèles comprennent l'utilisation d'attributs mutables, tels qu'une adresse électronique, pour les identifiants d'utilisateur. Entra ID permettant aux utilisateurs d'avoir une adresse électronique non vérifiée, l'utilisation de cet attribut permet d'usurper l'identité d'un utilisateur au-delà des limites d'un locataire. Dans la divulgation de Descope, il est décrit que l'attaque se situe dans une "zone grise" dans Entra ID, en raison de la dépendance des développeurs à suivre des anti-modèles. Bien que nous soyons d'accord avec cela, cela laisse les clients mutuels de Microsoft et du fournisseur d'applications SaaS (ISV) vulnérables à cet abus.

En réponse à la découverte de M. Cohen, le CSEM a publié un article sur les risques liés à l'utilisation de nOAuth : "Potential Risk of Privilege Escalation in Azure AD Applications" (Risque potentiel d'escalade des privilèges dans les applications Azure AD). Dans le cadre de la déclaration d'impact sur les clients de Microsoft, cet article indiquait ce qui suit :

Microsoft a identifié plusieurs applications multi-locataires dont les utilisateurs utilisent une adresse électronique dont le propriétaire du domaine n'a pas été vérifié. Bien que les adresses électroniques non vérifiées ne présentent pas de risque pour les applications qui n'utilisent pas de réclamations par courrier électronique à des fins d'autorisation, les propriétaires de ces applications ont été informés et ont reçu des conseils sur la manière de modifier leurs applications, le cas échéant. Si vous n'avez pas reçu de notification, c'est que votre application n'a pas consommé de réclamations par courrier électronique avec des propriétaires de domaines non vérifiés. Pour protéger les clients et les applications susceptibles d'être vulnérables à l'escalade des privilèges, Microsoft a déployé des mesures d'atténuation afin d'omettre les réclamations de jetons provenant de propriétaires de domaines non vérifiés pour la plupart des applications.

Déclaration d'impact sur les clients de Microsoft

Microsoft a également publié des conseils spécifiques sur l'abandon de l'utilisation des réclamations par courrier électronique. À l'heure où nous écrivons ces lignes, cet article n'est plus disponible sur le site de Microsoft, bien que vous puissiez en trouver une version archivée ailleurs.

Comment fonctionne l'abus de nOAuth ?

L'abus de nOAuth nécessite trois composants :

• La possibilité de définir une adresse électronique non vérifiée dans Entra ID
• Une inscription à l'application qui permet de revendiquer un courriel non vérifié
• Vulnérabilité d'une application à cette combinaison

Prenons un exemple de ce type d'abus.

Définition d'une adresse électronique non vérifiée dans Entra ID

Les services Entra ID et Microsoft 365 incluent un locataire par défaut avec un nom de domaine onmicrosoft.com, tel que contoso.onmicrosoft.com. Lorsque les organisations configurent leurs déploiements et embarquent leurs propres noms de domaine pour les services, le processus de vérification utilise un enregistrement TXT ou MX pour vérifier la propriété du domaine. Une fois vérifié, le nom de domaine est marqué comme tel dans Entra ID(Figure 1).

Pour supporter la fonctionnalité d'utilisateur invité dans Entra ID, cependant, le suffixe de domaine de l'attribut email n'a pas besoin d'être un domaine vérifié. Par conséquent, n'importe quel utilisateur de n'importe quel locataire Entra peut avoir n'importe quelle adresse email dans l'attribut mail.

Par exemple, la figure 2 montre un utilisateur, Adele Vance, dont l'attribut mail a la même valeur que l'attribut userPrincipalName.

Nous pouvons exécuter un simple PATCH pour modifier cet attribut de courrier(Figure 3).

Un autre GET montre qu'Adele a maintenant une adresse électronique pour un domaine qui n'est pas vérifié dans ce locataire(Figure 4).

Vérification d'un changement d'adresse électronique

Si nous voulons valider l'adresse électronique non vérifiée en tant que réclamation dans un jeton d'identification, nous pouvons configurer un enregistrement d'application dans Entra ID avec un URI de redirection de https://jwt.ms et lui transmettre le jeton d'identification.

Pour les enregistrements d'applications créés après juin 2023, par défaut, Entra ID n'émet pas de réclamation de courriel non vérifié. Pour modifier la configuration afin de permettre cela, nous pouvons utiliser un simple PATCH sur l'authenticationBehavior pour l'enregistrement de l'application, en définissant removeUnverifiedEmailClaim à false (Figure 5). Ce processus est documenté par Microsoft dans l'article "Manage application authenticationBehaviors".

Une fois notre enregistrement d'application configuré, nous pouvons l'utiliser pour reproduire le comportement d'une application vulnérable et afficher le jeton d'identification(Figure 6).

Si ce jeton d'identification est consommé par une application qui utilise l'adresse électronique comme identifiant unique, l'application ne saura pas que l'utilisateur n'est pas, en fait, l'utilisateur légitime.

Atténuer les abus de nOAuth

Comme nous l'avons vu, pour limiter les abus de nOAuth, il faut que le développeur mette correctement en œuvre l'authentification afin de garantir un identifiant unique et immuable.

Pam Dingle, directrice des normes d'identité chez Microsoft, a publié un article peu après la divulgation de nOAuth sur les anti-modèles des développeurs. Il vaut la peine d'être lu : "The False Identifier Anti-pattern".

Comme le souligne Pam dans son article, conformément à la section 5.7 de la spécification OpenID Connect, la combinaison des déclarations de l'émetteur(iss) et du sujet(sub) est le seul moyen pour une application(SP) de garantir un identifiant d'utilisateur unique et stable.

Dans Entra ID, l'émetteur(iss) est émis sous la forme d'un URI d'émetteur qui inclut l'identifiant du locataire, qui est unique au niveau mondial(figure 7).

Le sujet(sub) est un identifiant par paire qui est unique à chaque utilisateur pour chaque ID d'application(figure 8). Tout aussi important, sub est une valeur immuable dans Entra ID. Entra ID n'autorise aucune sorte de transformation ou de modification de la revendication en question, ce qui garantit son caractère unique.

Les détails sur les revendications d'un jeton d'identification émis par Entra ID peuvent être trouvés ici : "Référence des revendications relatives aux jetons d'identification".

Changements apportés par Microsoft pour limiter les abus de nOAuth

Dans Entra ID, Microsoft a apporté des modifications afin que tout enregistrement d'application créé après juin 2023 n'émette pas, par défaut, de réclamation d'email si l'adresse email n'est pas vérifiée. Bien entendu, des milliers et des milliers d'applications SaaS existent depuis avant juin 2023, et de nombreux développeurs veulent et doivent encore consommer l'adresse électronique ; de nombreuses applications SaaS veulent envoyer des courriels aux utilisateurs finaux, et la consommation par le biais d'une réclamation est le moyen le plus simple d'obtenir cette information.

Pour aider les développeurs, Microsoft a également introduit la déclaration facultative xms_edov, qu'un développeur peut utiliser pour déterminer si une adresse électronique est vérifiée. Cependant, au moment de rédiger cet article, l'allégation xms_edov semble être dans un état d'incertitude, ce qui amène à se demander si elle n'est pas en train d'être dépréciée. Bien que les documents Microsoft indiquent que l'allégation est facultative, elle n'est plus disponible dans l'interface utilisateur permettant de définir des allégations facultatives. La définition de xms_edov en tant qu'allégation facultative par l'intermédiaire de l'API graphique fonctionne, mais un message vous indique ensuite qu'il ne s'agit pas d'une allégation facultative valide(figure 9).

En pratique, un dev pourrait utiliser ces informations pour décider si l'adresse électronique d'un utilisateur est vérifiée dans le locataire(figure 10).

La nouvelle recherche de Semperis sur l'abus de nOAuth

L'accent Descope

Dans l'étude publiée par Descope, l'accent est mis sur les applications SaaS qui prennent en charge plusieurs fournisseurs d'identité, tels que Google et Microsoft, Facebook, etc.(figure 11).

Pour des raisons de convivialité, les applications SaaS sont généralement dotées d'une logique de fusion des comptes. Par exemple, si je m'inscris à Medium avec un compte Facebook et que je me connecte ensuite avec mon compte Google, les deux sources d'authentification m'amènent en fin de compte au même compte Medium.

Le problème exploré par Descope était que, comme tout compte d'utilisateur dans Entra ID pouvait porter la mention de l'adresse électronique, les développeurs qui fusionnaient sur la base de l'adresse électronique pouvaient, sans le savoir, permettre à un pirate d'accéder au compte d'un utilisateur cible.

Au-delà de certaines capacités mises en œuvre par Microsoft, Descope a recommandé que les applications SaaS qui prennent en charge la fonctionnalité de fusion de comptes interrompent le flux la première fois qu'une connexion est tentée avec une source de compte différente, en utilisant une fonction pour valider la propriété de l'e-mail. Nous sommes d'accord avec ce conseil. Cette fonction peut prendre la forme d'un lien magique par courriel, où l'utilisateur reçoit un courriel lui demandant de vérifier la propriété avant que la fusion n'ait lieu.

Lors de nos propres recherches, nous avons constaté qu'il s'agissait d'une pratique de sécurité courante parmi les applications qui s'avéraient invulnérables aux abus de nOAuth.

Recherche Semperis

À la fin de l'automne 2024, dans le cadre d'une recherche exploratoire, nous avons examiné la recherche effectuée par Descope et avons décidé de la tester avec quelques applications SaaS. Cela a coïncidé avec l'idée d'explorer la Microsoft Entra App Gallery. L'Entra App Gallery est un portail au sein d'Entra ID que Microsoft gère et qui permet à des fournisseurs SaaS tiers de faire apparaître des applications qui s'intègrent à Entra ID(Figure 12).

Dans le cadre de nos recherches, nous avons examiné les 1 017 intégrations OIDC disponibles à l'époque et avons trouvé 104 applications qui permettaient de s'inscrire soi-même à l'application. Le marché du SaaS étant fortement concurrentiel, les fournisseurs ont tendance à proposer des niveaux gratuits ou des essais de leurs applications avec peu de friction, ce qui vous permet d'utiliser et de tester l'application sans avoir à passer par des canaux de vente. Nous nous sommes concentrés sur ces applications non seulement parce qu'elles constituaient une barrière peu élevée pour la recherche en matière de sécurité, mais aussi parce qu'elles nous permettaient de rester dans les limites des tests éthiques.

Dans chaque application que nous avons testée, nous avons utilisé un locataire "victime" que nous avons géré pour configurer un compte que nous possédions dans la plateforme. Nous avons ensuite utilisé un autre locataire, le locataire "attaquant", pour tenter d'abuser de nOAuth contre notre propre victime. De cette manière, nous nous sommes assurés que nos tests n'affectaient que les comptes sous notre contrôle et n'accédaient qu'aux échantillons de données de test que nous avions créés.

Notre recherche diffère de celle de Descope en ce sens que nous voulions trouver des applications qui permettaient l'abus de nOAuth entre locataires Entra ID. Essentiellement, le client cible (victime) est un client de Microsoft avec un locataire Entra ID, et l'attaquant utilise un locataire Entra ID différent pour effectuer l'abus. Le diagramme suivant de Descope est valable en ce qui concerne le flux d'attaque dans notre recherche(Figure 13).

Cependant, dans le cadre de notre étude, l'application SaaS ne doit prendre en charge qu'Entra ID pour l'authentification. Bien que presque toutes les applications SaaS que nous avons testées prennent en charge un compte d'utilisateur local, nous avons constaté que certaines applications prenaient également en charge plusieurs fournisseurs d'identité, tels que Google et Entra ID, tandis que d'autres ne prenaient en charge qu'Entra ID.

En outre, nous avons émis l'hypothèse que si une application ne prenait en charge qu'Entra ID pour l'authentification, il était peu probable que le développeur ait mis en œuvre la logique de fusion des comptes et la vérification des courriels que Descope a notées, car le développeur ne s'attendait probablement pas à un scénario de collision des comptes.

Applications vulnérables

En testant 104 applications, nous en avons trouvé 9 qui étaient vulnérables à l'abus de nOAuth ; cela se traduit par une vulnérabilité dans environ 9% des applications testées. Comme 104 n'est qu'une goutte d'eau dans l'océan des applications SaaS qui sont intégrées avec Entra ID, vous pouvez extrapoler ces chiffres sur les dizaines de milliers d'applications SaaS disponibles.

Parmi les applications que nous avons trouvées vulnérables, nous avons noté quelques observations intéressantes concernant la taille, l'échelle et le type d'application. Nous avons trouvé une plateforme de système de gestion des ressources humaines (SGRH) qui, dans la pratique, serait probablement remplie de PII. De même, nous avons trouvé des applications qui s'intégraient à Microsoft 365 pour des tâches telles que l'accès au courrier et au calendrier. Comme ces intégrations utilisent un ensemble différent de combinaisons de jetons d'accès et de rafraîchissement, un attaquant qui réussirait à abuser de nOAuth serait en mesure non seulement d'accéder aux données de l'application SaaS, mais aussi potentiellement de pivoter vers les ressources de Microsoft 365.

Malheureusement, les tests à grande échelle prennent beaucoup de temps. Au-delà de la configuration du locataire Entra pour effectuer l'abus, nous avions besoin d'un œil humain sur l'interface de l'application SaaS pour déterminer si l'attaquant était en mesure d'accéder au compte de la victime. Bien que la plupart des applications invulnérables à cet abus présentaient généralement un nouveau flux d'accueil dans l'application, certaines nous ont simplement fait entrer dans l'écran principal de l'application, nous obligeant à examiner les informations du compte ou à essayer de manipuler les données dans l'application pour déterminer si l'attaquant se trouvait dans le même compte que la victime.

Contacter les parties prenantes

À la suite de ces recherches, nous avons ouvert un dossier auprès du CSEM. Nous avons également tenté de déterminer les parties prenantes de chaque fournisseur de services Internet dont l'application était vulnérable. Après avoir contacté ces parties prenantes, conformément au principe de Semperis d'être une force pour le bien, nous leur avons proposé de les aider à résoudre la vulnérabilité de leur application ; quelques vendeurs ont accepté cette offre. Dans ces cas, nous avons aidé les fournisseurs à comprendre le problème et avons effectué des tests supplémentaires de l'abus de nOAuth contre leur application jusqu'à ce que le problème soit résolu.

Défense des clients : un manque d'options

En fin de compte, la seule défense dont dispose un client contre l'abus de nOAuth est 1) d'exhorter le fournisseur à résoudre le problème ou 2) d'abandonner l'application SaaS.

Parce que l'attaque se produit en dehors du champ de vision de la victime, les mécanismes de défense traditionnels ne peuvent pas fournir de protection. Il s'agit notamment de

• Authentification multifactorielle (MFA) et renforcement de l'authentification dans Entra ID
• Accès conditionnel
• Les solutions Zero Trust Network Access (ZTNA) et Cybersecurity for Any Business (CASB)
• Détection et réponse des points finaux (EDR)
• Détection et réponse étendues (XDR)

Détection des abus de nOAuth

Bien que les solutions de gestion de la sécurité des applications SaaS (SaaS Security Posture Management - SSPM) puissent donner un aperçu des applications SaaS, elles se concentrent généralement sur la configuration et la posture de sécurité exposées aux clients de la plateforme et ne sont pas susceptibles d'indiquer une utilisation abusive de nOAuth. Des problèmes similaires existent avec les plates-formes de navigateur sécurisé d'entreprise et les plug-ins de navigateur, qui peuvent aider à mettre en évidence d'autres portes dérobées dans les applications SaaS, mais ne sont pas susceptibles de mettre en évidence ce type d'attaque.

Malheureusement, cela ne laisse que peu d'options aux clients :

• Corrélation des journaux d'authentification SaaS avec Entra ID au sein d'une plateforme SIEM
• Demander à leurs vendeurs ce qu'ils pensent de nOAuth
• Effectuer soi-même les tests d'abus de nOAuth

Du point de vue d'Entra ID, nous avons examiné les principes de service des applications multi-locataires et n'avons trouvé aucun attribut exposé à un client qui indiquerait que l'application consomme des réclamations de courrier électronique non vérifiées. Même si de tels attributs existaient, il n'y aurait aucun moyen d'indiquer l'usage que l'application fait de cette réclamation.

Corrélation des journaux d'authentification

Pour utiliser la corrélation de logs afin de détecter les abus de nOAuth, vous devez consommer vos logs d'authentification Entra ID dans une solution de gestion d'informations et d'événements de sécurité (SIEM), telle que Microsoft Sentinel. Vous devrez également consommer les journaux d'authentification de votre application SaaS, puis corréler les deux journaux au sein du SIEM. Vous devrez rechercher les événements d'authentification dans la plateforme SaaS avec un événement d'authentification manquant dans Entra ID(Figure 14).

Bien entendu, les résultats de la mise en pratique de cette théorie varieront considérablement. Bien que le sujet(sub) soit l'identifiant clé dans l'application SaaS, cette valeur n'est pas capturée dans les journaux de connexion d'Entra ID lors de l'authentification. Par conséquent, l'application SaaS devrait également contenir des attributs tels que l'UPN ou l'adresse électronique dans ses journaux pour la corrélation. De même, les journaux d'authentification du fournisseur SaaS doivent être disponibles de manière à pouvoir être consommés par un SIEM. D'autres facteurs, tels que la dérive temporelle et la précision, peuvent compliquer la détection des abus de nOAuth par la corrélation des journaux.

Test pour nOAuth et responsabilité du fournisseur

La seule autre option pour un client serait de tester les applications SaaS qu'il utilise pour détecter les abus de nOAuth. Avant cela, il peut contacter le fournisseur de l'application pour lui demander s'il connaît nOAuth et s'il a testé l'utilisation abusive de nOAuth.

Quelques points à noter :

• Les organismes de certification tels que SOC II n'ont pas enquêté sur ces abus. Nous avons trouvé des applications vulnérables dont les fournisseurs affichaient des certifications SOC II et autres sur leurs sites.
• Demandez au fournisseur s'il a testé cette vulnérabilité. Nous avons trouvé des fournisseurs qui pensaient avoir résolu le problème, alors que nous étions toujours en mesure d'effectuer des abus de nOAuth contre leurs applications.

Si le fournisseur ne peut pas répondre définitivement à cette question, le client peut effectuer ce test avec n'importe quelle application qui le préoccupe. Tout comme les chercheurs en sécurité, les clients doivent s'assurer que leurs tests respectent les limites éthiques : ils doivent tester leurs propres comptes d'utilisateur et comprendre les exigences contractuelles qu'ils peuvent avoir avec le fournisseur.

Défense des développeurs de logiciels contre nOAuth

Les développeurs qui utilisent l'allégation de courrier électronique doivent vérifier qu'ils ne l'utilisent pas pour l'identification de l'utilisateur. Si c'est le cas, ils doivent suivre les étapes documentées par Microsoft pour respecter les spécifications OIC, en utilisant l'émetteur et le sujet.

Les développeurs peuvent également examiner les enregistrements de leurs applications pour déterminer s'ils reçoivent l'allégation de courriel non vérifié. Cependant, c'est au développeur d'examiner son code pour déterminer comment l'allégation d'email est utilisée.

Il existe également d'autres solutions pour recevoir les données d'attributs de l'adresse électronique autrement que par le biais d'une revendication dans le jeton d'identification. L'OIDC spécifie un point de terminaison UserInfo, qui est mis en œuvre dans Entra ID. Ce point d'accès peut être utilisé pour recevoir des informations sur l'utilisateur authentifié. En appelant le point de terminaison UserInfo, l'application peut obtenir l'adresse électronique de l'utilisateur après l'authentification, même si cette adresse n'est pas vérifiée. Cette étape permet de s'assurer que l'adresse électronique n'est pas utilisée comme identifiant unique de l'utilisateur.

Dans cet exemple, nous pouvons appeler le point de terminaison UserInfo sur Adele Vance, qui a une adresse électronique non vérifiée(figure 15). Le sujet, qui est l'identifiant unique, correspondra à celui du jeton ID.

Les développeurs qui ont mis à jour leur code pour résoudre la vulnérabilité nOAuth doivent tester leur application après la correction pour s'assurer qu'elle n'est pas vulnérable aux abus nOAuth. Dans notre travail de remédiation avec les fournisseurs, la correction initiale n'a pas toujours résolu la vulnérabilité.

Lorsqu'il a communiqué avec le CSEM au sujet de nos conclusions, il a répété que les développeurs devaient suivre les recommandations et nous a renvoyés à l'article qu'il a publié à partir de la divulgation en 2023. Étant donné qu'il existe des besoins légitimes pour les applications d'obtenir l'adresse électronique d'un utilisateur, il n'y a aucun moyen de déterminer si une application utilise correctement l'attribut sans tester chaque application. Comme nous l'avons constaté lors de nos propres tests, ce processus prend beaucoup de temps.

Le CSEM a également indiqué qu'il avait communiqué avec les fournisseurs d'applications et que ceux qui n'avaient pas corrigé leurs applications étaient susceptibles d'être retirés de la galerie d'applications d'Entra.

Divulgation et calendrier

Surpris de constater que nOAuth abuse, en particulier dans les applications publiées dans la galerie Entra, nous avons ouvert un dossier auprès du CSEM (numéro de dossier 93209).

Nous avons également demandé au Microsoft Identity Product Group d'être plus agressif dans la protection des clients, compte tenu de la difficulté de la détection des abus de nOAuth. Nous avons suggéré d'avertir les clients des donneurs d'ordre que l'application permet des demandes d'email non vérifiées, même si, comme nous l'avons noté, ce n'est pas un identifiant absolu de vulnérabilité à nOAuth.

Nous avons également indiqué les neuf applications vulnérables que nous avons trouvées, au cas où le CSEM serait en contact avec ces fournisseurs.

• Le 3 décembre 2024 : Cas créé avec le CSEM
• Le 3 décembre 2024 : Cas reconnu par le CSEM
• Le 4 décembre 2024 : Nous avons fourni des détails supplémentaires au CSEM
• 17 décembre 2024 : Nous avons mis à jour le cas avec le CSEM, en notant que nous avons travaillé avec un fournisseur pour résoudre l'une des applications vulnérables
• 17 mars 2025 : Nous avons interrogé le CSEM sur l'état d'avancement du dossier ; aucune réponse n'a été reçue.
• 18 mars 2025 : Nous avons informé le CSEM sur le portail de notre intention de divulguer des informations lors de la session de Troopers 2025 (si nous sommes sélectionnés).
• 19 mars 2025 : Nous avons informé le CSEM par courriel de notre intention de divulguer des informations lors d'une session à Troopers (si nous sommes sélectionnés) et nous avons demandé des conseils sur la divulgation, étant donné que la vulnérabilité initiale avait déjà été divulguée ; aucune réponse n'a été reçue.
• 18 avril 2025 : Le dossier a été clôturé par le CSEM, qui a déclaré qu'"un correctif a été signalé pour le problème que vous avez présenté", sans autre information.
• Avril - mai 2025 : Nous avons testé et trouvé des fournisseurs d'applications qui étaient vulnérables à nOAuth ; nous avons à nouveau notifié les fournisseurs et communiqué nos conclusions au CSEM.
• Juin 2025 : Le CSEM a fourni des détails concernant les applications vulnérables à nOAuth dans la galerie d'applications d'Entra.
• 26 juin 2025 : Divulgation publique