Microsoft Authenticator for Android CVE-2026-80097 (AuthMask): How the Token Theft Worked and What to Do

Direct answer

CVE-2026-80097 is an improper-authentication bug (CWE-287) in Microsoft Authenticator for Android, versions 6.0.0 up to but not including 6.2606.4246. Microsoft fixed it on September 8, 2026 and rates it Important, CVSS 8.6 base / 7.5 temporal. Researchers at Enclave, who call it "AuthMask", showed that a malicious app with zero Android permissions could pretend to be Teams and get Authenticator to hand back plaintext access and refresh tokens for the signed-in work account. The fix is to update Authenticator to 6.2606.4246 or later. iOS is not listed as affected. Microsoft says it was not exploited or publicly disclosed before the patch, and it is not in CISA's KEV catalog. [S1, S2, S3, S4]

The key facts

How it worked

On Android, Authenticator is the "broker": other Microsoft apps such as Teams and Outlook ask it for tokens instead of signing in themselves. Enclave's write-up (October 23, 2026, researcher Ofek Levin) describes three mistakes that lined up. [S2]

1. An activity anyone could open. com.microsoft.identity.client.AccountChooserActivity was exported (android:exported="true"), so any app on the phone could launch it. Its only gate was that the caller used startActivityForResult.
2. The caller described itself. The app name, package name, client ID, redirect URI, scopes and even the caller UID all came from the request the caller wrote.
3. A signature check that checked itself. isValidCallingApp looked up the signature of the package the caller *claimed* to be, built that package's expected redirect URI, and compared it with the redirect URI the caller sent. Because the real Teams was installed, the attacker could read its signature and build the same URI, so the check always passed. Authenticator did know the real caller (getCallingActivity().getPackageName()), but used it only for bookkeeping.

On success, the activity returned access_token, refresh_token, id_token and client_info to the caller in plaintext. [S2]

Enclave tried three disguises: [S2]

• As Teams, asking for Microsoft Graph: Mail.ReadWrite, Mail.Send, Files.ReadWrite.All, Calendars.ReadWrite, ChatMessage.Send, Sites.ReadWrite.All and more. That's full delegated mail, files and calendar access.
• As the Teams chat backend (api.spaces.skype.com): user_impersonation.
• As Authenticator's own client: UserAuthenticationMethod.ReadWrite, Passkey.Create and Passkey.Delete. In other words, the ability to change the victim's sign-in methods, including adding a passkey of the attacker's own.

These are genuine tokens issued to a genuine Microsoft client, so MFA and Conditional Access were already satisfied when they were minted. Stopping a stolen refresh token depends on revocation, not sign-in policy.

Where Microsoft and Enclave disagree

Microsoft's advisory says exploitation requires "installing and running a malicious application on an affected Android device and convincing the user to complete an authentication flow in Microsoft Authenticator," and the CVSS vector marks user interaction as required. [S1]

Enclave says that in its tests there was "no user interaction beyond having the broker present with a signed-in work account." [S2]

We can't settle this from outside. Both agree a malicious app has to get onto the phone first, and that's the step to defend in either case. Plan for the worse reading.

Who is affected

• Android phones running Microsoft Authenticator 6.0.0 to before 6.2606.4246 with a work or school account signed in.
• iPhone and iPad are not in Microsoft's or NVD's affected product list. [S1, S3]
• Personal Microsoft accounts: Enclave's demo used a work account; the sources don't say whether personal accounts were exposed the same way.

The fix for users

1. Open the Google Play Store, search Microsoft Authenticator, and tap Update. If the button says Open, you're already current.
2. To check, long-press the Authenticator icon, tap App info, and look at the version at the bottom. It should be 6.2606.4246 or higher.
3. Remove apps you don't recognise or no longer use, and don't install APKs from outside the Play Store. The attack needs a malicious app on the same phone.

There's no workaround short of updating. [S5]

The fix for IT admins

1. Push the update

In Intune, add Microsoft Authenticator as a managed Google Play app and assign it as Required to your Android Enterprise devices. Set the app's update priority to High priority so devices update as soon as a new version is available instead of waiting for idle, charging and Wi-Fi conditions. [S6]

2. Enforce a minimum version

• App protection policies (MAM): Conditional launch includes Min app version, with actions to warn, block access or wipe data. It applies to apps targeted by the policy. Check whether Authenticator itself can be targeted in your tenant; if not, rely on the required-app deployment for Authenticator and keep version and device conditions on the apps you protect (Outlook, Teams). [S6]
• Compliance policies: Android compliance policies check device signals such as OS version, security patch level and Play Integrity. They don't have a built-in "minimum version of app X" setting. Use them to require a recent patch level and block apps from unknown sources, then require a compliant device in Conditional Access for Microsoft 365. [S6]
• Find stragglers: Intune's Discovered apps report lists app versions on corporate devices. Filter for Microsoft Authenticator and look for anything below 6.2606.4246.

3. Revoke sessions where you suspect exposure

Updating stops new theft but doesn't kill tokens already taken. For any user who ran a vulnerable version alongside an app you don't trust:

• Entra admin center: Users > select the user > Revoke sessions.
• PowerShell (Microsoft Graph):

Connect-MgGraph -Scopes "User.RevokeSessions.All"
Revoke-MgUserSignInSession -UserId "user@contoso.com"

This invalidates refresh tokens and session cookies. Access tokens already issued stay valid until they expire unless the resource supports Continuous Access Evaluation. Afterwards, review the user's authentication methods and remove any passkey or method they don't recognise. [S7]

4. Hunt in sign-in and audit logs

The stolen tokens belong to a real Microsoft client (Teams), so you're looking for normal-looking app activity from the wrong place. These are starting points for Microsoft Sentinel or Log Analytics, not tested detections; adjust them to your environment. For a KQL refresher, see the SC-200 KQL lesson.

Teams-client sign-ins to Microsoft Graph from IPs the user hasn't used before:

// Teams client ID used in Enclave's proof of concept
let teamsAppId = "1fec8e78-bce4-4aaf-ab1b-5451cc387264";
let known = union SigninLogs, AADNonInteractiveUserSignInLogs
    | where TimeGenerated between (ago(60d) .. ago(14d))
    | where ResultType == 0
    | distinct UserPrincipalName, IPAddress;
union SigninLogs, AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(14d)
| where AppId == teamsAppId and ResourceDisplayName == "Microsoft Graph"
| where ResultType == 0
| join kind=leftanti known on UserPrincipalName, IPAddress
| project TimeGenerated, UserPrincipalName, IPAddress, Location, UserAgent

Authentication method and passkey changes:

AuditLogs
| where TimeGenerated > ago(30d)
| where OperationName has_any ("security info", "passkey", "FIDO2", "authentication method")
| extend Actor = tostring(InitiatedBy.user.userPrincipalName),
         ActorIP = tostring(InitiatedBy.user.ipAddress),
         Target = tostring(TargetResources[0].userPrincipalName)
| project TimeGenerated, OperationName, Result, Actor, ActorIP, Target
| order by TimeGenerated desc

If you collect MicrosoftGraphActivityLogs, also look for bursts of mail (/messages, /sendMail) or file (/drive) requests from IPs that don't match the user's normal sign-ins. For anything that hits: revoke sessions, reset authentication methods and check mailbox rules.

5. Block sideloading

The attack starts with a malicious app on the phone. On Android Enterprise work profile and fully managed devices, keep unknown sources blocked, allow only managed Google Play apps in the work profile, and consider a Mobile Threat Defense connector so Intune can mark devices with risky apps as non-compliant. [S6]

Why this matters beyond one bug

Brokered sign-in puts all of a user's Microsoft 365 tokens behind one app. When that app trusts what a caller says about itself, every downstream control is already bypassed. If you're comparing identity platforms, mobile broker design is worth asking about; we cover the bigger picture in Okta vs Microsoft Entra ID. And if you want to know what your public-facing sites expose, run the free Protego vulnerability scanner.

FAQ

Is my iPhone affected? No. Microsoft and NVD list only Microsoft Authenticator for Android.

Which version fixes it? 6.2606.4246 and later.

Was it exploited? Microsoft says no, and it isn't in CISA's KEV catalog as of October 28, 2026. The technical details went public on October 23, 2026, so unpatched phones are a more attractive target now.

Do MFA or Conditional Access protect me? Not against the stolen tokens themselves, which were issued after MFA and policy were satisfied. Patching, revocation and device compliance are what help.

Do I need to reset passwords? That isn't the main fix. Revoke sessions and review authentication methods, especially passkeys, for anyone you think was exposed.

What is a "broker"? The app (Authenticator or Company Portal on Android) that signs you in once and hands tokens to other Microsoft apps, so you don't sign in to each one.

Sources

• S1. Microsoft MSRC, CVE-2026-80097: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-80097
• S2. Enclave, "AuthMask: We Made Microsoft Authenticator Hand Over Tokens to an App With Zero Permissions" (Oct 23, 2026): https://enclave.ai/blog/authmask-we-made-microsoft-authenticator-hand-over-tokens
• S3. NVD, CVE-2026-80097: https://nvd.nist.gov/vuln/detail/CVE-2026-80097 (CVE record: https://www.cve.org/CVERecord?id=CVE-2026-80097)
• S4. CISA Known Exploited Vulnerabilities catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• S5. Armis, CVE-2026-80097: https://cve.armis.com/CVE-2026-80097
• S6. Microsoft Learn, Intune app protection policy settings (Android) and Android Enterprise compliance settings: https://learn.microsoft.com/intune/intune-service/apps/app-protection-policy-settings-android and https://learn.microsoft.com/intune/intune-service/protect/compliance-policy-create-android-for-work
• S7. Microsoft Learn, Revoke-MgUserSignInSession: https://learn.microsoft.com/powershell/module/microsoft.graph.users.actions/revoke-mgusersigninsession