A Microsoft Authenticator installation on a phone is more than a place to approve sign-ins. On Android, it can also act as a broker that helps applications obtain tokens for a signed-in work account. That makes one question important whenever a broker returns a token: which app actually made the request?
Enclave AI and researcher Ofek Levin found a case where Authenticator for Android answered that question using information supplied by the requesting app, instead of binding the decision to the app that launched the request. Their research, published as AuthMask, describes how an unprivileged Android app could impersonate a Microsoft first-party app and receive delegated tokens from an account already signed in to Authenticator.
Microsoft fixed the issue as
CVE-2026-80097.
Enclave reports that versions before 6.2606.4246 are affected. The practical lesson
is not that every Authenticator installation or tenant had the same exposure. It is that a
broker must establish the caller's identity from a trusted source before releasing credentials
with the signed-in user's authority.
What the researchers found
According to Enclave AI's AuthMask write-up, the scenario required Microsoft Authenticator to be installed on an Android device and a work account to be signed in. The researchers report that a separate app with no Android permissions could launch an exported Authenticator activity and request a token while presenting itself as an installed Microsoft app. In their tests, the broker returned the result without an additional user interaction.
That last condition needs careful wording. The account had already been added to Authenticator. This was not a remote attack against an arbitrary tenant, and the report does not mean that an attacker could obtain tokens without getting an app onto a device that met the preconditions. Enclave reports no fresh prompt in its tested flow. Microsoft's advisory describes installing and running a malicious Android app and convincing the user to complete an authentication flow in Authenticator. These accounts describe different interaction conditions; the no-fresh-prompt result should be attributed to the researchers' test configuration.
The researchers say the tokens they received carried delegated Microsoft Graph access to mail, files, calendars, and other resources. The exact access depends on the token's audience, scopes, user permissions, and the application's consent. A delegated token acts within the authority granted to that user and application. This report should not be read as evidence that every affected device exposed every mailbox or every tenant resource.
The check trusted the claim, not the caller
Android allows an application component marked as exported to be launched by other apps. A broker activity can expose a legitimate cross-app entry point, but that entry point must verify the actual caller before it returns a credential. Exported does not automatically mean vulnerable; the security depends on the checks around that boundary.
Enclave's analysis describes a request containing caller-controlled values such as a package name, client ID, redirect URI, and scopes. Authenticator validated that the redirect URI matched the signature associated with the package name in the request. That demonstrated that the claimed package and redirect URI matched one another. It did not demonstrate that the package had actually launched the activity.
The researchers also observed that the activity could identify the real calling package, but that value was not used for the relevant trust decision. In short, the broker had access to a fact about the caller and a separate claim supplied in the request. The validation relied on the claim.
Why matching a signature-derived redirect was not enough
A redirect URI can be tied to an Android package signature. That helps an identity platform confirm that a redirect belongs to a registered application. It is useful, but it answers a narrower question than "which installed app is currently calling this broker?"
In the flow described by Enclave, the broker calculated the expected redirect URI using the package name supplied by the request, then compared it to the redirect URI in that same request. A malicious app could name an installed Microsoft app and provide the corresponding signature-derived redirect value. The two values matched because they described the same claimed package. The broker still needed to verify that the real caller was that package.
This is a familiar trust-boundary mistake: checking that two attacker-controlled inputs are consistent does not make either input trustworthy. A caller's assertion can be useful data, but it cannot replace identity established by the operating system or another trusted authority.
| Check | What it establishes | What it does not establish |
|---|---|---|
| Redirect URI matches a named package's signature | The redirect value is consistent with the package that was named. | That the named package made this request. |
| Activity received a start-for-result call | Another activity launched the component through that mechanism. | That the caller is authorized to act as a different installed app. |
| Operating system caller identity is checked and bound to the request | The request came from the verified app identity that the broker authorizes. | That the requested resource or scopes should be granted without normal authorization. |
| Token scopes and audience are constrained | The token is limited to the approved client, resource, and delegated permissions. | That the client app itself is the caller or that the user can access every resource. |
What a returned token can mean
An access token is a bearer credential. A service that accepts it uses its claims to decide what the holder may do. If a broker returns a token to the wrong app, that app may be able to call the corresponding service until the token expires or is rejected. Refresh tokens can extend the exposure if they are also returned and accepted.
That does not make a delegated token equivalent to a tenant administrator credential. The effective access is bounded by consent, the signed-in user's rights, the requested scopes, and resource-side checks. Enclave's proof-of-concept demonstrated broad delegated access in its tested configuration. Organizations should treat the demonstrated impact seriously without assuming those exact permissions were present in every tenant.
The incident response question is therefore concrete: was an affected device running the vulnerable broker while a work account was signed in, and is there evidence that a token or resource was accessed unexpectedly? The CVE alone does not establish that any particular organization's device was exploited.
What administrators should do
- Update Microsoft Authenticator for Android. Enclave identifies
6.2606.4246as the fixed version and earlier versions as affected. Confirm the currently deployed version through your managed application inventory and use the latest available supported release. - Check device coverage. Review enrolled and recently active Android devices, including devices that have not checked in recently. Verify the app's update policy and follow up on devices that have not received the fix.
- Assess exposure when there is a reason to suspect it. Identify devices that were vulnerable during the relevant period, then review sign-in records and Microsoft 365 audit data for activity that does not fit the user or device's normal pattern. The research report is not evidence that exploitation occurred in your environment.
- Use your incident process if exposure is plausible. Revoke sign-in sessions or credentials as appropriate, investigate access to mail, files, and other resources, and follow Microsoft guidance for the affected account and services. Token invalidation behavior depends on token type and resource; changing a password alone should not be treated as proof that every issued token is immediately unusable.
- Keep normal mobile controls in place. App protection, device compliance, and conditional access can reduce other risks, but they do not replace patching the broker that handles token requests on the device.
Do not infer compromise from the CVE alone. Patch the app, establish which devices were exposed, and investigate account or resource activity when the evidence or threat context warrants it.
What app and broker developers should take from it
The underlying design principle applies to any privileged broker that returns a credential, assertion, or capability to another process. Requests cross a process boundary, so the broker should decide what authority to grant from verified caller identity and policy, not from a package name or UID written into request data.
- Derive caller identity from trusted platform context and verify the package-to-UID and signing-certificate relationship before authorizing the request.
- Bind client ID, redirect URI, resource, and scopes to the verified caller's registration. Reject values that are valid for another app, even when those values are individually well-formed.
- Apply least privilege at the broker and resource layers. A valid caller should not be able to request unrelated audiences or permissions just because the broker can issue them.
- Test the boundary with a second app that is not on the allowlist. Include spoofed package names, altered UIDs, valid redirect URIs for a different installed app, malformed requests, and concurrent requests.
- Return only the minimum result needed by the approved client. Treat activity results and intent extras as cross-process data that can be observed by the receiving app.
On Android, details such as how a component is launched and how caller identity is exposed can affect the available checks. The implementation should use the platform-supported mechanism for the actual IPC flow, fail closed when caller identity cannot be established, and have security tests that exercise that flow on supported Android versions.
The practical lesson
Authenticator had the real caller's identity available in the flow described by Enclave, but the trust decision used a caller-supplied identity instead. That small gap turned a broker activity into a path for returning another app's delegated token.
For administrators, the immediate task is to verify that managed Android devices run a fixed Authenticator release and investigate any plausible exposure. For developers, the lesson is to bind every brokered credential to the app that actually asked for it. Matching a signature to a claim is not the same as verifying the caller.
References
- Enclave AI, AuthMask: We made Microsoft Authenticator hand over tokens. Research completed as part of the Enclave Fellowship Program with researcher Ofek Levin.
- Microsoft Security Response Center, CVE-2026-80097
- National Vulnerability Database, CVE-2026-80097