Authenticator checked the app you claimed to be. It never checked who was actually asking

Enclave published research on 23 October, by Ofek Levin, on a flaw in Microsoft Authenticator for Android. An app with zero permissions could impersonate any installed Microsoft first-party app and have the Authenticator broker hand over that app's tokens for the signed-in work account.

Microsoft tracks it as CVE-2026-80097 and fixed it in build 6.2606.4246, published on 8 September.

One activity any app could launch

Authenticator exposes an activity named AccountChooserActivity, running in its auth process, with android:exported set to true, so any app on the device can start it. The only gate on that activity is a check that there is a calling activity at all, which any app launching it the ordinary way passes.

Everything the broker then uses comes out of the caller's own intent. The calling UID is read from an extra in the bundle, and the app name, package name, client ID, redirect URI and scopes all come from a JSON blob the caller supplies.

Levin's description is flat: "We wrote every one of them."

The check that validated the claim against itself

There is validation, and on paper it sounds right. The broker takes the redirect URI from the request and the package name from the request, looks up that package's signature on the device, builds the redirect URI that package ought to use, and compares the two.

Think about what that actually proves. The app being impersonated really is installed, so its real signature produces its real redirect URI, and the attacker reads that off the package manager and sends it. The check compares the attacker's claim with a value derived from the same claim. It passes every time.

So Authenticator asked whether there was a caller, and whether the redirect URI matched the package in the request. Levin puts the missing question in one line: it never asked whether the app making the request was actually Teams.

Authenticator did know. The activity reads the real calling package name, and uses it only for bookkeeping on parallel requests. Two answers to who is asking were available, and the validation used the one the caller wrote.

Three disguises, and the third is the one to read twice

Enclave impersonated 3 callers and got 3 different sets of scopes back, and the third is the reason this is not simply another token theft bug.

As Teams against Microsoft Graph: mail read and write, send mail, files read and write across the tenant, calendars, chat messages, SharePoint sites. Full delegated access to the mailbox, files and calendar of the signed-in work account.

As the Teams chat backend: user impersonation.

As Authenticator's own client: permission to read and write the account's authentication methods, and to create and delete passkeys. The app holding the second factor could be talked into handing out the ability to rewrite the second factor.

The tokens came back in the result bundle in plaintext, access token, refresh token, ID token and client info, parsed by an app with no permissions at all.

The two sources disagree about how hard this is

Microsoft rates it 8.6 base and 7.5 temporal, severity Important, CWE-287 improper authentication. The vector says attack vector local, privileges required none, scope changed, and user interaction required. The FAQ says an attacker exploits this by installing a malicious app "and convincing the user to complete an authentication flow in Microsoft Authenticator".

Enclave says the opposite: "There was no user interaction beyond having the broker present with a signed-in work account."

Both of those are primary statements from the people involved, and they do not agree on the one metric that decides how urgent this is. We are not in a position to settle it, and neither is anyone else reading both pages.

Microsoft's exploitability table says publicly disclosed no, exploited no, exploitation less likely, exploit code maturity unproven. That assessment was published on 8 September, and the working proof of concept appeared on the 23rd of October.

One smaller detail worth having: revision 1.1 of the advisory, on 15 September, corrected the fix build number. Microsoft calls it an informational change. Anyone who checked their build against the number in the first week was checking against the wrong one.

What to do

• Update Microsoft Authenticator for Android to 6.2606.4246 or later, and check the build rather than assuming the store did it.
• Treat this as an account problem, not just a device one. The scopes include creating and deleting passkeys, so review authentication methods on accounts that were signed in on Android devices.
• Look at your mobile app inventory on managed devices. The attack needs a malicious app present, which is the part your controls can still affect.
• Do not read exploitation less likely as nothing to do here. That assessment predates the published technique by 45 days.
• Keep this next to the other MFA finding of the month: Talos put missing or insufficient MFA among its three leading weaknesses, in a third of its Q3 engagements. Enforcing it and protecting what enrols it are separate jobs.

What is not established

• Whether the attack needs the user to do anything. Microsoft says yes in its vector and FAQ, Enclave says no, and both are primary.
• Whether anyone used it. Microsoft said not exploited as of 8 September and has not updated that since.
• Whether updating invalidates tokens a malicious app already obtained. Neither source says.
• Whether other broker-capable apps on Android share the pattern. Enclave tested Authenticator.
• How many devices ran an affected build, or for how long.
• Why the public research came 45 days after the fix. Neither source explains the gap.