- Enclave found that Microsoft Authenticator on Android trusted what a calling app said about itself, so a no-permission app could collect work-account tokens.
- The attack needed the malicious app installed on a phone with a signed-in work account. Microsoft fixed it as CVE-2026-80097.
- Check that Authenticator for Android is at version 6.2606.4246 or later, and ask how many work devices can install apps from outside trusted stores.
A security check is only as good as the question it asks. Microsoft Authenticator asked the wrong one. It asked whether a request looked like it came from Teams. It did not ask whether Teams was the app making it. Once installed on a phone with Authenticator and a signed-in work account, an Android app with no permissions could collect sign-in tokens.
What Enclave found
Security firm Enclave reported that an Android app holding no permissions could pose as any Microsoft app installed on the phone. Authenticator would then give the impostor that app's tokens. Enclave says the researcher was Ofek Levin, working in its fellowship program.
The conditions were narrow. The phone needed Authenticator and one signed-in work account. Enclave says nothing more was required from the user.
Enclave ran three impersonations. Posing as Teams and requesting Microsoft Graph access returned scopes that included Mail.ReadWrite, Mail.Send, Files.ReadWrite.All, Calendars.ReadWrite and Sites.ReadWrite.All. Enclave says that gave full delegated access to the mailbox, files and calendar.
Posing as Authenticator's own client returned scopes that cover changing sign-in methods, including Passkey.Create and Passkey.Delete. Help Net Security says an attacker able to add a passkey could keep access after the malicious app is removed. The sources do not say Enclave tested this. They show the scopes were returned, not that a passkey was added or that access persisted.
How the flaw worked
Authenticator does more than show codes. On Android it also works as a broker. When Teams or Outlook needs a sign-in, it asks Authenticator, which returns a token. A token is a digital pass that proves the user is logged in.
Enclave says one Authenticator screen, AccountChooserActivity, was marked as exported. That means any app on the phone can open it. The only gate was a check that some app had launched it.
Everything describing the requester came from the caller. Enclave says it wrote the app name, package name, client ID, redirect address and scopes itself.
Authenticator did run a validation. It looked up the signature of the package the caller named, worked out the redirect address that package should use, and compared it with the one sent.
That sounds strong, but Enclave explains the weakness. Teams is installed on the phone, and any app can read its genuine signature. The researchers copied the right answer into the request. Enclave says the check always passes.
The tokens came back as readable text to the calling app. Enclave lists the access token, refresh token and ID token.
Authenticator also knew who was really calling. Enclave says the code read that caller's package name but used it only to track parallel requests. The screen held two answers to "who is asking" and trusted the one the caller supplied.
The limits on the risk
Help Net Security stresses that the attack still needed a malicious app on the device. The user would have to be tricked into installing it. After that, it says, the theft was silent, with no prompt or warning.
Microsoft confirmed the issue and fixed it. The CVE, CVE-2026-80097, was published on September 8, 2026 with a CVSS score of 8.6, rated High. Authenticator for Android versions earlier than 6.2606.4246 are affected.
The lesson for leaders
This shows a common design mistake. A system checks facts the requester can supply, not facts it can observe for itself. A passport check that only compares the photo with the name on the form works the same way. The paperwork is consistent, and nobody checks the person.
It matters because Authenticator sits at the center of work identity. A weakness in a broker affects every app that relies on it. Strength of sign-in at the moment of login does not help when the tokens of an already signed-in account can be taken afterwards.
The exposure sits on staff phones. In our view, any phone that holds a work account and can install apps from outside trusted stores widens the chance of someone installing the wrong app.
What to ask your team
Ask whether Authenticator for Android is at version 6.2606.4246 or later on every device with a work account. Help Net Security advises enforcing that minimum through mobile device management.
Ask how many devices with work accounts can install apps from outside trusted stores. Ask whether anyone reviewed sign-in method changes, including new passkeys, on accounts used from Android phones before the patch.
Last, ask vendors that act as sign-in brokers one plain question: does the code decide trust from who is calling, or from what the caller says? A patched flaw is a good prompt to ask.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Enclave.
