Cut-paper illustration of a phone showing a shield and key, with a briefcase on one side and a masked app icon receiving an arrow on the other

Your phone already had the fix. That is the uncomfortable part of this story.

Microsoft published CVE-2026-80097 on September 8, 2026, and the fixed version of Microsoft Authenticator for Android, 6.2606.4246, shipped in July. Most admins only learned the details when researcher Ofek Levin's write-up landed on October 23, with wider coverage on October 27. A patch nobody knows to check for is not yet a fix in practice. It is a version number in the Play Store, waiting for someone to enforce it.

This post is a short fleet check. It starts with one version number and ends with the account review that matters if a device ever ran an old build.

Authenticator is a broker, not just a code generator

On Android, Authenticator does more than show six digit codes and approve push notifications. It also acts as a broker for other Microsoft apps. When Teams or Outlook needs to sign a user in, it asks Authenticator, and Authenticator hands back a token. A token is proof that sign-in already happened. An app holding a valid token can read mail, files, and calendar data without asking for a password or a second factor again.

The broker does not hold one app's session. It holds the keys for the whole work account signed into it on that device. A flaw in how it decides who gets tokens is an identity flaw, not a minor app bug.

The broker trusted what the caller said about itself

Levin, working through Enclave's fellowship program, found that Authenticator exposed a component called AccountChooserActivity that any app on the device could launch. The activity built its token request from values supplied by the calling app, including the name of the app it claimed to be. A malicious app with no Android permissions at all could say it was Teams, and the broker believed it.

There was a signature check, but it checked the wrong question. It looked up the real signature of the package being impersonated and compared it with the redirect address in the request. Because Teams was genuinely installed, its genuine signature produced the genuine redirect address, and the check passed. Authenticator knew the real identity of the caller. Enclave found it read that identity but used it only for bookkeeping, never for the trust decision.

In Enclave's tests, impersonating Teams returned Graph scopes covering mail, files, calendar, chat, and SharePoint sites. Impersonating Authenticator's own client returned scopes for reading and writing authentication methods, including creating and deleting passkeys.

That last one matters most. A passkey added by an attacker can keep working after the malicious app is removed. Updating the app does not, by itself, remove a sign-in method someone else added. The fix closes the hole. It does not clean up anything planted through it.

One disagreement worth keeping

Enclave and Microsoft do not agree on how much user interaction the attack needed. Enclave reported no user interaction beyond a signed-in work account being present. Microsoft's advisory, as reported by The Hacker News, says exploitation requires installing a malicious app and convincing the user to complete an authentication flow, and its CVSS scoring reflects user interaction.

Plan for the stricter version, which is Enclave's. Both sides agree on the precondition that matters: a malicious app had to be on the device first.

Microsoft has said the flaw has not been exploited in attacks, and The Hacker News reported it was not in the CISA Known Exploited Vulnerabilities catalog as of October 26, 2026. Treat that as reassuring, not as proof that every phone in your fleet was patched in July.

Step 1: Check your own phone

Open the Google Play Store, search for Microsoft Authenticator, and check the version. You want 6.2606.4246 or later. Anything earlier, with a work or school account signed in, is affected. This CVE is Android only. The iPhone version is not covered by it. If the store offers an update, install it, then check the version again. Do not assume auto-update handled it.

Step 2: Enforce the minimum version in Intune

For managed Android devices, set the floor in policy instead of asking users nicely. Intune app protection policies for Android include a minimum app version setting, with actions of warn, block access, or wipe the account's data from the app. Create one policy for Authenticator at 6.2606.4246, start with warn if you need to measure the blast radius, and report on devices below the floor before you switch to block. The straggler list is the useful output. It shows which devices are not getting app updates reliably, a problem that will outlive this CVE.

For unmanaged devices, send the version number, not a general warning.

Step 3: Review accounts that ran an old build

For any work account used on an Android device that ran a version before 6.2606.4246:

  1. Check the authentication methods on the account, with attention to passkeys. Remove any the owner does not recognize.
  2. Review sign-in activity for activity from Android devices the user cannot explain.
  3. Revoke sessions where the activity does not make sense, and have the user sign in again on the updated app.
  4. Ask whether the user installed any app from outside the Play Store, or any unfamiliar app, on that phone. A yes answer moves the device from routine update to a device to inspect or wipe.

Microsoft's advisory does not say whether updating cancels a token a malicious app may already have obtained. That remains unclear from the available sources, which is another reason to revoke sessions rather than assume the update handled it.

Step 4: Close the way in

On managed devices, keep installs to the managed Play Store and block unknown sources. On personal devices, do not sideload apps onto a phone that holds a work account. If an app is not in the Play Store, it does not go on the work phone. That rule protects every app that trusts the device to tell the truth about who is asking.

Check Pass mark
Authenticator version on Android 6.2606.4246 or later
Intune minimum app version Set for Authenticator, stragglers reported
Authentication methods No passkey or method the owner does not recognize
Sessions Revoked where activity cannot be explained
App sources Managed Play Store only on managed devices

The durable point

The flaw is a familiar shape. A component trusted caller-supplied identity, a check verified the impersonated app instead of the real caller, and the information needed for the right decision was present but unused.

The practical point is smaller. A fix shipped in July, a CVE was published in September, and most people learned the details in late October. The gap between a fix existing and a fleet actually running it is where the risk lived. Check the version, enforce the floor, review the accounts, and close the install path. That is the whole job, and it is worth doing this week.

Sources