Microsoft Authenticator Flaw: How an App With No Permissions Could Steal Work Tokens

A Microsoft Authenticator flaw let an Android app with no permissions at all collect sign-in tokens for a victim’s work account. Microsoft fixed it in September, but researchers at Enclave only published the full detail on 23 October, and that write-up is worth a careful read if your staff use the app on personal phones.

What the Microsoft Authenticator flaw does

The bug is tracked as CVE-2026-80097. Microsoft calls it an elevation of privilege vulnerability. It is scored 8.6 (High) and filed under improper authentication, according to the Tenable CVE entry. The record was published on 8 September 2026, as part of that month’s Patch Tuesday.

Enclave researcher Ofek Levin found the problem. In the team’s technical write-up, a malicious app could make Authenticator’s broker issue tokens for a signed-in work account. The researchers say the app could impersonate any installed Microsoft first-party app.

How the impersonation worked

Authenticator acts as a broker on Android. Other Microsoft apps, such as Teams, ask it to fetch tokens so the user does not have to sign in again in every app. That is convenient, and it only works if the broker is strict about who is asking.

Here it was not. Enclave found that Authenticator exposes an activity called AccountChooserActivity that any app on the phone can start. The only check on the caller was that it existed. The calling app then supplied its own identity in the request, including the package name, client ID, redirect URI and the permissions it wanted.

Authenticator did check the redirect URI against the signature of the app being claimed. But if Teams really is installed, its real signature produces a matching redirect, so the check passed every time. The broker also knew the real package name of the caller. According to Enclave, it used that only for bookkeeping, not to decide whether to trust the request.

On success, the broker handed back an access token, a refresh token, an ID token and client information in plaintext.

What an attacker could reach

In Enclave’s tests, posing as Teams and asking for Microsoft Graph access returned permissions to read and send mail, read and write files and calendars, send chat messages and write to SharePoint sites. A second disguise, using Authenticator’s own client identity, returned rights to change authentication methods and create or delete passkeys.

That second result matters most. An attacker who can edit sign-in methods can turn a short-lived theft into a lasting foothold. A refresh token adds to that, since it can mint new access tokens after the first one expires.

Where Microsoft and the researchers disagree

The Hacker News reported that Microsoft says exploitation needs two things: a malicious app on the device and a user who completes an authentication flow. The CVSS vector reflects that, with user interaction marked as required. Enclave says its proof of concept returned tokens with no interaction beyond a signed-in work account being present.

Both claims cannot be fully right, and a defender should assume the worse one. Microsoft also says the flaw was not exploited or publicly known before the fix, and rates exploitation as less likely. The Hacker News noted it was absent from CISA’s Known Exploited Vulnerabilities catalogue as of 26 October.

One question remains open. As The Hacker News pointed out, Microsoft’s advisory does not say whether updating the app revokes tokens a malicious app may already have collected.

What to do this week

Start with the version number. The fix is in Microsoft Authenticator for Android 6.2606.4246 and later, so earlier builds are affected. If you manage phones with Intune or another device management tool, set a minimum app version and block sign-in from anything older.

Then think about the tokens. If you suspect a phone ran a dubious app while signed in to Authenticator, revoke that user’s sessions and review their sign-in logs for unfamiliar apps and locations. Check recent changes to authentication methods and passkeys, since that was one of the abuse paths.

Finally, look at which apps staff install on devices that hold work accounts. A flaw like this needs a hostile app to land on the phone first. Restricting sideloading and sticking to the official store narrows that door, though it does not close it.

Why testing the mobile side matters

Many firms test their web applications and networks, then assume the phone is out of scope. Yet the phone holds the brokered tokens that unlock mail, files and chat. An Android penetration testing engagement looks at exactly this kind of weakness: exported components, trust decisions based on caller-supplied data and tokens stored in the clear.

The same logic applies to the apps you build yourself. If your own mobile app has a broker-style component, ask who can call it and how it knows. Our mobile application penetration testing covers that question directly. For a related lesson on stolen sign-in material, see our piece on device code phishing.