CVE-2026-80097: Update Microsoft Authenticator for Android to Block Work Token Theft

What happened​

Microsoft titled the advisory "CVE-2026-80097 Microsoft Authenticator Elevation of Privilege Vulnerability." The CVE record describes it as improper authentication in Microsoft Authenticator that allows an unauthorized attacker to elevate privileges locally. It was published on 2026-09-08 with a score of 8.6 (High), and its CVSS 3.1 vector is AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H. Microsoft maps it to CWE-287, Improper Authentication.

The flaw was found by Ofek Levin as part of security firm Enclave's fellowship program. Enclave published the details on October 23 under the name "AuthMask." According to Enclave, an Android app with zero permissions could pretend to be any installed Microsoft first-party app. Authenticator's token broker would then give it that app's tokens for the work account signed in on the device. Two things had to be true:

• Microsoft Authenticator was installed.
• A work account was signed into it.

"Zero permissions" sounds alarming, but it doesn't mean the attack works remotely. The malicious app still has to be installed on the phone.

How it worked: two answers to "who's asking?"​

On Android, Authenticator acts as a broker. Microsoft apps such as Teams and Outlook ask it for tokens so you don't have to sign in to each app separately. Enclave found the weak spot in one component:

1. An activity any app could launch. com.microsoft.identity.client.AccountChooserActivity runs in Authenticator's :auth process and is marked android:exported="true". That setting lets any app on the device start it.
2. A check that almost anything passes. Enclave says the only gate was that getCallingActivity() returned something. Any app that launches the activity with startActivityForResult meets that test.
3. Every request field came from the caller. The caller supplied the claimed app name and package, client ID, redirect URI, requested scopes and even its own UID.
4. A signature check against the wrong app. Authenticator looked up the signature of the package the caller claimed to be, built the redirect URI that package should use, and compared it with the URI the caller sent. The real app was installed on the same phone, so an attacker could read its signature, compute the same URI, and pass every time.

The key detail is that Authenticator did know the real caller. Enclave says it read the true package name through getCallingActivity().getPackageName(), but used it only to keep track of parallel requests. It never used it to decide whether to hand over tokens. The activity checked the identity the caller claimed and ignored the identity it had verified.

Summary: This wasn't a cryptography failure. Authenticator ran a real check against an identity the attacker got to choose.

What the proof of concept got​

In Enclave's demonstration, a permission-free app claimed to be Teams. It sent Teams' client ID, asked for Microsoft Graph's .default scope, and received a result bundle containing an access token, refresh token, ID token and client info, all in plaintext it could read. Enclave reported three sets of results from three disguises:

The last row is the most worrying. Tokens that can change authentication methods and create or delete passkeys could let an attacker who stole a token keep access to the account afterwards. The mailbox scopes are just as bad: an attacker could read mail and send it as the user from a real corporate account, which makes for very convincing phishing.

These were the researcher's test results. They don't prove that every tenant would issue the same scopes. Conditional Access, tenant settings and service-side controls can limit what a token can actually do.

How much user interaction does it need?​

The researchers and the CVSS score disagree here. Enclave says its test needed no user interaction beyond having the broker installed with a work account signed in. The CVSS vector says user interaction is required (UI:R). Trend Micro's Zero Day Initiative, in its September Patch Tuesday review, sided with the vector: an attacker would need to install a malicious app on an Android device, then convince a user to complete the authentication sequence.

Both can be true. Getting the malicious app installed already takes user action, whether that's sideloading, a fake app, or a bad store listing. What happens after that may be silent. ZDI still called it the worst type of privilege escalation as it uses a bug in the authentication system itself, and added: "If you have a large Android user base, best not to ignore this one."

On exploitation, the aggregated CVE data from September listed it as KEV: No, meaning it wasn't in CISA's Known Exploited Vulnerabilities catalog. Neither Enclave nor Cyber Press reports any attacks in the wild. That was a September snapshot, though, and doesn't guarantee nobody has tried it since. Now that the full write-up and sample code are public, the bar for copycats is lower.

Which version fixes it?​

Enclave and Cyber Press both say versions before 6.2606.4246 are affected, and that 6.2606.4246 and later are fixed. GBHackers gives the same number, telling organizations that devices should be running version 6.2606.4246 or later.

The CVE record Microsoft submitted shows a different range: version 6.0.0, lessThan 16.3.0. That probably reflects a different internal version format rather than a different fix, but we couldn't confirm it, because Microsoft's advisory page wouldn't load during research. For a practical target, aim for 6.2606.4246 or newer, as the researcher states, and know that some vulnerability scanners may report the CVE using the 16.3.0 range instead.

What admins should do now​

1. Update Authenticator on every Android device, managed or personal, to 6.2606.4246 or later. Most consumer phones will update automatically from Google Play, but check rather than assume.
2. Check that the update actually reached devices using your mobile device management (MDM) tool's app inventory or compliance reporting. Devices that rarely check in are the ones likely to be behind.
3. Limit sideloading on managed devices. The attack needs a malicious app on the phone, and blocking untrusted sources removes the easiest way in. Cryptika's coverage gives similar advice, urging organizations to enforce timely app updates through MDM or EMM platforms, and restrict sideloaded applications where possible.
4. Look back at identity activity for delegated Microsoft Graph activity you can't explain, unusual refresh-token use, and sign-ins from mobile clients you don't recognize. Treat these as leads, not proof. No published indicator separates abuse of this flaw from other causes of odd token activity.
5. Check authentication-method changes. Because the Authenticator-client disguise returned passkey and authentication-method scopes, review recent passkey registrations and deletions on any account you're worried about.
6. Revoke sessions if something looks wrong. A stolen refresh token keeps working after the app is patched, so revoking a suspect user's sessions is the step that cuts off access.

Summary: Patch first, confirm the patch landed, then look for signs that tokens were misused before you updated.

The bigger picture​

Broker apps like Authenticator are what make single sign-on on phones feel seamless, and that makes them high-value targets. A broker that trusts whatever identity a caller claims can be used to get tokens for any app it serves, much like a stolen master key. The fix comes down to a basic principle: when the operating system tells you who the caller is, authorize based on that. Developers building their own broker or token-sharing features on Android should check their exported components for the same mistake.

For everyone else, the message is short: update Authenticator, block sideloading on managed devices, and keep an eye on Microsoft Graph activity you can't account for.