As reported by The Hacker News, Microsoft has patched a serious authentication broker flaw in its Authenticator app for Android — CVE-2026-80097 — that allowed a malicious app with zero permissions to impersonate trusted Microsoft apps and harvest sign-in tokens for a victim's work account. The vulnerability, discovered by Ofek Levin through a fellowship at security firm Enclave, carries a CVSS score of 8.6 (rated Important by Microsoft) and was fixed in Authenticator for Android version 6.2606.4246. No active exploitation has been observed.

Security Impact: As reported by The Hacker News, Microsoft has patched a serious authentication broker flaw in its Authenticator app for Android — CVE-2026-80097 — that allowed a malicious app with zero permissions to impersonate trusted Microsoft apps and harvest sign-in tokens for a victim's work account.

Vulnerability Details

FieldDetail
CVECVE-2026-80097
CVSS8.6 (Important)
Affected ProductMicrosoft Authenticator for Android (versions prior to 6.2606.4246)
VendorMicrosoft
Fix AvailableYes — update to version 6.2606.4246 or later
Active ExploitationNot observed in the wild
Root CauseAccountChooserActivity accepted caller-supplied app identity without verifying the requesting app matched the claimed identity

Why This Matters

This vulnerability is notable not just for its impact but for what it reveals about the trust model underlying mobile authentication brokers. Microsoft Authenticator on Android does far more than generate OTP codes — it functions as a broker that mediates sign-in for Microsoft 365 apps like Teams, Outlook, and OneDrive. When an app needs authentication, it delegates to Authenticator, which returns a token. This architecture is convenient but concentrates enormous trust in a single component.

The flaw exploited a gap between claimed identity and actual caller identity. Authenticator's AccountChooserActivity was exported and invocable by any app on the device. The attacker's app supplied values — including the name of the app it claimed to be — and Authenticator built its token request from those untrusted inputs. A signature check was present but fundamentally broken: it verified that the claimed app's signature matched the real installed app's signature, which it naturally did since the legitimate app was present on the device. Authenticator could see which app had actually initiated the request but did not use that information in its authorization decision.

This is a textbook confused deputy problem. The broker is the deputy, the attacker's app is the confused party supplying instructions, and the token is the privileged resource being misdirected.

Who Is at Risk

Who Is at Risk
Enterprise environments using Microsoft 365 with Android devices where Authenticator is configured as the primary broker for work accounts
BYOD deployments where users install personal apps alongside corporate authentication tools — the attack requires only a sideloaded or maliciously published app
Organizations with conditional access policies that rely on device-level trust signals from Authenticator, since stolen tokens inherit the full permissions of the signed-in user

Enclave's proof of concept returned Microsoft Graph tokens granting read/send mail, read/write files, and read/write calendar access — effectively full mailbox and document access without the user ever entering a password or approving a prompt.

Broader Implications

This is not just a Microsoft problem. The broker pattern — where a privileged authentication component mediates on behalf of other apps — is used across mobile platforms. Any exported component that accepts caller-supplied identity claims without cryptographically binding those claims to the actual calling process is vulnerable to the same class of attack. The fix must verify the requesting app's identity, not just the claimed app's signature.

Security teams should recognize that mobile threat models extend beyond malware and network interception. The inter-app trust relationships on a device are an attack surface that most MDM and EDR tools do not adequately monitor.

Shield53 Recommendations

Immediate Actions

  • Update Microsoft Authenticator on all Android devices to version 6.2606.4246 or later. Verify via managed app deployment or user self-service confirmation.
  • Audit conditional access policies to ensure they do not grant implicit trust based solely on Authenticator presence. Implement session lifetime limits and token revocation for suspicious activity.
  • Deploy mobile threat defense (MTD) capabilities that detect sideloaded or untrusted apps on enrolled devices, particularly in BYOD scenarios.

Strategic Actions

  • Review exported Android components in any internally developed apps that interact with authentication brokers — ensure caller identity is cryptographically verified, not self-attested.
  • Implement token scoping and least privilege — ensure Microsoft Graph tokens requested by mobile apps are scoped to the minimum permissions required, reducing blast radius of token theft.
  • Enable anomaly detection for Microsoft Graph API access patterns — unusual token usage from new app IDs or atypical data access volumes should trigger investigation.
  • Educate users on the risks of sideloading apps, particularly in BYOD environments where corporate and personal app ecosystems intersect.

The patch resolves the immediate vulnerability, but the architectural pattern that enabled it persists across the mobile ecosystem. Defenders should treat inter-app trust boundaries as a first-class security concern, not an implementation detail.