Researchers at Enclave have described how an Android app with no permissions could ask Microsoft Authenticator for sign-in tokens by claiming to be another Microsoft app, and receive them. Microsoft has fixed the flaw as CVE-2026-80097, and the affected builds are every Authenticator for Android release before version 6.2606.4246.
What Enclave reported
Enclave published the research on October 23, 2026, in a post by Ofek Levin, an AI security researcher at the company, written as part of its fellowship program. The setup it describes is an Android phone with Authenticator installed and one work account signed in. On Android, Authenticator does more than generate codes. It also acts as the broker that hands tokens to other Microsoft apps such as Teams, so those apps do not each have to run their own sign-in.
According to Enclave, one screen inside Authenticator could be launched by any other app on the device, and the broker never used the identity of the app that launched it when deciding whether to trust the request. In the post, Levin writes: “The caller’s identity was never used for any trust decision, so a single exported activity handed out tokens for the work account.”
Enclave says Authenticator did run a check, and that the check compared the request against the signature of the Microsoft app being claimed. Because that app was installed on the same phone, its genuine signature was available to read, so the comparison passed. The post says the broker did know who was really calling, and used that information only for bookkeeping on parallel requests. This article leaves out the request details on purpose. The CVE identifier and Enclave’s write-up are the references for defenders who need the technical record.
What the stolen tokens could reach
The post lists the flaw as an Authenticator elevation of privilege vulnerability, rated CVSS 8.6 (High) and classed as CWE-287, improper authentication. Enclave says a successful request returned the access token, refresh token and ID token in plaintext to the app that made the request, which could read them directly.
Enclave tested three disguises and lists the scopes each one returned. Posing as Teams and asking for Microsoft Graph produced scopes including Mail.ReadWrite, Mail.Send, Files.ReadWrite.All, Calendars.ReadWrite, ChatMessage.Send and Sites.ReadWrite.All. In the researchers’ tests, those tokens gave full delegated access to the mailbox, files and calendar. Posing as the Teams chat backend returned a user impersonation scope. Posing as Authenticator itself returned scopes named UserAuthenticationMethod.ReadWrite, Passkey.Create and Passkey.Delete.
Enclave states that the test needed no user interaction beyond having the broker present with a signed-in work account. The attack still required a malicious app to be installed first, and Enclave does not claim otherwise. It also does not report any use of the flaw against real organizations, and this article does not either.
The timeline matters for patch planning. Enclave says it reported the issue to the Microsoft Security Response Center, which confirmed it, fixed it in Authenticator for Android and published CVE-2026-80097 on September 8, 2026. Enclave’s public post followed on October 23, about six weeks later. Phones that update Authenticator through the Google Play Store may already be on a fixed build. Phones that do not update automatically, or that run managed builds, are where an old version can linger.
What it means for the security leader
A token broker sits on the path of every Microsoft sign-in on a phone, so a flaw in it reaches further than a flaw in a single app. In our reading, the passkey scopes deserve the first audit. A token that can create a passkey on a work account could, in principle, change how that account signs in, which makes the review of authentication methods a separate task from rotating tokens.
Token theft is already a theme on this site. Huntress reported token replay reaching 79 Microsoft 365 organizations without a password, and the defender problem is the same here, because a stolen token lets an attacker act before anyone sees a sign-in alert. Enclave’s tests describe silent token theft on the device, so detection has to come from the identity provider’s logs rather than from a prompt the user sees.
The second lesson concerns agents and automation. Our opinion desk has argued that software acting for a user should hold its own identity with minimal rights, and the Authenticator case shows what happens when one component answers for many apps. See our opinion on giving every AI agent its own identity and starting it with no permissions for that argument in the agent setting.
The gap between the September 8 fix and the October 23 post gives fleet owners a simple test. Managed devices should have updated during those six weeks, so any phone still on an older build when the post appeared points to a gap in how the organization enforces mobile app versions, and closing that gap helps with every app that holds work credentials.
What to do now
- Check the Authenticator version on every Android device that signs in to work accounts. Anything older than 6.2606.4246 is affected.
- If you run mobile device management, set 6.2606.4246 as the minimum allowed version for Authenticator and report devices that fall below it.
- Review the authentication methods registered on work accounts, with attention to passkeys added since the fix date of September 8, and remove any that the owner does not recognize.
- Review sign-in and token activity for Microsoft 365 accounts used from Android devices that ran an old build, and revoke sessions for any account that shows activity the user cannot explain.
- Keep sideloaded and unfamiliar apps off devices that hold work accounts, since the attack needed a malicious app on the phone.
The official identifier for the fix is CVE-2026-80097, and the research is in Enclave’s post. Neither describes exploit steps, and defenders do not need them to act.
Source: Enclave, AuthMask research post
