Authenticator Android token flaw is fixed
Microsoft fixed an Android Authenticator flaw that let a malicious app impersonate trusted software and obtain work-account tokens.
What the flaw allowed
Microsoft has fixed CVE-2026-80097, an improper-authentication vulnerability in Microsoft Authenticator for Android. According to Help Net Security’s technical summary, a malicious Android app could impersonate an installed Microsoft application such as Teams and receive tokens associated with a work account signed into Authenticator.
The malicious app did not need Android permissions in the researchers’ test. It did, however, have to be installed on the same phone. Authenticator also had to contain a signed-in work account, and the genuine Microsoft application being impersonated had to be present for the demonstrated check.
The affected range is every Authenticator for Android version before 6.2606.4246. Microsoft rated CVE-2026-80097 as Important with a CVSS 8.6 score. The fix was released in September, but Enclave researcher Ofek Levin published the detailed technique in October.
Why Authenticator trusted the wrong app
On Android, Authenticator can act as an authentication broker rather than only generating six-digit codes. Microsoft applications ask the broker for tokens that represent a user’s signed-in state and authorized access.
The vulnerable account-selection activity could be launched by another app. As the second report on AuthMask explains, Authenticator accepted caller-supplied identity details, including the application the caller claimed to be. It then compared the request’s redirect address with the signature of that named, genuinely installed application.
That validated the claimed identity instead of the application that had actually made the call. The research found that Authenticator could identify the real caller, but did not use that information when making the trust decision.
This distinction matters on any Android installation, including a degoogled phone running the affected Authenticator app. The reports describe an application-level authentication error; they do not limit the affected versions to a particular phone brand or Android distribution.
Get the next guide in your inbox
One email a week: new degoogling guides, OS and device-support news that matters, and one privacy fix you can do in five minutes. No tracking pixels.
What the test tokens could reach
By posing as Teams, the researchers’ test application obtained access and refresh tokens with delegated access to work-account resources. The demonstrated access included reading and sending email, reading or changing files and calendars, reaching SharePoint sites, and sending Teams messages.
The researchers also tested impersonating Authenticator itself. In that scenario, the returned permissions included the ability to create and delete passkeys. Help Net Security notes that an attacker who added a passkey could retain account access after the malicious phone app was removed.
There is a qualification around user interaction. Enclave reported that its demonstrated scenario needed no further interaction once the malicious app, signed-in work account, and genuine target app were present. Microsoft’s CVSS scoring treats the local attack as requiring user interaction. Both reports agree on the affected version range and the patched minimum version.
The reports say Microsoft found no evidence that the vulnerability was exploited in the wild. That does not change the update requirement now that technical details have been published.
What owners and administrators should do
- Update Microsoft Authenticator for Android and ensure the installed version is 6.2606.4246 or later. The cited guidance directs users to obtain the update from Google Play.
- If a workplace manages Android phones, require 6.2606.4246 as the minimum Authenticator version through its mobile-device-management policy.
- Treat unfamiliar sideloaded apps as a meaningful risk. The demonstrated attack required a malicious application to be installed locally even though it requested no Android permissions.
- Do not assume an app with no requested permissions is harmless. This flaw abused an exported Authenticator component and broker trust rather than protected contacts, storage, microphone, or location permissions.
People who use a degoogled phone but still depend on Microsoft work services should not overlook this patch. Removing Google services changes part of the software stack, but it does not remove vulnerabilities from third-party Android applications installed for work.