Leftover Debug Mode in Microsoft 365 Android Apps Created Account Token Exposure Risk

Overview

Security researchers disclosed an issue in several Microsoft 365 Android applications where a debug mode left enabled in production builds allowed another app on the same device to request and receive access tokens for an already signed-in Microsoft account.

The issue was named FlagLeft by Enclave and affected apps such as Word, Excel, PowerPoint, Microsoft 365 Copilot, Loop, and OneNote. Microsoft has released fixes, and several CVEs were assigned, including CVE-2026-41100, CVE-2026-41101, CVE-2026-41102, and CVE-2026-42832.

There is no public evidence that the issue was exploited before the fix. Still, the risk is significant because it involves access to enterprise accounts, email, files, and calendars through mobile devices.

What Happened

Microsoft 365 Android apps use a shared sign-in mechanism so users do not need to authenticate separately in every app. For example, if a user is already signed in to Word, other Microsoft apps can use the same trusted access flow.

That process should verify whether the app requesting a token is a trusted Microsoft application. According to Enclave’s analysis, this validation was skipped because a debug mode setting was left enabled in a shared Microsoft SDK. As a result, an untrusted app installed on the same Android device could request an access token without a password, a new sign-in screen, or a visible warning to the user.

Why This Matters

Access tokens are highly sensitive because they allow access to services without re-entering a password. In this case, the tokens supported single sign-on across Microsoft applications.

If a malicious app obtained such a token, it could potentially access:

• email content
• Microsoft 365 files
• calendar data
• messages or connected account services
• active sessions that may look normal in logs

This makes the issue especially relevant for organizations that allow Microsoft 365 access from personal or corporate Android devices.

Potential Impact

This is not a remote internet-based attack. The scenario requires a malicious or compromised app to already be installed on the same Android device.

However, the impact can still be serious because:

• the user may see no visible sign of access
• multi-factor authentication may not help if a valid session token is already exposed
• updating the app does not automatically revoke tokens that may already have been issued
• activity may appear as normal mobile access

This is a strong reminder that mobile devices are part of the enterprise attack surface, not just a secondary access channel.

Recommended Actions

Organizations should verify that affected applications are updated through Google Play or their mobile device management platform.

Priority actions include:

• update Word, Excel, PowerPoint, Microsoft 365 Copilot, Loop, and OneNote for Android
• confirm devices are no longer running vulnerable builds
• enforce updates through MDM (Mobile Device Management)
• review installed apps on managed corporate devices
• restrict access from unmanaged or non-compliant devices
• revoke refresh tokens and force reauthentication where risk is suspected
• monitor for unusual mobile session activity

NVD lists Microsoft Word for Android as affected before version 16.0.19822.20190. Similar updates were distributed for other affected apps through Google Play.

DIAMATIX Perspective

This case shows why mobile productivity apps are now part of critical enterprise infrastructure. They are not just tools for reading documents. They carry access to email, files, calendars, internal communication, and cloud services.

The core risk is not only the app itself, but the trust relationship between apps on the same device. When that trust is broken, a malicious app can abuse an already valid session.

Protection requires more than application updates. It requires identity monitoring, device management, and control over mobile applications. In Microsoft 365 environments, this is an identity security issue, not only a mobile app issue.

CISO Analysis

From a CISO perspective, this is an identity and mobile access risk.

Key questions include:

• How many employees access Microsoft 365 from Android devices?
• Are those devices managed through MDM?
• Is access allowed from unmanaged personal devices?
• Can we detect unusual activity from mobile sessions?
• Do we have a process to force reauthentication and revoke tokens when risk is suspected?

This type of issue shows that multi-factor authentication is not sufficient if valid tokens are already exposed. Organizations must monitor not only sign-in events, but also session usage after authentication.

What This Means for Your Environment

• This type of risk relies on abuse of trust between apps on the same mobile device, not a classic phishing page or stolen password.
• Detection depends on visibility into mobile devices, active sessions, tokens, and unusual Microsoft 365 activity.
• Response requires app updates, device management, and token revocation where compromise is suspected.

Do you know which mobile devices have access to your Microsoft 365 environment?

Could you detect abuse of a valid mobile session even when no new password entry occurs?

See how identity and mobile access risks are analyzed and handled in real operational environments.

Contact DIAMATIX
Trusted · Innovative · Vigilant

Sources

• Enclave. FlagLeft research on Microsoft 365 Android apps.
• Microsoft / NVD. CVE-2026-41100, CVE-2026-41101, CVE-2026-41102, CVE-2026-42832.
• SecurityWeek. Analysis of the Microsoft Android apps debug flag issue.
• The Hacker News. Public reporting on the Microsoft 365 Android token exposure issue.

This article is based on publicly available technical and threat intelligence information as of June 2026.