ItInsightsWorld Security Brief: Malicious Android Apps Can Abuse Microsoft Authenticator to Steal Microsoft 365 Tokens (CVE-2026-80097)

Identity brokers sit at a busy crossroads of mobile security: they are trusted to validate users, then they hand access to services. CVE-2026-80097 exposes what happens when that trust is not paired with a reliable way to confirm which app made the request. The issue affects Microsoft Authenticator on Android and turns a convenience feature into a possible token-theft path for malicious applications that pretend to be installed Microsoft apps. For ItInsightsWorld Security readers, the practical lesson is simple: an approved sign-in can still be weaponized if the requesting app is allowed to assert its own identity.

Microsoft Authenticator serves two roles. In one mode, it acts as a 6-digit code generator for time-based one-time passwords. In another mode, it acts as an authentication broker for Microsoft applications: after the user confirms a request, the user can sign in to an enterprise account and reach Microsoft 365 resources. That second role is where CVE-2026-80097 becomes dangerous.

The vulnerability lives in a Microsoft component exposed to other apps for authentication calls. Research shows the calling application could provide the app name, package name, client ID and redirect address inside the request. Microsoft Authenticator would then evaluate the redirect against the identity claimed in the request, rather than verifying the identity of the application that actually launched the call. In other words, the broker could be told who the caller was, instead of discovering it independently.

The attack path can be understood as a false-label problem. If a malicious Android app claims to be Microsoft Teams and Teams is already installed on the device, the claimed identity may match a real signature and a real redirect address stored on the device. Microsoft Authenticator can accept the claim and return a real token to the actual request originator: the malicious app. The malicious app does not need to become Teams; it only needs to describe itself convincingly enough to satisfy the broker’s check.

According to the disclosure by security researcher Ophi Kleven, this pattern can produce broad access to a victim’s Microsoft 365 data. When impersonating Microsoft Teams, a successful request can obtain delegated permissions in Microsoft Graph. Those permissions can include reading and sending email, accessing files, modifying calendar items, sending Microsoft Teams messages, and manipulating SharePoint content. An access token can be used directly against the corresponding resources, while a refresh token can be exchanged for new access tokens during its validity period. The result is not merely passive viewing of data; it can become ongoing, programmatic control over a user’s collaboration footprint.

There is an account-security dimension as well. The research also reports that an attacker exploiting this flaw could manage the user’s authentication methods and create or delete passkeys. That expands the impact from confidentiality and integrity of data into the security controls that protect the account itself.

Microsoft addressed the issue with version 6.2606.4246, released on September 8. The affected range is Android Microsoft Authenticator 6.0.0 to 6.2606.4246. Kleven responsibly notified Microsoft before publication. To reduce risk for users who had not yet upgraded, the researcher withheld technical details until 50 days after the fix. The disclosure note also expects that some attackers will now look for ways to reuse this class of flaw, making cleanup and prevention important for organizations that may have devices or accounts exposed before patching.

Risk view: what changed and what did not

Expected security property	What CVE-2026-80097 weakens	Why it matters for enterprise identity
An authentication broker should know the actual requester, not only its self-reported label.	The request can include app name, package name, client ID and redirect address.	A malicious app can ride on the reputation of a genuinely installed Microsoft application.
Redirect checks should prove authorization of the calling app.	The redirect is checked against the claimed identity, while the real caller may differ.	Approval may result in token delivery to the wrong app.
Consent should be limited to the data scope of the authenticating flow.	Delegated Microsoft Graph permissions can be obtained through a disguised request.	Email, files, calendars, Microsoft Teams messages and SharePoint content can be reached.
Account credential management should remain bound to a trusted client.	Authentication methods and passkeys could be managed after exploitation.	Token abuse can become persistent access control abuse.

Security checklist for admins and users

The checklist below focuses on actions that can be taken without waiting for a perfect forensic picture.

• Confirm whether Microsoft Authenticator on Android is below 6.2606.4246. Devices running versions in the 6.0.0 to 6.2606.4246 range should be prioritized for the September 8 fix.
• Upgrade affected installs to 6.2606.4246 or a later build, then document the patch date.
• Review recently installed Android apps on company-managed or BYOD devices and remove apps whose origin is unclear.
• For accounts suspected of pre-patch exposure, inspect authentication methods and passkeys. The research says the flaw can affect these controls.
• If unknown authentication methods, unfamiliar passkeys or unexpected device associations appear, treat them as possible evidence of abuse and revoke access according to your incident-response process.
• Review token scopes and application access related to Microsoft Graph, Microsoft 365, Microsoft Teams and SharePoint for unusual patterns.
• Reduce the opportunity for untrusted apps to reach the broker by limiting installation sources and requiring managed devices for sensitive identity flows.
• Communicate that a 6-digit code workflow and an authentication-broker workflow are different risk surfaces; staff should not assume a legitimate-looking prompt is always initiated by the app the user is using.

Common misconceptions

A useful way to judge the incident is to separate what the vulnerability does from what people often assume.

• Misconception: CVE-2026-80097 is only another weak password or 6-digit code problem. What the disclosure describes is a trust gap in an authentication-broker flow; the 6-digit code is a separate function.
• Misconception: patching alone erases every consequence. The September 8 update closes the flaw, but the research explains that a refresh token could remain useful during its validity period, so organizations should still consider token and account review after possible exposure.
• Misconception: only Microsoft Teams is at risk. Teams is used as the example because it may already be installed and has a valid identity on the device. The core problem is that the broker could be given a claimed identity, not that Teams itself is the only target.
• Misconception: the impact stops at reading email. Delegated Microsoft Graph access can include sending messages, modifying calendar entries, manipulating SharePoint content and managing authentication methods or passkeys.
• Misconception: user approval proves the request came from the app the user trusts. Approval may occur even when the actual caller is a malicious Android app that has claimed the identity of another installed Microsoft application.

FAQ

What is CVE-2026-80097 in plain security terms?

It is a vulnerability in Microsoft Authenticator on Android that could allow one app to obtain Microsoft tokens by pretending to be a different, already-installed Microsoft app.

Which versions are affected?

The affected range is Android Microsoft Authenticator 6.0.0 to 6.2606.4246. Version 6.2606.4246 is the September 8 fixed release mentioned in the disclosure.

Why mention September twice?

September gives the broader fix month from the original disclosure summary, while September 8 gives the exact release date used in the technical write-up.

Why were details published after 50 days?

Researchers delayed public details until 50 days after the fix to avoid endangering users who had not yet updated Microsoft Authenticator.

Can this lead to long-term access?

The disclosure says a refresh token could be used to obtain new access tokens during its validity period, and that authentication methods and passkeys could be managed by an attacker.

Does the flaw affect the 6-digit TOTP feature directly?

The core report centers on the authentication-broker role, where a request identifies an app by name, package name, client ID and redirect address. The 6-digit code function is described as a separate role of Microsoft Authenticator.

Action recommendations

For enterprise readers, the response should be split into three time windows: immediate exposure, suspected compromise and longer-term app design.

Immediate exposure

1. Inventory Android Microsoft Authenticator builds and upgrade anything in the 6.0.0 to 6.2606.4246 range to 6.2606.4246 or later.
2. Identify users or devices that may have installed untrusted apps before the fix.
3. Review authentication methods and passkeys for unexpected changes.

Suspected token abuse

1. Revoke refresh tokens and access paths that are not associated with approved sessions or approved Microsoft apps.
2. Look for abnormal email, file, calendar, Microsoft Teams message or SharePoint activity that matches the delegated permissions discussed in the disclosure.
3. Re-verify users before restoring Microsoft 365 access from devices with uncertain app provenance.

Longer-term practice

1. Treat app identity assertions as untrusted until verified by a stronger platform signal.
2. Prefer managed-device or installation-restriction controls for employees who use Microsoft Authenticator for corporate Microsoft 365 sign-in.
3. Document broker flows and token scopes so security teams know what a disguised request can reach.

CVE-2026-80097 is small in code terms but large in consequence: a mobile identity helper that users rely on can become a token handoff mechanism if it trusts an app’s self-description. For Android environments, Microsoft Authenticator users and enterprise security teams now have a concrete patch deadline, a clear version threshold and a warning about delayed disclosure. The practical takeaway from this ItInsightsWorld Security briefing is to move from “update available” to “update applied, reviewed and verified,” especially when authentication flows can lead to Microsoft Graph, Microsoft 365, Microsoft Teams and SharePoint access.