On a managed Android phone, Microsoft Authenticator does more than show six-digit codes. It works as the device's identity broker: when Outlook, Teams or another Microsoft app needs to sign in to a work account, it asks Authenticator, and Authenticator hands back an access token. A token is a short-lived digital pass that lets the app act for the user without asking for the password again. Because the broker holds those passes for every work app on the phone, it has to be strict about which app it gives them to.
According to research published on October 23 by Ofek Levin of Enclave, it was not strict enough. Levin showed that a malicious Android app with no permissions at all could claim to be Teams or Outlook, and Authenticator would give it that app's tokens for the signed-in work account. Enclave's write-up is titled "AuthMask." Microsoft tracks the flaw as CVE-2026-80097, which was published on September 8, 2026, more than six weeks before the write-up and the press coverage that followed.
The fix is already out. What admins need to do is make sure every phone in the fleet actually has it.
What went wrong
Enclave's analysis comes down to two failures that stacked on top of each other.
The door was open to everyone. Android apps are built from components, and an app can mark a component as "exported," which means other apps on the device can start it. Levin found that an account-chooser screen inside Authenticator's authentication process was exported. Its only gate was a check that the caller had launched it in a way that expects a result back. Any installed app can pass that check.
The broker believed what the caller said about itself. Once inside, the request carried the fields the broker uses to decide who is asking: the package name, client ID, redirect URI and requested scopes. Enclave reports that all of them came from data the calling app supplied. Authenticator did run a validation step. It compared the claimed redirect URI with one built from the signing signature of the claimed app as installed on the phone. But any app can read another installed app's signature information, so a rogue app posing as Outlook or Teams could produce a matching value and pass the check. Enclave's summary is that the broker never used the caller's real identity, which Android itself can report, when deciding whether to release tokens.
In short, Authenticator asked "who are you?" and accepted the answer without checking it.
What an attacker gets
Enclave says the stolen tokens gave delegated access to the victim's mailbox, files and calendar. Help Net Security's October 27 report lists the impact more fully. A rogue app could read and send mail, read and change files, reach calendar and SharePoint data, and send Teams messages as the victim.
The most serious case is impersonating Authenticator itself. Both Enclave and Help Net Security report that doing so could let an attacker change the account's sign-in methods, including creating or deleting passkeys. Help Net Security notes that an attacker who adds their own passkey to an account can keep getting in after the malicious app has been removed. That is a foothold on the account itself, not just on the phone.
That is consistent with the CVSS 3.1 score of 8.6 (High) on the NVD record. Its vector marks the scope as "changed" (the bug sits in a phone app, but the impact reaches beyond it), with high impact to confidentiality, integrity and availability. NVD lists the weakness as CWE-287, improper authentication. CISA's SSVC entry rates technical impact as "total."
How worried should you be?
The limits matter as much as the impact.
- A malicious app has to be installed first. Help Net Security says the attack still needed a malicious app on the device, so someone would have to be tricked into installing one, and Enclave describes the attacker as a malicious app on the device. This is not a remote, over-the-network attack. Someone has to get a rogue app onto the phone, for example through a malicious store listing, a sideloaded APK, or a lookalike utility.
- The device needs Authenticator with a work account signed in. Enclave lists that as the only setup required. It says there was no user interaction beyond having the broker present with a signed-in work account, and Help Net Security says the rogue app needs no permissions and no tap. NVD's vector does list user interaction as required. One plausible reading is that installing the app is the interaction, but the sources do not spell this out.
- No known in-the-wild exploitation. CISA's SSVC entry records exploitation as "none" and automatable as "no." The sources do not mention any attacks in the wild.
The zero-permission detail is what makes this worth acting on. Security teams that vet mobile apps often focus on what an app asks for: contacts, SMS, accessibility services. An app that requests nothing passes that kind of review easily, and here it didn't need to request anything.
What It Means for Defenders
Who is affected: Per NVD, Microsoft Authenticator for Android from version 6.0.0 up to, but not including, 6.2606.4246. Help Net Security describes every Android version before 6.2606.4246 as affected. The sources do not say that the iOS app is affected.
What to patch: Update Microsoft Authenticator from Google Play to 6.2606.4246 or later. NVD lists Microsoft's MSRC advisory for CVE-2026-80097 as the vendor advisory.
What to enforce: Users don't update reliably, and a broker app that seems to work rarely gets their attention. Help Net Security advises companies that manage devices to make sure their MDM enforces the minimum version of 6.2606.4246. If you run Intune or another MDM with app-version compliance rules, that is one place to apply it.
What to restrict: Because the attack needs a malicious app on the device, Help Net Security also advises being careful about sideloading and unfamiliar apps from outside trusted stores. On managed and work-profile devices, consider blocking installs from unknown sources where your platform allows it, and review which apps the work profile permits.
What to check and rotate: The sources do not report any exploitation, so this is precaution, not incident response. Still, the Authenticator impersonation path means a successful attack could leave persistence on the account itself. For high-value users, especially anyone whose phone ran an old Authenticator build next to unvetted apps, review the registered sign-in methods and passkeys in your identity tenant and remove any the user doesn't recognize. If you find suspicious mailbox, SharePoint or Teams activity tied to a mobile session, revoke that user's sessions and refresh tokens as part of your normal process.
For CMMC and federal contractor shops: Phones that broker access to email and files holding controlled unclassified information are likely part of your assessment scope. A documented minimum-version rule for Authenticator, plus a sideloading restriction, can serve as evidence of configuration management and mobile-device control. A note in your POA&M or change log that you closed CVE-2026-80097 across the fleet also helps.
The bigger lesson
Identity brokers concentrate trust. Their purpose is to hold credentials for many apps so those apps don't each have to. That makes the broker's caller check one of the most important checks on the phone. This flaw happened because the check relied on information the caller provided about itself, while Authenticator already had the real caller's identity available and did not use it for the trust decision. Fixing it took a patch from Microsoft. Getting the patch onto every phone still falls to each IT team, and an MDM version rule is a dependable way to do that.
