A high-severity security vulnerability has been disclosed in Microsoft Authenticator for Android that could allow a malicious application installed on the same device to steal Microsoft 365 authentication tokens. Tracked as CVE-2026-80097, the flaw carries a CVSS score of 8.6 and affects the broker component responsible for issuing sign-in tokens to other Microsoft applications on Android. Microsoft fixed the problem in September 2026, but Android devices still running older versions of Authenticator remain exposed.
What makes the vulnerability particularly concerning is that the malicious application does not need special Android permissions, the user's password or any additional approval. By impersonating a trusted Microsoft application such as Teams, malware on the same device could potentially obtain access, refresh and ID tokens belonging to the user's Microsoft 365 account.
The Vulnerability Is Tracked As CVE-2026-80097
CVE-2026-80097 is classified as an improper authentication vulnerability within Microsoft Authenticator's broker component. This broker exists to help Microsoft applications obtain authentication tokens without requiring users to repeatedly enter their credentials.
The problem was that the requesting application was not being verified strongly enough. A malicious application could therefore present itself as a trusted Microsoft app and submit a sign-in request that Authenticator treated as legitimate.
Instead of rejecting the request, the vulnerable version could return authentication tokens that belonged to the signed-in work account.
The Attack Does Not Require Android Permissions
One of the most serious aspects of the vulnerability is that the malicious application does not need to request sensitive Android permissions before attempting the attack. This makes the threat harder for users to identify because they would not necessarily receive an obvious warning that an installed application was attempting to access Microsoft 365 information.
The attack also does not require the user to confirm the authentication request. No additional credentials need to be entered, and there is no separate approval prompt that would alert the account owner.
From the user's perspective, the malicious application could therefore attempt to steal authentication material with very little visible activity.
The Malicious App Pretends To Be A Trusted Microsoft Application
The attack works by abusing the relationship between Microsoft Authenticator and other Microsoft applications installed on the same Android device. A malicious app can send a request while pretending to be something trusted, such as Microsoft Teams.
Because the vulnerable Authenticator broker does not properly confirm the requesting application's identity, it can mistakenly treat the request as legitimate. The application may then receive tokens intended for the real Microsoft service.
This turns a local malicious app into a potential route towards Microsoft 365 cloud access.
Access Tokens Could Provide Immediate Cloud Access
An access token allows an application to access Microsoft 365 resources after a user has already authenticated. If an attacker steals a valid token, they may be able to interact with cloud services without knowing the user's password.
This is why token theft has become such an important security concern. Traditional protections such as strong passwords are much less useful if an attacker can steal the proof that authentication already happened.
Depending on the permissions associated with the token, the attacker could potentially access information belonging to the compromised account.
Refresh Tokens Make The Situation More Serious
The vulnerability can also expose refresh tokens, which are particularly valuable because they may allow an attacker to obtain new access tokens after the original one expires.
An access token generally has a limited lifetime. A refresh token can potentially extend the attacker's access without requiring the user to authenticate again.
That makes refresh-token theft particularly concerning because simply waiting for the first token to expire may not remove the attacker from the environment.
During an incident, organisations may therefore need to revoke existing sessions rather than relying only on password changes.
ID Tokens May Also Be Exposed
The vulnerable broker can additionally provide ID tokens, which contain information about the authenticated user's identity and the sign-in session.
While these tokens serve a different purpose from access tokens, they are still part of the authentication process and should not be exposed to an untrusted application.
The fact that access, refresh and ID tokens can all potentially be obtained demonstrates that the vulnerability affects a fundamental trust relationship inside Microsoft's Android authentication flow.
Microsoft Graph Could Become Accessible
The stolen authentication tokens may allow access to Microsoft 365 information through Microsoft Graph, depending on which application the malicious software impersonates and which permissions are associated with the session.
Microsoft Graph provides access to a huge range of Microsoft 365 services through a common API. This can include Outlook email, calendars, OneDrive files, SharePoint content and Teams information.
A compromised token therefore has the potential to expose much more than one isolated application.
Researchers Demonstrated Email Access
Researchers were reportedly able to demonstrate the attack by impersonating Microsoft Teams. Tokens obtained through that method could then be used to access Microsoft 365 resources.
The demonstrated capabilities included reading and sending emails, accessing files and modifying calendar entries. Those actions alone could provide attackers with valuable corporate information and opportunities to impersonate the legitimate user.
Email access is particularly serious because compromised mailboxes can be used to conduct further phishing attacks from an account colleagues already trust.
OneDrive And SharePoint Data Could Also Be At Risk
Microsoft 365 is frequently used as an organisation's primary document collaboration platform. OneDrive and SharePoint may contain internal documents, project information, contracts and other sensitive corporate material.
If stolen tokens provide access through Microsoft Graph, those repositories may become reachable without the attacker ever obtaining the user's actual password.
The impact will depend on the permissions assigned to the affected account, but even an ordinary employee account can contain information useful for further attacks.
Teams Access Could Help Attackers Impersonate Employees
Compromise of Microsoft Teams could create another route for social engineering. Attackers operating through a legitimate employee identity may be able to view conversations or potentially send messages that appear to come from the real user.
Colleagues are much more likely to trust a request arriving through an existing corporate Teams account than an unsolicited message from an unknown source.
This creates opportunities for attackers to request credentials, encourage users to open malicious files or gather additional information about the organisation.
Token theft can therefore become the beginning of a much larger attack rather than the final objective.
Calendar Manipulation Can Also Have Security Consequences
Calendar access may appear less dangerous than email or file access, but it can still provide useful intelligence. Corporate calendars can reveal meetings, travel plans, executives' schedules and internal project activity.
Attackers could also modify calendar entries, potentially inserting malicious links or creating fake meetings designed to trick other employees.
When combined with access to email and Teams, calendar information can help attackers build extremely convincing impersonation attempts.
The Vulnerability Requires A Malicious App On The Same Device
The attack cannot be launched remotely against Microsoft Authenticator by itself. A malicious application first needs to be installed on the same Android device as the vulnerable Authenticator app.
That requirement provides an important layer of protection, but it does not eliminate the risk. Android malware frequently reaches devices through unofficial application stores, sideloaded APKs, malicious links and applications disguised as legitimate utilities.
Organisations allowing employees to install applications from unrestricted sources may therefore face greater exposure.
Work Accounts Are The Primary Concern
The affected configuration involves Microsoft Authenticator for Android with a signed-in work account. This makes the vulnerability particularly relevant to businesses using Microsoft 365, Entra ID and Authenticator across managed Android devices.
Corporate mobile devices often contain access to email, Teams, OneDrive and other services that attackers value highly. A compromise therefore has implications beyond the smartphone itself.
Organisations managing Android fleets should verify Authenticator versions centrally rather than depending entirely on employees to update the application themselves.
All Versions Before 6.2606.4246 Are Affected
The fixed version is Microsoft Authenticator for Android 6.2606.4246.
Any affected Android device running an earlier release should be considered vulnerable and updated as soon as possible.
Microsoft released the corrected version in September 2026, meaning many users may already have received the update automatically. However, organisations should not simply assume that every device has updated successfully.
Older phones, disabled automatic updates or devices rarely connected to the Play Store may still be running vulnerable builds.
Organisations Should Verify Versions Through MDM
Businesses managing Android devices through mobile device management should use those tools to confirm which version of Microsoft Authenticator is installed.
Platforms such as Microsoft Intune can provide administrators with visibility into managed applications and device compliance. Organisations can use this information to identify devices still running versions earlier than 6.2606.4246.
This is considerably more reliable than sending an email asking employees to check manually and hoping everyone completes the task.
Automatic Application Updates Should Be Enabled
Enabling automatic updates on managed Android devices can significantly reduce exposure to vulnerabilities like this one. Once Microsoft releases a fixed Authenticator version, devices can receive it without requiring individual users to take action.
Automatic updates are particularly useful for applications involved in authentication and security because delaying updates can leave a direct path into corporate services.
Organisations may still need to test certain business-critical applications carefully, but security apps should generally remain as current as possible.
Avoid Installing Applications From Unofficial Sources
The attack depends on malicious software already being present on the Android device. Restricting application installation to trusted sources therefore reduces the likelihood that the vulnerability can be exploited.
Organisations should consider blocking installation from unknown sources on managed corporate devices. Users should also avoid downloading APK packages from random websites or unofficial application stores.
A seemingly harmless utility can become significantly more dangerous when vulnerabilities allow it to interact with trusted authentication software.
This Attack Shows Why App Sandboxing Is Not Enough
Mobile operating systems normally isolate applications from each other. One app should not simply be able to read another application's private data or authentication secrets.
CVE-2026-80097 demonstrates how a legitimate communication mechanism between apps can still become an attack path when authentication between those apps is weak.
The malicious application does not need to break Android's entire security sandbox. Instead, it abuses a trusted interface by convincing Microsoft Authenticator that it is something else.
That makes application identity verification just as important as operating-system permissions.
Multi-Factor Authentication Does Not Automatically Stop Token Theft
Microsoft Authenticator is widely deployed specifically because organisations want stronger multi-factor authentication. However, this vulnerability demonstrates that even an MFA application can become part of an attack path.
The attacker does not necessarily need to defeat the user's MFA challenge directly because the vulnerable broker may provide tokens after the user has already authenticated.
This highlights an important distinction between stealing credentials and stealing authenticated sessions.
MFA remains extremely valuable, but organisations also need controls capable of detecting suspicious token use after authentication has occurred.
Monitor Microsoft Graph Activity
Organisations should monitor for unusual Microsoft Graph activity associated with their users. Unexpected access to email, files or calendars may indicate that tokens are being used by something other than the legitimate application.
Security teams should pay particular attention to behaviour that does not match a user's normal working pattern. Large numbers of file downloads, unusual mailbox activity or unexpected Graph requests could justify further investigation.
Cloud activity monitoring becomes increasingly important as attackers shift from stealing passwords towards stealing valid authentication tokens.
Watch For Unexpected Application Consent Grants
Unexpected application consent should also be investigated. Attackers sometimes attempt to establish longer-term access by convincing users or administrators to grant permissions to malicious applications.
Although CVE-2026-80097 is specifically a token-theft vulnerability, unusual consent activity may indicate that an attacker is attempting to expand or preserve access after compromising an account.
Organisations should regularly review which applications have been granted access to Microsoft 365 data and remove permissions that are no longer required.
Unfamiliar Android Devices Should Raise Attention
Security teams should also watch for authentication tokens being used from unfamiliar Android devices. A user who normally signs in from one corporate phone suddenly appearing from another device or unusual environment may warrant investigation.
Device identity alone is not proof of compromise, particularly when users replace phones or travel. However, it becomes much more significant when combined with other suspicious activity.
Risk-based Conditional Access policies can help detect and respond to these types of unusual sessions automatically.
Suspicious Sessions Should Be Revoked
If an organisation identifies suspicious activity involving an affected account, revoking active sessions should be part of the response.
Changing the user's password alone may not immediately invalidate every token that has already been issued. An attacker could potentially continue accessing cloud resources until those sessions expire or are explicitly revoked.
Administrators should therefore invalidate suspicious sessions, review account activity and determine whether any additional persistence mechanisms were created.
Password Resets Alone May Not Be Enough
Token theft fundamentally changes how defenders need to think about account compromise. Traditional incident response often begins with resetting the user's password, but stolen session tokens may remain usable even after the underlying credential changes.
This is why token revocation has become increasingly important in Microsoft 365 incident response.
Security teams should treat a confirmed token theft incident as a cloud session compromise rather than simply a password compromise.
That means reviewing all relevant authentication sessions and connected applications.
Microsoft Fixed The Vulnerability Before Full Technical Disclosure
Microsoft published the vulnerability record on 8 September 2026 and released the corrected Authenticator version around the same period. Researchers later published more detailed technical information on 23 October 2026.
This sequence gave organisations an opportunity to update before the attack mechanics became widely known.
Now that technical details are public, remaining vulnerable devices deserve greater attention because malicious developers have more information available to reproduce the attack.
Mobile Application Security Is Becoming Part Of Cloud Security
The vulnerability also demonstrates how closely mobile security and cloud security are connected. A malicious application installed on one Android phone can potentially become a route into corporate Microsoft 365 services hosted far away in the cloud.
Protecting the Microsoft tenant therefore requires more than securing servers and cloud configurations. The endpoint generating authentication tokens is part of the same security boundary.
This is why mobile device management, application control and cloud identity monitoring increasingly need to operate together.
Managed Devices Provide Better Visibility
Organisations using managed Android devices have an advantage because administrators can enforce minimum application versions, restrict sideloading and monitor device compliance centrally.
Bring-your-own-device environments can be more complicated because the organisation has less control over which applications are installed and how quickly security updates are applied.
Conditional Access can help by requiring compliant or managed devices before allowing access to sensitive Microsoft 365 resources.
The more valuable the information being accessed, the stronger these device requirements should become.
The Vulnerability Reinforces The Principle Of Least Privilege
Even if an attacker successfully steals a user's tokens, the damage is still influenced by what that account is allowed to access.
Users should therefore receive only the Microsoft 365 permissions required for their roles. Broad SharePoint access, unnecessary administrative rights and excessive application permissions increase the impact of any account compromise.
Least privilege cannot prevent the initial token theft, but it can significantly limit what an attacker can do afterwards.
Final Thoughts
CVE-2026-80097 is a significant Microsoft Authenticator vulnerability because it targets something organisations normally depend on to strengthen account security. A malicious Android application on the same device can impersonate a trusted Microsoft application and potentially obtain Microsoft 365 access, refresh and ID tokens without requesting Android permissions, additional user approval or the user's credentials.
Those tokens may provide access through Microsoft Graph to services such as Outlook email, calendars, OneDrive, SharePoint and Teams. Researchers demonstrated that impersonating Microsoft Teams could allow stolen tokens to be used for activities including reading and sending emails, accessing files and modifying calendar entries.
Microsoft fixed the vulnerability in Authenticator for Android version 6.2606.4246, so the most important action is ensuring every affected device has been updated to that release or later. Organisations managing Android fleets should verify this centrally through MDM rather than simply assuming automatic updates have worked.
They should also restrict applications from unofficial sources, enable automatic updates and monitor Microsoft 365 for unusual Graph activity, unexpected consent grants and suspicious token use. If compromise is suspected, active sessions should be revoked rather than relying solely on a password reset.
The vulnerability is a useful reminder that authentication security no longer ends once MFA succeeds. In a cloud environment, the authentication token itself can be just as valuable as the password — and sometimes even more so.
Comments 0