Microsoft Authenticator flaw CVE-2026-80097 let zero-permission Android apps pose as Teams and harvest work-account tokens — Microsoft says it was patched in September
Enclave published CVE-2026-80097 details on Oct 23: zero-permission apps could harvest work tokens by posing as Teams; Microsoft says 6.2606.4246 patched it.
On Android, Microsoft Authenticator holds the sign-in credentials for every first-party Microsoft app on the device, and researcher Ofek Levin found a way around that arrangement: any app with zero Android permissions could present itself as Microsoft Teams and receive the work account’s access, refresh and ID tokens straight from Authenticator. Enclave, where Levin researched this, published the full technical write-up on October 23 under the CVE number CVE-2026-80097; Microsoft rates it CVSS 8.6. Microsoft’s own advisory record shows the CVE was published back on September 8, with the fix landing in version 6.2606.4246. So the working exploit recipe is now public, but the hole itself closed weeks ago — the news here is the disclosure, not a fresh threat.
Key points
- The flaw lived in the exported component
com.microsoft.identity.client.AccountChooserActivity: it validated the identity the caller claimed — the signature check ran against the claimed app’s installed package — while the real caller’s package name was recorded but never used in a trust decision (Enclave, October 23). - Every Android Authenticator version before 6.2606.4246 was affected; that version has been live on Google Play for a while, and Microsoft’s advisory record dates the CVE publication to September 8, 2026.
- The two sides disagree on exploitation: Enclave says no user interaction was needed beyond the broker being present with a signed-in work account (“no prompt, no warning”); Microsoft, via The Hacker News, says exploitation also required the victim to complete a sign-in step, and that it saw no real-world attacks.
Background
Microsoft calls Authenticator a “broker.” Once installed, apps like Outlook and Teams don’t each negotiate with Microsoft’s servers for tokens; they ask the broker, which signs and hands them out. The design concentrates security in one place, and the same concentration is what makes impersonating the broker valuable — every app’s tokens flow through it. Levin’s testing targeted exactly this mechanism: his malicious app impersonated Teams, the Teams chat backend, and Authenticator itself, and collected tokens in all three roles.
We’ve covered adjacent ground before. The fake calendar-invite phishing wave abused legitimate .ics data and human trust, touching no vulnerability at all; CVE-2026-80097 is the mirror image — it abused the trust between apps on the same phone, with the credentials handed over while the user, in principle, knew nothing. And our piece on why passkeys are not a trap discussed attestation: proving that a caller really is the app it claims to be is the same problem one layer down.
The facts
The core of the attack is the component’s validation logic. AccountChooserActivity is declared android:exported="true" in the manifest, so any app can invoke it. Its caller checks come down to two: getCallingActivity() must be non-null (satisfied by any startActivityForResult call), and the redirect_uri in the request must match the one derived from the claimed app’s installed signature. That claim arrives in caller-controlled intent extras — a spoofed caller.info.uid plus a broker_request_v2 JSON containing client_id, redirect_uri, scopes and more. Because Teams genuinely sits installed on the device (client ID 1fec8e78-bce4-4aaf-ab1b-5451cc387264), an attacker can rebuild a valid msauth:// redirect URI from Teams’ own SHA1 signature and the check always passes. The real caller’s package name was available via getCallingActivity().getPackageName(), but the code only logged it. Tokens — access, refresh, ID token and client_info — came back in plaintext through setResult, captured in the malicious app’s onActivityResult.
Wearing Teams’ identity, the app could obtain Microsoft Graph scopes including Mail.ReadWrite, Mail.Send, Files.ReadWrite.All, Calendars.ReadWrite, ChatMessage.Send and Sites.ReadWrite.All — in testing it could read and send mail, reach files and post Teams messages. Impersonating Authenticator itself went further: UserAuthenticationMethod.ReadWrite plus Passkey.Create and Passkey.Delete, meaning the sign-in methods on the account could be rewritten. CyberSecurityNews matches NVD on the affected range (before 6.2606.4246) and the CVSS 8.6 score; its claim that the fixed version shipped in July 2026 is single-source — Microsoft’s advisory doesn’t state a release month.
| Item | Detail | Source |
|---|---|---|
| ID and score | CVE-2026-80097, CVSS 8.6 (AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H) | NVD, published 2026-09-08 |
| Affected | Authenticator for Android < 6.2606.4246 | Enclave; CyberSecurityNews |
| Component | com.microsoft.identity.client.AccountChooserActivity (exported) | Enclave |
| Fix | 6.2606.4246 (live on Google Play) | Microsoft advisory; Enclave |
| Preconditions | Authenticator installed with a signed-in work account; the two sides disagree on whether a user step is required | Enclave; The Hacker News |
What others say
On whether exploitation needs the user to do anything, the accounts conflict. Enclave’s write-up says no interaction beyond the broker and a signed-in work account; Help Net Security’s October 27 report rendered it as “silent. No prompt, no warning, nothing to see,” and CyberSecurityNews likewise wrote that no user approval was required. The Hacker News, also on October 27, passed along Microsoft’s position: exploitation also needs the victim to complete a sign-in step in Authenticator, and Microsoft says it has not observed the flaw used in attacks. Note that the UI:R (user interaction required) in the CVSS vector is Microsoft’s own scoring. We could not load The Hacker News’ full article (the page blocks fetching), so that line comes from its front-page summary; no third party has adjudicated the disagreement yet.
The remediation guidance from both outlets is the same: update from Google Play to 6.2606.4246 or later, pin a minimum version through MDM/EMM, restrict sideloaded APKs, and watch for unusual Graph activity and token use from unfamiliar devices. Help Net Security adds the provenance: Levin did the research through Enclave’s fellowship program and followed responsible disclosure.
Our take
The gap between the dates is the real story. The CVE was numbered on September 8 and the fixed version reached Google Play around the same time, yet the full mechanics of the attack stayed private until October 23. Microsoft published no standalone announcement beyond the advisory entry, and — per The Hacker News’ paraphrase — even the exploitation conditions are disputed between vendor and researcher. The disclosure that put this on the public agenda in late October came entirely from the researcher’s side.
The one-minute action: open the Play Store on any Android phone, search Microsoft Authenticator, and check the version — at or above 6.2606.4246 you’re fine, below it, update now. Admins should add that version as the floor in MDM policy. Two caveats belong next to that advice. “Fixed in September” means devices left un-updated for the past month have been exposed to a reproducible attack path, and whether that window saw real exploitation rests on Microsoft’s “not observed” alone. And the passkey permissions Help Net Security flagged show the blast radius goes past mail: the account’s authentication methods themselves were rewriteable, which is the part of the attack surface Enclave evidently wanted the industry to see.