Identity

Authenticator for Android handed work tokens to any app

By Yaali. October 28, 2026, 6 min read, Identity, Vulnerabilities, Patching.

CVE-2026-80097 let a zero-permission Android app pose as Teams and get work account tokens from Microsoft Authenticator. Fixed in 6.2606.4246. What to check.

Microsoft Authenticator for Android would issue Microsoft Entra ID tokens for a signed-in work account to any app on the same phone that claimed to be Microsoft Teams. The bug, CVE-2026-80097 (CVSS 3.1 score 8.6, rated Important), was found by Ofek Levin of Enclave, and Microsoft published the fix on September 8, 2026. Enclave released the technical write-up, which it calls AuthMask, on October 23. The attacking app needed no Android permissions at all.

You are affected if staff have a work account in Authenticator on an Android phone running a build older than 6.2606.4246. Microsoft says the flaw was not exploited or publicly disclosed before the fix, and it is not in the CISA Known Exploited Vulnerabilities catalog. The details are now public, though, and Authenticator updates on personal phones are often left to the user, so many devices may still be behind.

How it works

On Android, Authenticator also acts as the authentication broker for Microsoft apps: when Teams or Outlook needs a token for your work account, it asks Authenticator, which holds the account and does single sign-on for every Microsoft app on the phone. A broker is only safe if it knows who is asking, because each app has its own client ID and gets tokens scoped to what that client is allowed to do.

Authenticator exposed an activity (an Android screen component) called com.microsoft.identity.client.AccountChooserActivity, marked android:exported="true", so any installed app could start it. The only gate Enclave found was that the activity had been started for a result. The caller passed a JSON request in an extra named broker_request_v2, and every field in it came from the caller: client_app_name, client_id, redirect_uri, scopes, authority and username.

The identity check sat in BrokerInteractiveTokenCommandParameters.validate(), which called isValidCallingApp(redirectUri, callerPackageName). That function builds the redirect URI it expects from the signing certificate of the package the caller names, and compares it with the one the caller sent. Teams was really installed, so its certificate produced a valid redirect URI, and any app can read another app's signature through Android's PackageManager. So the check confirmed that the claimed identity matched an installed app, and said nothing about whether the caller was that app.

Android already gave Authenticator the real answer: getCallingActivity().getPackageName() returns the package that launched the activity. Enclave found that value was used only to track parallel requests, never in the trust decision.

What a forged request returned

The result came back to the attacking app in broker_result_v2_compressed, with an access token, a refresh token, an ID token and client info in plaintext. A refresh token lets the holder get new access tokens without the user signing in again, so the attacker's access can outlive the bug.

Posing as Teams (client ID 1fec8e78-bce4-4aaf-ab1b-5451cc387264) and asking for Microsoft Graph, Enclave received delegated permissions that included Mail.ReadWrite, Mail.Send, Files.ReadWrite.All, Sites.ReadWrite.All, Calendars.ReadWrite and ChatMessage.Send. It also got user_impersonation on the Teams chat backend, api.spaces.skype.com. Posing as Authenticator's own client returned UserAuthenticationMethod.ReadWrite, Passkey.Create and Passkey.Delete, which are enough to add or remove a user's sign-in methods.

The tokens covered the work account signed in to Authenticator on that phone, not other users in the tenant. Because the token came from the broker, the user's earlier MFA had already been satisfied.

Microsoft and Enclave disagree on user interaction

Microsoft says exploitation needs a malicious app on the device and a user who completes an authentication flow in Authenticator, and its CVSS vector reflects that (AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H). It rates exploitation "less likely". Enclave says its proof of concept needed "no user interaction beyond having the broker present with a signed-in work account". We cannot settle that from the published material. Plan as if Enclave is right: the only real hurdle is getting a user to install an app.

What to do

1. Update Authenticator to 6.2606.4246 or later on every Android device with a work account. Users can check under the app's settings or in Google Play under "About this app". Microsoft lists no workaround, so the update is the fix.
2. Push it on managed devices. In Microsoft Intune, Authenticator is normally a managed Google Play app for Android Enterprise; set its update priority to High priority so Google Play installs the update as soon as it is available. Use Apps, then Monitor, then Discovered apps to find devices still reporting an older Authenticator version, and follow up with the owners.
3. Ask owners of unmanaged phones to update. Bring-your-own-device phones with a work account in Authenticator are outside Intune's update push, so send them the version number, and treat any sideloaded or unknown app on a phone that holds a work account as a reason to look closer. The attack needs a malicious app on the device.
4. Check for misuse. Microsoft published no indicators. In Entra ID, look at sign-in logs for the Microsoft Teams client ID above where the device or IP address does not match the user's usual phone, and at non-interactive sign-ins (the AADNonInteractiveUserSignInLogs table in Log Analytics) where a refresh token for that client is redeemed from somewhere unexpected. If you send Microsoft Graph activity logs to a workspace, MicrosoftGraphActivityLogs shows which app ID and IP address made each Graph call. In the audit log, look for unexpected authentication method or passkey changes on accounts used on Android.
5. Clean up a suspect account. The sources do not say whether updating the app cancels tokens a malicious app already took, so assume it does not. Revoke the user's sessions in the Entra admin center or with Revoke-MgUserSignInSession in Microsoft Graph PowerShell, remove any sign-in method or passkey the user does not recognise, and check for new inbox rules, forwarding and files shared outside the organization.

The broker is part of your identity perimeter

Most tenants have strong Conditional Access on browsers and laptops and treat the phone as the trusted second factor. This bug sat inside that trusted second factor, and it handed out the same tokens a user's own Teams app gets. Keep a minimum Authenticator version in your device policy and in your patch reporting alongside the operating system, and include broker apps when you test mobile clients, since an exported Android component that trusts caller-supplied identity is a common pattern.

We test exported components, intents and token handling in Android apps as part of mobile penetration testing, and review Entra sign-in and Graph activity for this kind of token misuse in security operations. To ask about either, open the chat and Yaali, our AI agent, will pass your question to an engineer.

Sources: Enclave, AuthMask write-up, The Hacker News, Microsoft Security Update Guide, CVE-2026-80097, Android Pure, Runtime Wire, Secarma.