Microsoft Authenticator for Android: The 'Confused Deputy' That Handed Corporate Tokens to Any App

Microsoft has assigned CVE-2026-80097 to a high-severity vulnerability in Microsoft Authenticator for Android that allowed any app installed on the device to steal access tokens for work accounts. Technical details published by Enclave on October 23, 2026 reveal a design flaw in the exported AccountChooserActivity: the authentication broker saw the caller's real identity but chose not to use it to decide whom to trust. The result was an open door to email, files, calendars, and — through passkey manipulation — silent persistence that survives the malicious app's own removal.

The "Confused Deputy" Mechanism: Trusting Declarations, Not Identity

The core of the vulnerability lies in a pattern known in computer security as a "confused deputy attack": a privileged component (the "deputy") is tricked into performing actions on behalf of an actor that has no right to request them. In Microsoft Authenticator, the vulnerable component is the Android activity com.microsoft.identity.client.AccountChooserActivity, which is exported and therefore reachable by any app installed on the device without special permissions.

According to research published by The Hacker News and confirmed by Cybersecurity News, this activity accepted token requests encapsulated in a JSON broker_request_v2. The security check implemented by Microsoft verified that the redirect URI and client ID provided by the requesting app matched those of a legitimate Microsoft app installed on the device — typically Microsoft Teams. However, this check merely compared the metadata declared by the requesting app against the publicly readable metadata of the impersonated app. "Authenticator knew which app was really calling. It just never used that information to decide whether to trust it," states the Enclave research cited by The Hacker News.

The Android OS provides the caller's real package and UID identity to the activity. Microsoft Authenticator received this information but did not use it to validate the match with the identity declared in the JSON. This gap between awareness and enforcement — the broker knew who was calling but chose not to act on that knowledge — is what turns a potential defense into a concrete vulnerability.

From Graph Tokens to Persistence: Escalation Beyond Initial Theft

Once tokens were obtained by impersonating Teams, the malicious app gained access to a broad range of Microsoft 365 services. The delegated permissions obtained, documented by HWUpgrade and confirmed by Enclave's tests, included reading and writing email (Mail.ReadWrite), sending messages (Mail.Send), full access to files in OneDrive and SharePoint (Files.ReadWrite.All), and calendar management (Calendars.ReadWrite). Access to Teams chats is also documented in researcher Ofek Levin's tests.

The impact was not limited to real-time exfiltration. According to Help Net Security, the malicious app could impersonate Microsoft Authenticator itself to modify the victim account's sign-in methods. This included creating new attacker-controlled passkeys, which served as an additional authentication method tied to the user's identity. The consequence is a particularly insidious form of persistence: even after the malicious app's removal or an update to the patched version, the added passkeys remained valid as a legitimate sign-in method.

It remains unconfirmed whether the update to version 6.2606.4246 automatically revokes previously stolen tokens or added passkeys. HWUpgrade raises the specific question of the validity of refresh tokens stolen before the patch, suggesting they may remain active; Microsoft has not published clarifications on this point.

Divergence on Attack Requirements: With or Without User Interaction?

A point of friction among sources concerns the need for user interaction for a successful attack. Microsoft, in the official MSRC advisory for CVE-2026-80097, assigns the CVSS vector UI:R (User Interaction Required) and describes the attack as requiring the user to complete an authentication flow in Microsoft Authenticator. The official quote reads: "An attacker could exploit this vulnerability by installing and running a malicious application on an affected Android device and convincing the user to complete an authentication flow in Microsoft Authenticator."

Enclave, the research team that disclosed the vulnerability, instead states that "The app didn't need permissions, and you didn't need to tap anything" — as summarized by Help Net Security. This discrepancy is not resolved in the available material: it may reflect different test conditions, attack-flow variants, or a different assessment of what constitutes "interaction" in the context of a programmatically launched activity. Certainty calibration requires presenting both positions without forcing a reconciliation.

"Improper authentication in Microsoft Authenticator allows an unauthorized attacker to elevate privileges locally" — Microsoft MSRC, CVE-2026-80097

The Patch and Exposure Perimeter: Versions and Updates

Microsoft released the fix in Microsoft Authenticator for Android version 6.2606.4246, with effective distribution starting in July 2026 according to Cybersecurity News. The officially assigned CVSS score is 8.6, with the full vector CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H, a severity classification of "Important," and an exploitability assessment of "Exploitation Less Likely." Microsoft states the vulnerability has not been exploited in known real-world attacks.

CVE-2026-80097 was assigned by Microsoft on September 8, 2026. The vulnerability type is coded as CWE-287 (Improper Authentication). The dossier contains no information on similar variants in other Microsoft mobile identity brokers or on the quantitative extent of the device population actually exposed.

The source does not specify whether the patch now implements validation of the caller's real identity via package/UID or adopts a different mechanism to restrict access to the activity. This architectural detail falls within the limits of the collected material.

What to Do Now

• Verify that corporate Android devices with Microsoft Authenticator are updated to version 6.2606.4246 or later, deploying the update via MDM with priority on work profiles.
• Check Microsoft Graph access logs for anomalous activity on accounts using Authenticator on Android, paying attention to spikes in access from non-standard client applications.
• Review registered sign-in methods for affected corporate accounts, verifying the presence of passkeys added during suspicious or undocumented periods.
• Restrict sideloading of applications on corporate Android devices, given the absence of special permission requirements for exploiting the vulnerability.

Why Mobile OAuth Broker Design Continues to Underestimate Enforcement

The lesson of CVE-2026-80097 is not that of a trivial implementation bug, but of an architectural choice that privileged verification of declared metadata over identity attested by the operating system. In mobile OAuth brokers — components increasingly central to enterprise zero-trust architecture — this distinction is critical: the package name is an assertion, the UID is a fact. The industry tendency to treat the former as sufficient reflects an incomplete stage of maturity in the secure design of inter-app communication on mobile platforms.

The case also raises a persistence question that transcends the single vulnerability. When an identity broker can be induced to modify its own sign-in methods, compromise becomes structural: no longer an abusive access to revoke, but a digital identity extended with attacker-controlled components. The lifecycle management of passkeys — who can add them, who can revoke them, what happens when the originating broker is compromised — is a governance perimeter still little explored in current implementations.

Frequently Asked Questions

Does the vulnerability also affect Microsoft Authenticator for iOS?

No. The vulnerable component is specific to the Android implementation of Microsoft Authenticator; no indications of equivalent issues emerge in the iOS version.

Does updating to the patched version automatically revoke stolen tokens?

This is not confirmed by available sources. It remains an unclarified point from Microsoft whether the update to 6.2606.4246 invalidates previously issued refresh tokens or any passkeys added by the attacker.

Which source is correct about user interaction?

Microsoft and Enclave present divergent assessments not reconciled in the dossier. The official MSRC advisory includes UI:R (interaction required); Enclave describes tests without interaction. The discrepancy may reflect different experimental conditions.

Sources

• thehackernews.com
• helpnetsecurity.com
• hwupgrade.it
• cybersecuritynews.com
• msrc.microsoft.com