Microsoft 365 Android Token Flaw Moves Risk To Mobile

Enclave disclosed on June 2, 2026 that several Microsoft 365 Android apps had shipped with a production debug setting that changed how account-token sharing was enforced. The affected apps named by Enclave were Word, PowerPoint, Excel, Microsoft 365 Copilot, Microsoft Loop, and OneNote. The company said Microsoft confirmed and fixed the issues, and NVD records show related Microsoft CVEs published on May 12 for Copilot, Word, PowerPoint, and Microsoft Office.

The confirmed technical issue is local, not a remote internet worm. An attacker needed a malicious or attacker-controlled app on the same Android device. That limit matters, but it does not make the flaw routine. Mobile Microsoft 365 apps often sit on devices that carry email, files, calendars, documents, and chat-adjacent workflows. When a local app can receive a token that should have stayed inside a trusted Microsoft app family, the blast radius follows the account and tenant policy, not the icon the user tapped.

Enclave's June 2 writeup describes a vulnerability it calls FlagLeft. The research says a development flag, setIsDebugMode(true), remained enabled in production builds across multiple Microsoft 365 Android apps. That flag mattered because it skipped a check that should have prevented an untrusted app on the same device from receiving Microsoft account tokens through the apps' shared sign-in machinery.

The affected app list in Enclave's disclosure includes Word, PowerPoint, Excel, Microsoft 365 Copilot, Microsoft Loop, and OneNote. Enclave says it produced a working proof of concept on Android, requested tokens from installed Microsoft apps through a third-party app, and used the returned access to read email. That is the researcher claim. The narrower vendor-record layer is that NVD lists Microsoft-issued CVEs for improper access control or spoofing in Copilot, Word, PowerPoint, and Microsoft Office, all published on May 12, 2026.

The strongest constraint is also the first response question: exploitation needed another app on the same Android device. That means a user would first have to install a malicious app, use a compromised app, or operate a device whose app controls were already weak. For consumer devices, that points to app-store hygiene and sideloading risk. For enterprises, it points to mobile device management, managed Google Play policy, app allowlists, and separation between work and personal profiles.

The reason this still deserves fast attention is that the target was not a local file in one mobile app. It was Microsoft account tokens. A valid token can let software act as the signed-in user for the access carried by that token. Enclave identifies the exposed material as FOCI tokens used for app-family single sign-on. Microsoft documentation on refresh tokens explains the underlying risk pattern: refresh tokens last longer than access tokens and can be used to acquire new access tokens for resources where the client has permission.

The public vulnerability records are terse. NVD lists CVE-2026-41100 for Microsoft 365 Copilot for Android with a Microsoft CNA score of 4.4, CVE-2026-41101 for Word with a Microsoft CNA score of 7.1, and CVE-2026-41102 for PowerPoint with a Microsoft CNA score of 7.1. NVD also lists CVE-2026-42832 as a Microsoft Office improper access-control issue with Microsoft as the source. Those records classify the weakness as CWE-284, improper access control.

That record set does not fully explain the operational story by itself. The CVE descriptions say local spoofing by an authorized attacker, which is accurate but easy to underread. Enclave's research supplies the missing mechanism: a same-device app could request tokens that should have been limited to trusted Microsoft apps. The gap between a short CVE title and a practical token-theft path is why mobile identity bugs should be triaged by behavior and asset value, not only by score.

Enclave says the issue has been patched. Microsoft Security Response Center pages are JavaScript-rendered in a way that does not expose much plain text here, but NVD records link back to MSRC vendor advisories and show the CVEs were published on May 12. For managed fleets, that should translate into a concrete inventory task: verify current versions of Word, Excel, PowerPoint, Microsoft 365 Copilot, Loop, and OneNote for Android across every device that can access work data.

Do not rely only on a general statement that Android apps auto-update. Devices can sit offline, users can disable updates, app versions can diverge between work and personal profiles, and mobile threat-defense agents may not see unmanaged personal apps with the same clarity as managed work apps. If the tenant allows bring-your-own-device access, the response has to include Conditional Access posture, Intune compliance state, app protection policy, and sign-in telemetry, not only MDM-enrolled phones.

There is no public evidence in the sources reviewed here that the flaw was exploited in the wild before the fix. That should keep the response proportional. Most organizations should start with patch verification, Android app inventory, and targeted log review. The higher bar is for users who combine Android Microsoft 365 access with sensitive mailboxes, legal files, source code, privileged admin roles, executive communications, or incident-response material.

For those users, consider token revocation as a scoped response if there is evidence of a suspicious co-installed app, unmanaged device exposure, unusual Microsoft Graph access, abnormal Android sign-in patterns, or impossible travel during the vulnerable window. Microsoft Learn documents emergency revocation steps for Microsoft Entra ID, including revoking refresh tokens, and the Microsoft Graph revokeSignInSessions API invalidates refresh tokens issued for a user with a short delay. That is disruptive, so it belongs behind evidence and risk tiering rather than as a tenant-wide reflex.

The uncomfortable part is not that a mobile app had a bug. It is that a debug setting reportedly changed the behavior of a control protecting account-token handoff in several production apps. Shared identity SDKs create useful consistency, but they also create shared failure modes. A single build-time or configuration mistake can propagate across apps that users and admins treat as separate products.

Identity SDK release gates should test the negative case, not only the happy path. A production app should prove that an untrusted package name, signature, broker caller, redirect target, or local app context cannot receive tokens. That proof should run in CI against release artifacts, not only against source code. Mobile SSO is a security boundary. It needs regression tests, variant analysis, and release-blocking checks that reflect that role.

The public record does not show how many devices ran vulnerable builds, how long each affected app carried the flag, or whether any attacker used the issue before disclosure. It also does not show tenant-level indicators that would reliably distinguish benign token use from token use that originated through the vulnerable handoff path. Enclave says the traffic and logs could look normal, which makes retrospective certainty hard.

That uncertainty should shape communication. Users do not need to change their Microsoft password solely because this article exists. Admins do need to confirm patched Android apps, tighten mobile app controls, review high-risk accounts, and be ready to revoke sessions when evidence justifies it. The durable lesson is broader than Microsoft: mobile productivity suites increasingly behave like identity brokers, and identity brokers cannot leave debug behavior in production.