A malicious app on an Android phone, even one that requested no permissions at all, could pull a signed-in work account’s access tokens out of Microsoft Authenticator. The bug is tracked as CVE-2026-80097, carries a CVSS score of 8.6, and was fixed in Authenticator version 6.2606.4246 as part of Microsoft’s September 2026 Patch Tuesday. Ofek Levin, an AI security researcher at the security firm Enclave who found the bug through its fellowship program, published the technical details on October 23.
The day in tech, in one email: TLDR is the daily newsletter with links and TLDRs of the most interesting stories in startups, tech and programming.
We may earn a commission if you sign up.
The attack has a firm precondition: the rogue app must already be installed on the same device as an Authenticator that holds a work account. Phones without that combination were never exposed.
An exported activity that trusted the caller’s word
Android gates sensitive features such as contacts, storage and location behind permissions, but a component that an app marks as exported can be launched by any other app on the phone. Per Enclave’s write-up, Authenticator’s AccountChooserActivity carried that exported flag, and the only access check was that the activity had a calling activity at all. The researchers’ test app, which declared no permissions, passed it.
The caller then supplied its own identity: a package name, a client ID, a redirect URI, the scopes it wanted and a spoofed UID. The “validation” built the expected redirect URI from the installed signature of whichever app the caller claimed to be. Because the test app could read that signature from the device, the check always passed. Authenticator knew the true package name of the caller but never used it in a trust decision. On success the broker returned an access token, a refresh token, an ID token and client information in plaintext to the calling app.
What a borrowed Teams identity could reach
Authenticator on Android acts as an authentication broker, a role Enclave’s write-up uses throughout: Microsoft apps ask it for tokens on behalf of the signed-in work account, so that a user signs in once rather than in every app. The flaw turned that convenience into an open door. A refresh token, which is one of the three tokens the broker handed over, is the longer-lived credential that lets a holder obtain fresh access tokens, so what leaked was more than a single short session.
Enclave’s proof of concept posed as Microsoft Teams and asked for Microsoft Graph scopes including Mail.ReadWrite, Mail.Send, Files.ReadWrite.All, Calendars.ReadWrite, ChatMessage.Send and Sites.ReadWrite.All. The write-up says the result was full delegated access to the account’s mailbox, files and calendar, enough to read and send mail and to read and write documents.
Two further impersonations were tested. Posing as the Teams chat backend returned a user_impersonation scope, and posing as Authenticator’s own client returned UserAuthenticationMethod.ReadWrite, Passkey.Create and Passkey.Delete. The tokens belonged only to the work account signed into Authenticator on that device, not to every account on the phone.
Where Microsoft and Enclave disagree on user interaction
The conditions for the attack, as Enclave lays them out, are three: a device with Microsoft Authenticator installed at a version before 6.2606.4246, at least one work account signed into it, and a malicious app on the same device. The write-up classifies the weakness as CWE-287, improper authentication, and scores it CVSS 8.6, in the High band.
Enclave states that its attack needed “no user interaction” beyond the broker being present with a signed-in work account. The Hacker News reported that Microsoft’s position differs: the victim must also complete a sign-in step in Authenticator. The CVSS vector in the Tenable record for the flaw, AV:L and UI:R, agrees with Microsoft, marking the attack as local and requiring user interaction. The CVE description calls it improper authentication that lets an unauthorized attacker elevate privileges locally. Tenable’s page shows the record published on September 8 and updated on September 24, with an exploit prediction score of 0.00534, a low figure that fits Microsoft’s “less likely” rating.
Microsoft’s advisory, linked as the official record for CVE-2026-80097, rates the flaw Important. The Hacker News said Microsoft assesses exploitation as “less likely” and states that the flaw was neither exploited nor publicly disclosed before the fix. It had not appeared in the CISA Known Exploited Vulnerabilities catalog as of October 26.
Patched in September, disclosed in October
The timeline is compressed into a few lines. Microsoft published the CVE on September 8, 2026, the day of the month’s Patch Tuesday, a release that The Hacker News counted as a record 974 fixes and listed CVE-2026-80097 among the notable ones, without describing it as exploited. Enclave’s technical write-up followed on October 23, roughly six weeks after the fix, so a patched version was already available before the mechanics became public. Authenticator for Android at 6.2606.4246 or later contains the fix, and the report says organizations can enforce that minimum version through device management.
One question is left open by the available record. Microsoft’s advisory does not say whether installing the update revokes tokens that a malicious app may already have obtained, and neither Enclave nor The Hacker News answers it.
This article was produced with the assistance of AI and reviewed by Morning Overview editors prior to publication.
The day in tech, in one email: Get TLDR →
We may earn a commission if you sign up.
More from Morning Overview
- Ford is recalling 223,472 F-150 pickups because the fuel tank can leak or detach
- Hybrids have 15% fewer problems than gas cars, while EVs and plug-in hybrids have about 80% more, Consumer Reports finds
- Regulators cleared the first U.S. small modular reactor, 4 months early
- Lake Powell sank to a record 3,517 feet, nearing the level that stops Glen Canyon Dam’s turbines
