Microsoft Authenticator Token Theft: What CVE-2026-80097 Means for Identity Security

Microsoft has fixed an Android vulnerability that allowed a malicious application to obtain work-account tokens through Microsoft Authenticator. CVE-2026-80097 affects the authentication broker, a component that helps applications sign users in and obtain tokens for Microsoft services.

For Microsoft 365 teams, the immediate action is to confirm that Authenticator has updated. The wider question is whether the organization can investigate and contain misuse of an identity after a legitimate sign-in. MFA coverage alone cannot answer that question.

Microsoft published the advisory on September 8, 2026. It assigns a CVSS 3.1 score of 8.6 and an Important severity rating. The fixed Android build is 6.2606.4246; Microsoft's September 15 revision corrected the build number. Ofek Levin at Enclave published the AuthMask research on October 23. As checked on October 27, Microsoft's advisory lists exploitation as No. That is Microsoft's reported status, rather than proof that no compromise has occurred.

How the broker trusted the wrong application

Authenticator does more than generate codes or approve MFA requests. On Android, its broker helps applications obtain tokens and share a sign-in experience. That makes the requesting application's identity part of the security decision.

Enclave found that an exported Android activity accepted identity details supplied by the caller. Validation checked the claimed application's package and redirect information without establishing that the caller was that application. In the Teams example, the genuine application was also installed on the device.

The researcher reported receiving access and refresh tokens, with delegated permissions covering mail, files, calendars, and SharePoint. Impersonating Authenticator's client returned authentication-method and passkey-related scopes. Those reported scopes should not be described as unrestricted tenant administration or proof that every possible authentication-method change would succeed.

The attack required a malicious app on an affected device with a work account signed into Authenticator. Enclave's proof of concept needed no Android permissions and no further user interaction in its tests. Microsoft's advisory describes convincing the user to complete an authentication flow. That difference remains material: permission-free does not mean the attack works without first getting an app onto the device.

Why MFA remains necessary

The vulnerable component was deciding which application could receive tokens for an authenticated account. A stronger sign-in method cannot, by itself, correct an application-identity validation flaw in that component.

Access tokens authorize requests to a particular resource within their granted permissions. Refresh tokens can be used to request further tokens, subject to the identity platform's checks. Neither should be treated as an unrestricted credential that works against every service.

Phishing-resistant MFA still reduces exposure to credential phishing. This disclosure gives organizations another reason to review the applications and devices involved in token acquisition, and the response available when tokens are obtained by the wrong application. It does not establish that every Conditional Access policy or phishing-resistant sign-in method can be bypassed.

Check the update and the limits of your mobile visibility

Start by establishing which Android devices use Authenticator for work accounts and whether they run build 6.2606.4246 or a later supported version. The fixed build is a minimum remediation reference, not a reason to hold devices on an older release when a newer update is available.

Use the application inventory and deployment information your management approach actually provides. For enrolled devices, check update deployment and reported application versions where available. For personal devices protected only through application protection policies, establish what you can verify before claiming that the affected population is patched. Ask users to confirm the installed version where central evidence is unavailable.

A compliance result describes the checks that were configured and evaluated. It does not establish that every installed application is trustworthy. Defender for Endpoint on Android can feed device-risk information into Intune compliance and Entra Conditional Access when the integration is configured, but that does not demonstrate detection of this particular exploit.

Review the differences between fully managed devices, work profiles, and devices using app protection without enrollment. Application visibility and control differ across those arrangements. The useful outcome is a list of confirmed updates, unresolved devices, and an owner for the remaining checks.

Investigate activity after sign-in

A token obtained through a broker can lead to successful resource access, so an investigation that looks only for failed sign-ins can miss the activity that matters.

For a suspected account, review interactive and non-interactive Entra sign-ins alongside the available resource audit records. Correlate the application, resource, device information, source address, time, and Conditional Access result. A familiar client application name is not sufficient to establish which Android application initiated the broker request.

Follow the evidence into the affected services. Relevant checks include unexpected authentication-method changes, mailbox access or changes, and unusual SharePoint or OneDrive activity. Where Microsoft Graph activity logging was already enabled, it may provide additional request evidence. Do not assume that enabling a log today recovers requests from before collection began.

Establish the available retention period and collection coverage before drawing conclusions. Entra, Defender XDR, Sentinel, and workload audit records answer different questions; none should be presented as a guaranteed AuthMask detection simply because the product is deployed.

Patching and containment are separate tasks

Updating Authenticator closes the vulnerable path. It does not, by itself, establish that previously obtained tokens or application sessions have become unusable.

If there is evidence of compromise, contain the affected device and account through the incident response process. Consider restricting account access, revoking sign-in sessions, reviewing registered authentication methods, and investigating activity in the resources the account could access. Preserve the available evidence and remove unauthorized methods or persistence identified during the investigation.

Session revocation is an important containment action, but enforcement depends on the token, application, and resource involved. Existing access tokens and application-managed sessions can behave differently from refresh tokens. Continuous Access Evaluation can shorten the response in supported scenarios; it does not make every application session end immediately.

A practical exercise is to use a dedicated test account to validate the supported revocation process against the applications your organization relies on. Record when access stops, which sessions remain, and what additional containment is required. That exercise can test the response procedure without reproducing the vulnerability.

What I would ask the security team to demonstrate

I would want three pieces of evidence following this disclosure: confirmed Authenticator updates for the devices we can manage, a documented treatment for devices we cannot verify, and a tested response for suspected token misuse.

Those checks put the existing investment in Intune, Defender, Entra, and security operations to work. They also expose gaps that a report showing high MFA adoption will not explain, such as personal devices with limited inventory, missing resource logs, or a revocation procedure nobody has tested.

MFA remains essential. The operational responsibility continues after sign-in, through the applications receiving tokens, the resources accepting them, and the team's ability to stop access when something goes wrong.