AuthMask : vol de jetons dans Microsoft Authenticator pour Android (CVE-2026-80097)

En bref

• Microsoft Authenticator pour Android sert d'intermédiaire d'authentification pour d'autres applications Microsoft. Dans les versions antérieures à 6.2606.4246, une activité exportée permettait à n'importe quelle application de l'appareil, sans aucune permission, de se faire passer pour une application Microsoft installée, comme Teams, et de recevoir en clair les jetons du compte professionnel sous l'identité cliente de cette application, y compris les jetons d'accès et d'actualisation. La démonstration du chercheur s'appelle AuthMask ; la faille porte l'identifiant CVE-2026-80097.
• Tout appareil équipé de Microsoft Authenticator pour Android dans une version antérieure à 6.2606.4246, avec un compte professionnel connecté, est concerné. La faille obtient un score de base CVSS v3.1 de 8,6, de sévérité élevée (CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H/E:U/RL:O/RC:C), tandis que Microsoft lui attribue sa propre sévérité « importante ».
• Microsoft indique que la faille n'a pas été exploitée et n'avait pas été divulguée publiquement avant le correctif ; l'évaluation ADP de la CISA indique une exploitation inexistante. Au 27 octobre 2026, elle ne figure pas dans le catalogue KEV de la CISA. Une preuve de concept publique, publiée par le chercheur le 23 octobre 2026, démontre toute la chaîne. La valeur E:U du vecteur, qui indique une maturité d'exploitation non démontrée, date de l'évaluation Microsoft du 8 septembre, avant la publication de cette preuve de concept.
• Mettez Microsoft Authenticator pour Android à jour vers la version 6.2606.4246 ou ultérieure. Les organisations qui gèrent des appareils Android peuvent imposer cette version minimale au moyen de leur gestion des appareils.

Suis-je concerné ?

Votre appareil est vulnérable si ces deux conditions sont réunies :

• L'appareil exécute Microsoft Authenticator pour Android (package com.azure.authenticator) dans une version antérieure à 6.2606.4246.
• Un compte professionnel est connecté à Authenticator sur cet appareil, car l'intermédiaire distribue des jetons pour le compte connecté.

L'exploitation nécessite également qu'une application malveillante soit installée sur l'appareil. Il s'agit d'un prérequis pour l'attaquant, pas d'une condition de vulnérabilité : l'application de preuve de concept ne détenait aucune permission, et l'attaque est lancée depuis cette application, pas depuis un site web.

Vous n'êtes pas concerné par cette faille si l'appareil exécute la version 6.2606.4246 ou ultérieure. Lors de la vérification du 27 octobre 2026, la fiche Google Play proposait la version 6.2609.6214, mise à jour le 26 octobre. La faille se situe dans l'implémentation de l'intermédiaire de l'application Android ; le bulletin et les travaux publiés traitent de cette application, et aucune source disponible ne se prononce sur les autres plateformes.

La fiche Google Play de l'application affiche plus de 100 millions de téléchargements (vérification le 27 octobre 2026). La documentation Microsoft sur le SSO Android présente Authenticator comme un intermédiaire d'authentification : les applications peuvent l'utiliser pour obtenir des jetons et partager la connexion sur l'appareil.

Vérifiez la version que vous utilisez :

• Sur l'appareil : ouvrez les paramètres Android, puis Applications, puis Microsoft Authenticator, et lisez la version affichée dans les informations sur l'application. L'écran À propos de l'application affiche la même valeur.
• Sur un parc géré : consultez la version déclarée pour com.azure.authenticator dans l'inventaire de gestion des appareils et imposez la version 6.2606.4246 ou ultérieure.

Comment corriger la faille ?

Mettez Microsoft Authenticator pour Android à jour depuis Google Play, puis vérifiez que la version installée est 6.2606.4246 ou ultérieure. Sur un parc géré, imposez cette version minimale via votre plateforme de gestion des appareils pour empêcher les appareils en retard de mise à jour de rester connectés.

Les sources disponibles s'arrêtent au correctif : le bulletin Microsoft, tel que rapporté par The Hacker News, ne précise pas si la mise à jour révoque les jetons qu'une application malveillante aurait déjà collectés, et la divulgation du chercheur n'aborde pas non plus ce point.

Considérez comme exposé tout appareil sur lequel une version non corrigée a coexisté avec une application inconnue. Demandez à un administrateur de sélectionner l'utilisateur dans Entra ID > Utilisateurs > Tous les utilisateurs, puis de choisir Révoquer les sessions, conformément aux recommandations Microsoft sur la révocation des accès. Cette action révoque les jetons d'actualisation ; les jetons d'accès existants peuvent rester valides jusqu'à leur expiration. Renouvelez tous les identifiants que ces sessions auraient pu exposer.

Aucune modification de configuration ne remplace la mise à jour : la faille réside dans la logique de validation de l'intermédiaire, et aucun réglage d'Authenticator ne change ce comportement.

Quelle est la cause racine ?

La requête de jetons de l'intermédiaire était construite entièrement à partir de valeurs fournies par l'application appelante, et son contrôle de signature validait l'identité revendiquée contre des données que l'appelant contrôlait également. Comme les deux côtés du contrôle provenaient du même appelant, une application sans aucune permission pouvait se faire passer pour n'importe quelle application Microsoft installée et franchir le contrôle.

La chaîne décrite dans la divulgation du chercheur sur la version vulnérable comporte trois parties.

Premièrement, le point d'entrée est ouvert à toutes les applications. Authenticator expose l'activité com.microsoft.identity.client.AccountChooserActivity, marquée android:exported="true", de sorte que toute application de l'appareil peut la démarrer. Son seul contrôle exige que getCallingActivity() ne soit pas nul, ce que satisfait tout appelant utilisant startActivityForResult.

Deuxièmement, la requête est rédigée par l'attaquant. L'activité transmet directement les paramètres supplémentaires de l'intent à son sélecteur de compte, et la requête de l'intermédiaire est construite à partir de ces paramètres : l'UID de l'appelant provient du paramètre caller.info.uid, tandis que le nom de l'application, le nom du package, l'identifiant client, l'URI de redirection et les portées proviennent tous du paramètre JSON broker_request_v2. Le résumé de la divulgation est sans détour : l'identité de l'appelant n'a jamais servi à une décision de confiance.

Troisièmement, la validation confirme les propres déclarations de l'appelant. BrokerInteractiveTokenCommandParameters.validate() appelle :

platformUtil.isValidCallingApp(getRedirectUri(), getCallerPackageName());

Puis isValidCallingApp calcule l'URI de redirection que le package revendiqué devrait utiliser à partir de sa signature installée, et la compare à l'URI de redirection envoyée par l'appelant :

String brokerRedirectUri = PackageHelper.getBrokerRedirectUri(this.mContext, claimedPackage);
return StringUtil.equalsIgnoreCase(claimedRedirect, brokerRedirectUri);

Comme l'application usurpée est réellement installée, sa véritable signature est lisible via PackageManager. L'attaquant la lit donc, construit l'URI de redirection authentique et l'insère dans la requête. Le contrôle réussit alors. Authenticator disposait d'une seconde réponse, le véritable appelant obtenu avec getCallingActivity().getPackageName(), mais ne l'utilisait que pour le suivi interne, jamais pour la décision de confiance.

Comment est-elle exploitée ?

L'application de l'attaquant lit la signature de l'application usurpée, construit une requête d'intermédiaire qui revendique cette identité, lance l'activité exportée et reçoit les jetons dans son propre onActivityResult.

La preuve de concept publiée, qui se fait passer pour Teams :

int uid = getPackageManager().getApplicationInfo("com.microsoft.teams", 0).uid; // read Teams' uid
String redirect = "msauth://com.microsoft.teams/" + urlEncode(sha1OfInstalledSig("com.microsoft.teams"));

JSONObject req = new JSONObject();           // broker_request_v2, all attacker-controlled
req.put("client_app_name", "com.microsoft.teams");
req.put("client_id", "1fec8e78-bce4-4aaf-ab1b-5451cc387264");
req.put("redirect_uri", redirect);
req.put("scopes", "https://graph.microsoft.com/.default");
req.put("authority", "https://login.microsoftonline.com/organizations");
req.put("username", "<victim-upn>");        // the victim's UPN

Intent i = new Intent();
i.setClassName("com.azure.authenticator", "com.microsoft.identity.client.AccountChooserActivity");
i.putExtra("caller.info.uid", uid);          // spoofed caller uid
i.putExtra("common.broker.protocol.version.name", "20.0");
i.putExtra("broker_request_v2", req.toString());
startActivityForResult(i, 1);                // tokens come back to onActivityResult

Étape par étape :

1. L'application de l'attaquant, sans aucune permission, lit l'UID et la signature installée de l'application Microsoft qu'elle veut usurper, ici Teams.
2. Elle construit l'URI de redirection msauth:// à partir de cette signature, afin que la validation de l'intermédiaire reproduise la même valeur, et inscrit l'identifiant client, les portées et le nom d'utilisateur de la victime dans le paramètre broker_request_v2.
3. Elle lance l'activité exportée AccountChooserActivity avec startActivityForResult et un caller.info.uid usurpé. Cet appel fournit une activité appelante, donc getCallingActivity() n'est pas nul et l'unique contrôle de l'activité est satisfait.
4. La validation compare l'URI de redirection fournie par l'attaquant à celle dérivée de la signature installée du package revendiqué. Les deux côtés présentent la même valeur, donc le contrôle réussit, et aucune étape ne confirme que l'application demandeuse est réellement Teams.
5. L'activité renvoie le résultat de l'intermédiaire à celui qui l'a lancée : un ensemble contenant access_token, refresh_token, id_token et client_info en clair, que l'application de l'attaquant peut analyser.

Schéma du déroulement de l'attaque

Que peut faire un attaquant ?

L'attaquant obtient les jetons du compte professionnel connecté à Authenticator sur l'appareil, avec toutes les permissions déléguées associées à l'identifiant client de l'application usurpée.

Le chercheur a mesuré trois usurpations et leurs portées :

• En se faisant passer pour Teams et en demandant Microsoft Graph (graph.microsoft.com/.default) : Mail.ReadWrite, Mail.Send, Files.ReadWrite.All, Calendars.ReadWrite, ChatMessage.Send, Sites.ReadWrite.All et d'autres, ce que le chercheur résume comme un accès délégué complet à la boîte aux lettres, aux fichiers et au calendrier.
• En se faisant passer pour le backend de messagerie Teams (api.spaces.skype.com) : user_impersonation.
• En se faisant passer pour le propre client d'Authenticator : UserAuthenticationMethod.ReadWrite, Passkey.Create, Passkey.Delete.

Microsoft et le chercheur s'accordent sur deux prérequis : une application malveillante installée sur l'appareil et un compte professionnel connecté à Authenticator. Ils divergent sur l'interaction nécessaire :

• Microsoft : Le bulletin, tel que rapporté par The Hacker News, exige que la victime termine une étape de connexion dans Authenticator. Le vecteur CVSS de Microsoft indique qu'une interaction utilisateur est requise (UI:R).
• Chercheur : La preuve de concept a renvoyé des jetons sans interaction supplémentaire dès lors qu'un compte professionnel était connecté à l'intermédiaire.

Pour le triage, considérez comme exposé un appareil ciblé sur lequel une application inconnue est installée, quelle que soit la description applicable.

Comment vérifier le correctif ?

Le correctif consiste à mettre l'application à jour vers la version 6.2606.4246 ou ultérieure. Selon la divulgation du chercheur, Microsoft a corrigé la faille et les versions antérieures à 6.2606.4246 sont affectées. Sur une version corrigée, un appelant ne doit pas pouvoir obtenir les jetons d'une autre application en fournissant son identité et son URI de redirection.

La divulgation publique ne contient pas de diff du correctif et n'établit donc pas la modification exacte apportée à la validation dans la version corrigée. Elle montre que l'intermédiaire vulnérable connaissait le véritable package appelant grâce à getCallingActivity(), mais faisait plutôt confiance à l'identité revendiquée dans les paramètres de la requête.

Une équipe de défense peut vérifier le comportement attendu sur un appareil de test après mise à jour : la requête d'usurpation divulguée ne doit pas renvoyer les jetons du compte professionnel à l'application attaquante. Il s'agit d'un critère de vérification, pas d'une affirmation sur l'implémentation non publiée du correctif.

Comment vérifier si j'ai été compromis ?

Aucun indicateur de compromission, nom de package attaquant ou liste de hachages n'a été publié pour cette faille au 27 octobre 2026, et le bulletin Microsoft ne fournit pas de recommandations de détection dans les sources disponibles. Les vérifications ci-dessous sont celles qu'étayent les éléments publics.

• Sur l'appareil : recherchez les applications installées que vous ne reconnaissez pas, en particulier celles installées hors du store, et vérifiez la version d'Authenticator pour délimiter la période d'exposition.
• Dans les journaux de connexion et d'audit du compte professionnel : recherchez des applications clientes inattendues recevant des permissions déléguées comme Mail.ReadWrite, Files.ReadWrite.All, Calendars.ReadWrite ou UserAuthenticationMethod.ReadWrite.
• Dans les mêmes journaux : recherchez les événements de consentement ou d'émission de jetons qui mentionnent l'identifiant client de Teams depuis des appareils sans session Teams.
• Si une application inconnue a coexisté avec Authenticator dans une version antérieure à 6.2606.4246, partez du principe que les jetons du compte étaient accessibles et révoquez ses sessions actives et ses jetons d'actualisation sans attendre de preuve.

Chronologie

• 2026-09-08 : Microsoft publie CVE-2026-80097 (champ datePublished de la fiche CVE) avec le correctif dans Microsoft Authenticator pour Android 6.2606.4246. Le chercheur avait signalé le problème au MSRC avant cette date, et les sources disponibles ne précisent pas la date de sortie de la version corrigée de l'application.
• 2026-10-23 : Enclave publie la divulgation technique AuthMask avec la preuve de concept complète, attribuée au chercheur Ofek Levin dans le cadre de l'Enclave Fellowship Program.
• 2026-10-26 : la fiche Google Play est mise à jour vers la version 6.2609.6214 (vérification le 27 octobre 2026).
• 2026-10-27 : The Hacker News publie son article sur la faille et les recommandations de correction du bulletin ; le présent article suit, et l'évaluation ADP de la CISA dans la fiche CVE indique une exploitation inexistante.

FAQ

L'application iOS est-elle affectée ?

Les sources disponibles ne le précisent pas. Le bulletin, la divulgation du chercheur et les articles de presse traitent tous de Microsoft Authenticator pour Android, et la chaîne d'attaque repose sur des mécanismes Android : une activité exportée, la lecture de signatures via PackageManager et le protocole d'intermédiaire MSAL Android. Aucune source ne se prononce dans un sens ou dans l'autre sur l'application iOS ; considérez donc ce correctif comme propre à Android et surveillez toute déclaration de l'éditeur sur les autres plateformes.

La victime devait-elle toucher l'écran ?

Microsoft et le chercheur ne sont pas d'accord. Le bulletin Microsoft indique que l'exploitation nécessite que la victime termine une étape de connexion dans Authenticator, et son vecteur CVSS exige une interaction utilisateur. Le chercheur rapporte que la preuve de concept a renvoyé des jetons sans interaction autre qu'un compte professionnel déjà connecté sur un appareil disposant de l'intermédiaire. Les deux s'accordent sur les prérequis utiles au triage : une application malveillante installée et un compte professionnel connecté.

Si un jeton a déjà été volé, la mise à jour de l'application le révoque-t-elle ?

Les sources disponibles ne le précisent pas. Le bulletin Microsoft donne la version corrigée mais, comme le rapporte The Hacker News, n'indique pas si la mise à jour annule les jetons déjà collectés par une application malveillante. Si vous soupçonnez une collecte, révoquez directement les sessions et les jetons d'actualisation du compte au lieu de vous reposer sur la mise à jour.

Pourquoi cette faille est-elle classée élevée et importante plutôt que critique ?

Deux échelles interviennent : le score de base CVSS v3.1 de 8,6 relève de la tranche élevée (7,0 à 8,9), tandis que « importante » correspond à la propre échelle de sévérité de Microsoft. Côté CVSS, l'attaque est locale : l'attaquant doit d'abord installer une application sur l'appareil, ce que le vecteur indique par AV:L, et Microsoft exige une interaction utilisateur, ce qui abaisse encore le score. L'évaluation ADP de la CISA indique une exploitation inexistante, une automatisation impossible et un impact technique total. Le vecteur local signifie que l'attaque ne peut pas être lancée à distance contre un parc d'appareils.

A-t-elle été exploitée dans des attaques réelles ?

Non. Microsoft indique que la faille n'a pas été utilisée dans des attaques et n'avait pas été divulguée publiquement avant le correctif, et considère son exploitation comme peu probable. L'évaluation ADP de la CISA indique une exploitation inexistante, et la CVE ne figure pas dans le catalogue KEV de la CISA au 27 octobre 2026.

Supprimer l'application malveillante suffit-il ?

Cela supprime la présence de l'attaquant, mais pas le risque déjà encouru. Les jetons collectés avant la suppression restent valides jusqu'à leur expiration ou leur révocation. Examinez donc l'activité du compte et révoquez les sessions en parallèle de la suppression, puis mettez Authenticator à jour pour empêcher la répétition de la même chaîne.

Examinez la gestion de l'intermédiaire de votre application Android avec Ostorlab

Lancez un scan mobile Ostorlab sur vos applications Android publiées, puis examinez les activités exportées qui utilisent les paramètres d'intent pour prendre des décisions de confiance. Vérifiez que chaque activité contrôle le véritable appelant avant de renvoyer des jetons ou d'autres données sensibles. Ce contrôle de l'appelant est la frontière qu'AuthMask n'a pas su faire respecter.

Références

• Enclave, « AuthMask: We Made Microsoft Authenticator Hand Over Tokens to an App With Zero Permissions », 23 octobre 2026, chercheur Ofek Levin via l'Enclave Fellowship Program : l'activité exportée AccountChooserActivity, la requête d'intermédiaire fournie par l'appelant, le contrôle de signature qui s'autoconfirme, la preuve de concept complète, les portées mesurées et la version corrigée : https://enclave.ai/blog/authmask-we-made-microsoft-authenticator-hand-over-tokens (consulté le 27 octobre 2026)
• Bulletin Microsoft Security Response Center pour CVE-2026-80097, publié le 8 septembre 2026 : https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-80097 (page rendue en JS ; contenu du bulletin repris de la fiche CVE et de l'article The Hacker News ci-dessous)
• Fiche CVE-2026-80097, CNA Microsoft, publiée le 8 septembre 2026, « Une authentification incorrecte dans Microsoft Authenticator permet à un attaquant non autorisé d'élever ses privilèges localement », CVSS v3.1 8,6 (CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H/E:U/RL:O/RC:C), avec l'évaluation SSVC ADP de la CISA indiquant une exploitation inexistante, une automatisation impossible et un impact technique total : https://cveawg.mitre.org/api/cve/CVE-2026-80097 (consulté le 27 octobre 2026)
• The Hacker News, « Microsoft Authenticator Flaw Let Permissionless Android Apps Steal Work Account Tokens », 27 octobre 2026, citant le bulletin Microsoft sur la version corrigée 6.2606.4246, le prérequis d'une étape de connexion, l'absence d'exploitation, la sévérité importante et le score de 8,6, le contexte du Patch Tuesday de septembre et la correction via la gestion des appareils : https://thehackernews.com/2026/10/microsoft-authenticator-flaw-let.html (consulté le 27 octobre 2026)
• Fiche Google Play de Microsoft Authenticator pour Android, com.azure.authenticator, plus de 100 millions de téléchargements, version actuelle 6.2609.6214 mise à jour le 26 octobre 2026 : https://play.google.com/store/apps/details?id=com.azure.authenticator (consulté le 27 octobre 2026)
• Catalogue CISA Known Exploited Vulnerabilities, vérifié pour CVE-2026-80097 le 27 octobre 2026 (absente) : https://www.cisa.gov/known-exploited-vulnerabilities-catalog