Enclave says a zero permission Android app could take Authenticator tokens; Microsoft rates CVE-2026-80097 8.6

Microsoft says a user step, the finder says none

Microsoft's data for CVE-2026-80097, read on 27 October 2026, scores user interaction as Required in its CVSS 3.1 vector (UI:R, base score 8.6), and its own FAQ says an attacker needs to convince the user to complete an authentication flow in Microsoft Authenticator. The research post by Enclave, dated 23 October, which is 45 days after Microsoft's advisory of 8 September (derived), says there was no user interaction beyond having the broker present with a signed in work account. Help Net Security's report of 27 October says the victim did not need to tap anything. Two primary pages therefore describe the precondition for the same flaw differently, and neither page reconciles the difference.

That difference does not decide whether the flaw is serious. Microsoft's score is high, and the fix is a single app version, 6.2606.4246, which the CVE record gives as the first version outside the affected range. What the record does not establish is any use against a real victim. Microsoft's data marks exploited No, its assessment reads Exploitation Less Likely, the CISA enrichment inside the CVE record lists exploitation as none (dated 9 September), and the CISA known exploited vulnerabilities file read at about 08:07 UTC, catalogue 2026.10.26 with 1,758 entries, does not list it. It does not state how many phones ran an affected build, and it names no iOS version. All of those are time stamped and can change.

Pages read from 08:06 to 08:16 GMT on Tuesday 27 October 2026: Microsoft's security update guide data feed, the CVE record, the NVD record, the CISA file, Enclave's research post and Help Net Security's article, plus Microsoft Learn pages for the admin controls. Microsoft ships and scores Authenticator, so its score and its fix are its own account. Enclave is a security company that publishes this research on a site that lists pricing, so the finding is its own account too. Help Net Security is the news outlet whose headline pointed to the research and is used here only as a pointer.

What the record states and what it leaves out

Microsoft's description is one sentence: Improper authentication in Microsoft Authenticator allows an unauthorized attacker to elevate privileges locally. Its FAQ says the attacker could gain the ability to authenticate against a remote host using the current user's credentials, and that exploitation means installing and running a malicious application on an affected Android device and convincing the user to complete an authentication flow in Microsoft Authenticator. The record does not publish what the code change was.

Microsoft's vector against Enclave's description

Each part of the vector can be set beside what Enclave says it did. Where the two agree the table says so. Where a metric has no support in the research post, the table says that too. The last column is this site's comparison and not a statement from either publisher.

The two possible readings of the user interaction difference are both consistent with the pages. Microsoft's FAQ may be describing a flow the user completes in Authenticator that Enclave's test did not need, or Microsoft may have scored a narrower path than Enclave tested. Neither page says which. The honest position for a defender is to plan for the weaker precondition, which is the one in the research post, and to treat Microsoft's FAQ as the more cautious scoring.

How a rogue app got tokens, as Enclave describes it

Enclave says Microsoft Authenticator on Android exposes an activity, com.microsoft.identity.client.AccountChooserActivity, in its :auth process, marked android:exported="true", so any app on the phone can launch it. The only gate Enclave found is that a calling activity exists. The request fields, including the package name the caller claims to be, its client ID, its redirect URI and the scopes it wants, are all read from the caller's own data. The validation then compares the claimed redirect URI with the one derived from the claimed package's signature on the device. Because the claimed app, Teams in Enclave's test, is installed, its genuine signature gives the genuine redirect URI, so the check passes.

Zoom

The point of the second diagram is a design observation Enclave makes: Authenticator did know the real caller, because the activity reads the package name of the calling activity, and used it only for parallel request bookkeeping. The trust decision used the second answer, the one the caller supplied.

Zoom

What the tokens carried depends on which app the test app claimed to be. Enclave lists three disguises and the scopes each returned. The list is Enclave's, and the table repeats it as printed.

Two statements about these tokens go further than the primary. Help Net Security writes that an attacker who can add a passkey to an account can keep getting in after the malicious app is removed. Enclave lists the passkey scopes but does not say a passkey was registered in its tests, so that is an inference from the scopes. The bundle Enclave describes also holds a refresh token. Microsoft's own page on revoking access explains why that matters: with a refresh token an app can silently get new access tokens when the old one expires, and access tokens last one hour by default. Neither Enclave nor Microsoft says whether any Conditional Access policy would have stopped the test. Microsoft's Learn page says brokers are how apps meet organisational Conditional Access policies, so the control and the flaw sit in the same component.

The dates: advisory first, research post 45 days later

The CVE record shows the identifier was reserved on 25 August and published on 8 September, 14 days later (derived). Microsoft's advisory carries the same release time, 14:00 UTC. Its second revision, on 15 September, seven days after release (derived), corrected the fix build number, which Microsoft calls an informational change. Enclave's post carries the date 23 October on the page, 45 days after the advisory (derived), although the page's own metadata says it was published at 13:27 UTC on 25 October. Help Net Security's article is dated 27 October, 49 days after the advisory (derived).

Zoom

The gap matters for one reason. The advisory was public for 45 days before the technical post appeared, and 38 days after the corrected fix build number (derived). When build 6.2606.4246 reached Google Play is not stated in the pages read, so the time a patched build was available cannot be computed. The devices that mattered after 23 October are those that had not updated, and no page says how many that is.

Labels that do the work of controls

Four labels in this story sound like controls and are not, on the evidence in the pages.

Technical details

Everything in this section is printed by one of the primaries and is copied exactly from the page saved on 27 October 2026. Nothing is proof of concept code. Enclave's post also prints a block of its test app's code, which this site does not reproduce. Neither Microsoft nor Enclave prints indicators such as hashes, domains or detection rules, and Microsoft prints no workaround. What follows is what a defender can match against an app inventory or a code review, and the settings and commands Microsoft documents.

First, the range in the CVE record. This is the version string a defender compares against the installed Authenticator version. The record's cpe entry names the product without an Android qualifier, and the MSRC feed names Microsoft Authenticator for Android.

criteria: cpe:2.3:a:microsoft:authenticator:*:*:*:*:*:*:*:*
versionStartIncluding: 6.0.0
versionEndExcluding: 6.2606.4246
vectorString: CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H/E:U/RL:O/RC:C
cvssV3_1 baseScore: 8.6

Second, Microsoft's own FAQ text from the MSRC data feed. This is the text that sets the user step. Quote it when you reconcile it with the research post.

An attacker who successfully exploited this vulnerability could potentially gain the ability to authenticate against a remote host using the current user’s credentials.
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. Successful exploitation could allow the attacker to obtain authentication tokens and access resources as the affected user.

Third, the component and the flawed check, as Enclave prints them. The first block is the exposed component and the gate. The second is the validation Enclave says was the only comparison made. A defender uses these names to ask a mobile security or code review tool whether a non Microsoft app references the Authenticator package and this class. That use is this site's idea and neither primary offers it as a detection.

com.microsoft.identity.client.AccountChooserActivity
android:exported="true"
getCallingActivity() != null

platformUtil.isValidCallingApp(getRedirectUri(), getCallerPackageName());
String brokerRedirectUri = PackageHelper.getBrokerRedirectUri(this.mContext, claimedPackage);
return StringUtil.equalsIgnoreCase(claimedRedirect, brokerRedirectUri);

Fourth, what comes back. Enclave says the activity returns the broker result to whoever launched it, in a bundle holding the tokens in plaintext. The names below are the result handling lines and the bundle field names as printed. A refresh token in the bundle is why the response needs session revocation and not only the update.

intent.putExtras(bundleFromAuthenticationResult);
setResult(2004, intent);
broker_result_v2_compressed
access_token
refresh_token
id_token
client_info

Fifth, the admin settings and commands Microsoft documents. Neither page is about this CVE. They are the controls the checklist below refers to, and the first is a setting name and its actions as Microsoft prints them on its Intune page. Microsoft says the Min app version setting accepts the formats major.minor, major.minor.build and major.minor.build.revision. Whether the setting can be pointed at Authenticator is not established, and the next section says why.

Min app version
Warn - The user sees a notification if the app version on the device doesn't meet the requirement. This notification can be dismissed.
Block access - The user is blocked from access if the app version on the device doesn't meet the requirement.
Wipe data - The user account that is associated with the application is wiped from the device.

Connect-MgGraph -Scopes "User.ReadWrite.All","Directory.AccessAsUser.All"
$User = Get-MgUser -Search UserPrincipalName:'johndoe@contoso.com' -ConsistencyLevel eventual
Revoke-MgUserSignInSession -UserId $User.Id

The Microsoft page's example account name, johndoe, is Microsoft's placeholder and not a person. The page says Revoke sessions on the user's overview page in the Entra admin center does the same for one user.

A ranked checklist for an administrator

The order below puts the fix first, then the questions the record leaves open, then the clean up. Where a control is not shown to work against this flaw the item says so.

No regulator or agency guidance on this CVE was found in the pages read, so none is cited. The control that matters is a version string on a phone. If an update to the fixed build is not on every managed device by now, 49 days after the advisory (derived), a report of 100 per cent patched needs the version number behind it.

Key facts