Microsoft Authenticator Android: token theft without permissions

A vulnerability in Microsoft Authenticator for Android allowed an app installed on the same phone, with no permissions and no user interaction, to obtain access tokens for the user’s Microsoft work account. The news was reported on 27 October 2026 by Help Net Security and The Hacker News, and the following day by heise Security. The flaw has already been fixed: it is tracked as CVE-2026-80097 and affects versions earlier than 6.2606.4246.

The available technical details come mainly from the Help Net Security article, the only one whose full text we were able to read; for the other two outlets we have the headline, which confirms the core point: apps without permissions able to steal work account tokens.

Authenticator’s role as a broker

On Android, Authenticator does more than display one-time codes. It acts as an authentication broker: when Teams, Outlook or another Microsoft app needs to sign the user in, it asks Authenticator for a token, which Authenticator issues on behalf of the account registered on the device. Precisely because it guards access to the entire account, the broker is supposed to check rigorously which app is requesting a token.

According to Help Net Security, researcher Ofek Levin, from Enclave’s fellowship program, found that this check did not hold:

• one Authenticator component could be invoked by any app on the device;
• when asked for a token, Authenticator trusted the identity declared by the calling app;
• the intended check compared the request details with those of the legitimate Microsoft app installed on the phone, but those details are readable by any app, and therefore easy to imitate;
• Authenticator knew the real identity of the caller, but did not use it to decide whether to trust the request.

In practice, a malicious app could introduce itself as Teams and receive the tokens meant for Teams. This is a well-known pattern in Android apps that expose components to other apps: the operating system makes it possible to know who is calling, and security depends on the component actually using that information rather than the data supplied by the caller.

What the tokens allowed

Help Net Security reports that, with a single work account registered in Authenticator, the researchers’ test app obtained tokens that made it possible to:

• read and send email from the victim’s mailbox;
• read and modify files, calendar and SharePoint sites;
• send Teams messages as the victim;
• by posing as Authenticator itself, change the account’s sign-in methods, including creating and deleting passkeys.

The last point is the most sensitive: a passkey added by the attacker lets them keep accessing the account even after the malicious app has been removed from the phone. According to the same source, the theft was silent: no confirmation prompt and no warning for the user.

The attack’s limit is its starting point: a malicious app must be installed on the device, so a user has to be tricked into installing it. Help Net Security does not report any real-world exploitation.

In MITRE ATT&CK terms (our classification, not the sources’), the chain maps to theft of application tokens on mobile (T1635, Steal Application Access Token), their use as alternate authentication material (T1550.001) and persistence by changing the account’s sign-in methods (T1098, Account Manipulation).

Fix and severity

Enclave reported the flaw to Microsoft through responsible disclosure. Microsoft confirmed it and published the fix on 8 September 2026, with a CVSS score of 8.6. All versions of Authenticator for Android earlier than 6.2606.4246 are vulnerable. The sources do not indicate any impact on Authenticator for iOS.

Impact for European and Italian organisations

Authenticator is widely used as a second factor and as a broker for Microsoft 365, including on personal phones used for work (BYOD), where the company has little control over what gets installed. A token stolen this way gives access to mail, documents and Teams without going through the sign-in, and the added passkey survives a clean-up of the phone.

For NIS2 entities, multi-factor authentication is one of the required measures: this vulnerability is a reminder that the second factor must be managed like any other software, with updates and enforced minimum versions. A compromised account with access to mail and documents can turn into a significant incident, with the notification deadlines to CSIRT Italia set by Legislative Decree 138/2024 for Italian entities.

What to do now

• Update Microsoft Authenticator on Android to version 6.2606.4246 or later and check the version actually installed on company devices.
• If you manage devices with an MDM, enforce the minimum version of Authenticator and roll out the update through managed Google Play.
• Block installation from unknown sources (sideloading), at least in the work profile, and restrict the apps that can be installed on managed devices.
• Review the authentication methods registered on accounts, especially passkeys recently added or deleted: in the Microsoft Entra ID audit logs, look for registrations of new security methods that cannot be traced back to the user.
• If an account is in doubt, remove unrecognised methods, revoke active sessions and ask the user to sign in again from an updated device.
• Remind users to install apps only from trusted stores: the vulnerability still required a malicious app on the phone.

Last updated: 28 October 2026