AuthMask is research describing a vulnerability in Microsoft Authenticator for Android that allowed a malicious app with no declared permissions to impersonate Teams or another Microsoft app and request work-account tokens. Microsoft tracks the flaw as CVE-2026-80097, rated it 8.6 on the CVSS scale, and fixed it in Authenticator 6.2606.4246. The case shows that an authentication app does more than store OTP codes: when it acts as a sign-in broker, it can also issue the digital passes used to reach email, files, calendars, and enterprise resources.
How Does Authenticator Act as a Broker?
On Android, Microsoft Authenticator can act as an identity broker for apps such as Teams or Outlook. Instead of each app handling the entire sign-in session, it sends a request to the broker; the broker verifies the signed-in account and returns an appropriate access token. The token is proof that allows Microsoft Graph or another API to let the app act within the granted scopes.
This model makes single sign-on more convenient, but it also places Authenticator in a particularly sensitive position. If the broker mistakes the caller's identity, an attacker does not need to crack a password or steal an OTP. The attacker only needs to convince the broker that a malicious request came from a legitimate Microsoft app.
The Weakness Was an Exported Activity
Ofek Levin, a researcher in the Enclave Fellowship program, found that Authenticator exposed the activity com.microsoft.identity.client.AccountChooserActivity with the attribute android:exported="true". Any app on the device could therefore launch this component. The initial gate only checked whether the call used Android's result-returning mechanism; it did not prove which app made the call.
More seriously, the caller supplied many identity fields in the broker request: UID, package name, client ID, redirect URI, and scopes. Authenticator knew the real package name of the calling app through Android, but used that data only to manage parallel requests, not to make a trust decision.
Why Did the Signature Check Still Fail?
Authenticator checked the redirect URI against the signature of the declared application package. This appears to be a reasonable barrier: the redirect URI must match a value derived from the package name and digital signature. However, the software checked the app the attacker claimed to be, instead of comparing it with the app that actually made the call.
If Teams was installed, a malicious app could read its public package and signature information through PackageManager, generate the correct Teams redirect URI, and place it in the request. The check confirmed that the forged dataset was internally consistent with Teams, but never answered the crucial question: was the process requesting the token really Teams? Microsoft mapped the root cause to CWE-287, Improper Authentication.
How Did the AuthMask Exploit Chain Work?
In the test, an app declaring no Android permissions could launch the activity, claim to be Teams, supply a valid client ID and redirect URI, and request a Microsoft Graph token. The authentication result was returned directly to the app that opened the activity. The response bundle contained an access token, refresh token, ID token, and client information in a form the caller could read.
The chain required Authenticator to be installed with a signed-in work account. The attacker also had to get a malicious app onto the device. However, the app itself did not need to request sensitive permissions, reducing warning signs during installation. The original report says that obtaining tokens in the test required no further user interaction.
What Access Could the Stolen Tokens Provide?
When impersonating Teams and requesting Microsoft Graph, the researchers obtained delegated scopes for reading and sending email; reading and modifying files, calendars, and SharePoint sites; and sending Teams messages. Impersonating the Teams chat backend yielded the scope user_impersonation. Claiming to be Authenticator's own client also produced permissions related to authentication methods, including creating or deleting passkeys.
The actual scope depends on the impersonated app, tenant configuration, existing consent, and access policies. The CVE should therefore not be interpreted as every device automatically exposing all Microsoft 365 data. What was demonstrated is that the broker's trust boundary was broken, allowing a local app to request tokens under another app's identity.
Disclosure Timeline and Affected Versions
Enclave reported the vulnerability to Microsoft through responsible disclosure. Microsoft confirmed it, released a fix, and published CVE-2026-80097 on September 8, 2026. Enclave released the AuthMask technical report on October 23, after the patch was available, giving administrators time to update before exploitation details became public.
According to Enclave and Microsoft, Microsoft Authenticator for Android versions earlier than 6.2606.4246 are affected. The flaw is rated High with a CVSS score of 8.6. The research does not say that Authenticator on iOS is vulnerable to the same chain because the activity, package, and broker mechanisms analyzed are specific to the Android app.
What Should Users and Organizations Do?
Users should open the app information screen or Google Play and verify that Microsoft Authenticator is version 6.2606.4246 or later. They should install apps only from trusted sources, limit sideloading, and remove software they no longer use. An app asking for no permissions is not necessarily harmless: AuthMask abused an inter-app interface rather than the camera, contacts, or storage.
Organizations should use MDM or another device-management platform to enforce a minimum version, inventory devices that have not updated, and block access from noncompliant devices. If a malicious app may have been installed while the vulnerable version was present, administrators should revoke sessions, review Entra ID and Microsoft 365 logs, and inspect changes to authentication methods, passkeys, mailbox rules, and unusual file access.
Design Lessons From CVE-2026-80097
AuthMask is a classic confused-deputy flaw: the system had enough information to know the real caller, but made its decision using the identity supplied by that caller. In a broker, every identity field received through an intent or IPC must remain untrusted until it is bound to the calling process's UID and signature using operating-system data.
The broader lesson is that Android's permission model does not cover the whole attack surface. An app labeled as requiring no permissions can still reach another app's exported component. Developers should minimize exported components, require signature-level permissions where appropriate, authenticate the real caller, and test IPC flows with forged input. Organizations should treat authentication-app version management as an identity control, not merely routine mobile-app maintenance.
VNCyberS compiled from Enclave, Microsoft, and Help Net Security
Tiếng Việt
English