← Back to Feed CACHED · 2026-10-27 09:35:31 · CACHE_KEY CVE-2026-80097
CVE-2026-80097 · CWE-287 · Disclosed 2026-09-08

Microsoft Authenticator Android MSAL broker caller-identity bypass via exported AccountChooserActivity

ASSESSED — NOISGATE
Vendor
—
—
—
Reassessed
—
—
—
Verdict: —
Do you agree?
01 · The Real Story

Your building's security guard checks the visitor's own business card instead of their ID, then hands them the master key

CVE-2026-80097 is an improper-authentication flaw in Microsoft Authenticator for Android (all versions before 6.2606.4246). The app's MSAL broker exposes an Android activity — com.microsoft.identity.client.AccountChooserActivity — marked android:exported="true". Any app on the same device can launch it via startActivityForResult and supply intent extras (broker_request_v2 JSON) that spoof the caller's package name, client ID, redirect URI, scopes, and UID. Authenticator's only validation compared the *attacker-supplied* redirect URI against the *legitimate package's* computed URI — which any app can derive from PackageManager — rather than using Android's built-in getCallingActivity() to verify who was actually calling. The result: the broker returns plaintext access tokens, refresh tokens, and ID tokens granting delegated Mail.ReadWrite, Mail.Send, Files.ReadWrite.All, Calendars.ReadWrite, ChatMessage.Send, and Sites.ReadWrite.All scopes. Impersonating Authenticator itself even yields UserAuthenticationMethod.ReadWrite, enabling passkey manipulation.

Microsoft rates this HIGH at 8.6, and the base CVSS math is technically correct for AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H. However, that score overlooks the real-world delivery barrier: the attacker must first land a malicious app on the target's Android device. In enterprise environments with Intune-managed Google Play, sideloading restrictions, and Play Protect enforcement, installing an untrusted APK is significantly harder than the CVSS AC:L implies. The per-device, per-user blast radius also means there is no single-exploitation fleet-wide outcome — each phone must be individually compromised. The vendor's 8.6 is defensible for unmanaged BYOD fleets but overstates the risk for MDM-enrolled estates. We downgrade the numeric score to 7.0 while keeping the HIGH bucket because the affected component is an identity broker and the post-exploitation impact on any single compromised user is severe.

"Android MFA broker hands tokens to any impersonator — update Authenticator now."
02 · The Attack Path

5 steps from start to impact.

STEP 01

Deliver malicious app to target device

The attacker must get a rogue Android app installed on the victim's device. Delivery vectors include trojanized Play Store apps, sideloaded APKs via phishing links, or compromise of an enterprise app catalog. The malicious app declares zero Android permissions, making it invisible to permission-based review.
Conditions required:
  • Victim uses an Android device with Microsoft Authenticator installed
  • Victim has an authenticated work account in Authenticator
  • Attacker can install an app on the same device
Where this breaks in practice:
  • Enterprise MDM (Intune) can restrict installation sources to managed Google Play only
  • Google Play Protect scans for known malicious behavior patterns
  • Corporate-owned devices typically block sideloading via policy
  • Zero-permission apps still must pass Play Store review if delivered that way
Detection/coverage: MDM compliance reports flag non-managed app installations. Google Play Protect raises alerts for apps exhibiting suspicious inter-app communication patterns.
STEP 02

Enumerate installed Microsoft apps and derive redirect URIs

The malicious app queries PackageManager for installed Microsoft first-party apps (Teams, Outlook, etc.) and reads their signing certificates. It computes the signature-derived msauth:// redirect URI that Authenticator expects for each legitimate app. This is all public information available to any app on the device without special permissions.
Conditions required:
  • Malicious app is running on the same device
  • Target Microsoft app (e.g., Teams) is installed
Where this breaks in practice:
  • None — this is standard Android API behavior available to any app
STEP 03

Craft spoofed broker request and launch exported activity

The attacker constructs a broker_request_v2 JSON payload in intent extras, spoofing the client_app_name, client_id, redirect_uri, scopes, authority, username, and caller.info.uid to impersonate the legitimate Microsoft app. It launches com.microsoft.identity.client.AccountChooserActivity via startActivityForResult. The sole entry gate — getCallingActivity() != null — is trivially satisfied by any startActivityForResult call.
Conditions required:
  • Exported activity is reachable (always true pre-patch)
  • Attacker knows the target app's client_id and redirect_uri (computed in Step 2)
Where this breaks in practice:
  • None — exploitation is trivial once the malicious app is running
Detection/coverage: No on-device detection mechanism exists for this inter-process intent spoofing in unpatched versions.
STEP 04

Bypass redirect URI validation

Authenticator validates the redirect URI by comparing the attacker-supplied value against the computed URI for the *claimed* package name. Since the attacker supplies the correct URI derived from the legitimate app's real signature, validation passes. Critically, Authenticator never checks whether the *actual calling app* matches the claimed identity — getCallingActivity() data is available but unused in the authorization decision.
Conditions required:
  • Authenticator is unpatched (< 6.2606.4246)
Where this breaks in practice:
  • Patched versions use the verified caller identity for authorization decisions
STEP 05

Receive and exfiltrate stolen tokens

Authenticator returns a broker_result_v2_compressed bundle containing plaintext access tokens, refresh tokens, ID tokens, and client information. The malicious app parses these and can immediately use them or exfiltrate them to an attacker-controlled server. Refresh tokens provide persistent access even after the malicious app is removed. Impersonating Teams yields delegated Graph API scopes for mail, files, calendar, SharePoint, and chat; impersonating Authenticator itself yields UserAuthenticationMethod.ReadWrite for passkey manipulation.
Conditions required:
  • Steps 1–4 succeeded
Where this breaks in practice:
  • Conditional Access policies evaluating device compliance or sign-in risk may block token use from unexpected locations
  • Continuous Access Evaluation (CAE) can revoke tokens faster if anomalous usage is detected
Detection/coverage: Entra ID sign-in logs will show token usage. Anomalous sign-in patterns (e.g., token used from a new IP/device simultaneously with legitimate usage) may trigger risk-based Conditional Access or Identity Protection alerts.
03 · Compensating Control

1
HIGH 7.0→IGNORE 0.0
SEVERITY REDUCED
Push Authenticator update to 6.2606.4246+ via managed Google Play — This is the definitive fix. Use Intune or your MDM's managed Google Play integration to force-update Microsoft Authenticator to 6.2606.4246 or later on all enrolled Android devices. Set auto-update policy to HIGH priority. Per the noisgate mitigation SLA for HIGH, deploy within 30 days. Verify deployment via MDM compliance reporting.
2
HIGH 7.0→MEDIUM 5.0
SEVERITY REDUCED
Block sideloading on all managed Android devices — Configure MDM policy to disable installation from unknown sources (DISALLOW_INSTALL_UNKNOWN_SOURCES). This eliminates the primary malicious app delivery vector outside managed Google Play. On Intune, this is enforced via Android Enterprise device restrictions profile. This control alone blocks the most likely delivery path.
3
HIGH 7.0→MEDIUM 5.5
SEVERITY REDUCED
Enforce Google Play Protect scanning via MDM compliance policy — Require Google Play Protect to be enabled and passing on all enrolled devices as a compliance condition. In Intune, set 'Require Google Play Services' and 'Threat scan on apps' to required. This provides automated malware detection for apps exhibiting suspicious inter-process communication patterns. Does not guarantee detection of a novel zero-permission app but raises the bar.
4
HIGH 7.0→HIGH 6.5
Monitor Entra ID sign-in logs for anomalous token usage — Configure alerts in Microsoft Entra ID Protection or your SIEM for concurrent sessions from different IPs/devices, unusual geographic token usage, or atypical Graph API call patterns (e.g., bulk mail access from a mobile token). This is detective, not preventive — it shortens dwell time from days to hours but does not block initial token theft.
5
HIGH 7.0→MEDIUM 5.5
SEVERITY REDUCED
Enforce Conditional Access device compliance requirements — Require device compliance (MDM-enrolled, up-to-date, not rooted) as a Conditional Access condition for Microsoft 365 access. If a device falls out of compliance (e.g., flagged by Play Protect), tokens from that device are blocked at the resource level. This limits the usability of stolen tokens if the source device is subsequently flagged.
What doesn't work
  • FIDO2 / hardware security keys as additional MFA — The vulnerability bypasses the authentication flow entirely by impersonating a legitimate app to the broker. Tokens are stolen post-authentication, so adding stronger MFA factors does not prevent the broker from handing tokens to the malicious app.
  • Network firewalls / IPS / WAF — This is a local inter-process attack on a mobile device. No network traffic is involved in the exploitation itself; only the subsequent token exfiltration traverses the network, and it uses standard HTTPS to Microsoft endpoints.
  • VPN enforcement — Irrelevant. The attack occurs locally on the device via Android intent mechanisms, not over a network connection.
  • Reducing token lifetimes alone — While shorter access token lifetimes reduce the exploitation window, the attacker also obtains refresh tokens, which can silently request new access tokens. Token lifetime reduction without revoking refresh tokens provides minimal protection.
04 · Intelligence Metadata

The supporting signals.

In-the-wild exploitationNo confirmed exploitation. Microsoft stated the flaw was not exploited in the wild prior to patch. Not listed on CISA KEV.
PoC / weaponizationDetailed write-up with code snippets published. Enclave published the *AuthMask* report on October 23, 2026, including Java code demonstrating intent construction and token retrieval. No standalone exploit repo found on pocindex.io or GitHub as of assessment date, but the published code is sufficient to reproduce.
EPSS0.00442 (~96th percentile is unlikely). Low predicted exploitation probability, consistent with the local attack vector and mobile-specific delivery requirement.
KEV statusNot listed. No CISA Known Exploited Vulnerabilities catalog entry as of 2026-10-27.
CVSS vectorCVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H (8.6). Temporal score per MSRC: 7.5. Local vector with scope change reflects cross-boundary token theft. UI:R maps to account selection if prompted.
Affected versionsMicrosoft Authenticator for Android < 6.2606.4246. All prior versions with the exported AccountChooserActivity in the MSAL broker are vulnerable.
Fixed version6.2606.4246 (deployed via Google Play, advisory dated September 8, 2026). Patch enforces caller identity verification using getCallingActivity() for authorization decisions.
ResearcherOfek Levin, Enclave Fellowship Program. Research published as AuthMask on October 23, 2026.
Scanning / exposureNot remotely scannable. This is a local Android inter-process vulnerability. No Shodan/Censys/GreyNoise exposure data applicable. Fleet exposure must be assessed via MDM inventory of Authenticator versions.
Disclosure timelineReported to MSRC via coordinated disclosure → patch released September 8, 2026 → technical write-up published October 23, 2026 (45-day gap).

Sources.

  1. MSRC Advisory CVE-2026-80097
  2. Enclave — AuthMask: We Made Microsoft Authenticator Hand Over Tokens
  3. Help Net Security — Microsoft Authenticator vulnerability
  4. GBHackers — Microsoft Authenticator Flaw Allows Zero-Permission Token Theft
  5. CyberPress — Microsoft Authenticator Flaw Lets Malicious Apps Steal Tokens
  6. TheCyberSecGuru — CVE-2026-80097 Broker Bypass Analysis
  7. BetaNews — Microsoft patches high severity flaw in Authenticator
05 · The Call

Final Verdict
= UNCHANGED to HIGH (7.0/10)

Why this verdict

  • Local delivery barrier is real friction. The entire chain requires a malicious app on the victim's Android device. In MDM-managed fleets (Intune, VMware WS1), app installation is restricted to managed Google Play catalogs. Google Play Protect adds a second screening layer. This compounding friction is not captured by AC:L in the CVSS vector and justifies a 1–2 point downward adjustment.
  • Per-user blast radius, not fleet-scale. Unlike a server-side IdP compromise where one exploit = all users, this attack must be repeated per-device. There is no pivot from one stolen token set to fleet-wide compromise. Each phone is an independent target requiring its own malicious app delivery.
  • Role multiplier: identity broker (floor = HIGH). Microsoft Authenticator IS the MSAL token broker on every Entra ID-enrolled Android device. It is canonically an identity component — Microsoft auto-installs it on MDM-enrolled devices. When the chain succeeds, the attacker obtains the victim's full delegated Microsoft 365 identity (mail, files, calendar, Teams, SharePoint) plus potential passkey management. For privileged users (IT admins, security staff), this is identity-scale impact. This floors the verdict at HIGH regardless of delivery friction.
  • Zero-permission stealth is an upward pressure. The malicious app needs no declared Android permissions, meaning it bypasses permission-based user review and many static analysis checks. This partially offsets the delivery friction, preventing a downgrade to MEDIUM.
  • Public technical write-up lowers the bar. Enclave's AuthMask report includes working code snippets. While no packaged exploit kit exists yet, the October 23 publication puts weaponization within reach of moderately skilled attackers targeting specific organizations.

Why not higher?

CRITICAL would require fleet-scale or domain-scale impact from a single exploitation point. This vulnerability is fundamentally per-device: compromising one phone yields one user's tokens. The local attack vector means there is no internet-facing attack surface to mass-exploit. Even in the worst case (privileged admin's phone compromised), the blast radius is bounded to that admin's delegated permissions, not a direct domain takeover equivalent. Enterprise MDM restrictions on app installation create meaningful friction that a CRITICAL rating would ignore.

Why not lower?

MEDIUM would understate the risk for an identity-component vulnerability where the post-exploitation impact is full Microsoft 365 account takeover with persistent refresh tokens. The zero-permission requirement makes the malicious app exceptionally stealthy — no permission prompts, no runtime warnings. The AuthMask write-up with code snippets is public, lowering the exploitation skill bar. Microsoft Authenticator is auto-installed on every enterprise Android device, guaranteeing the vulnerable component is present across the fleet. The identity-broker role floors this at HIGH.

06 · Verification

Crowdsourced verification payload.

Run on an auditor workstation with adb in PATH and the target Android device connected via USB with USB debugging enabled. Requires no root on the device. Usage: bash check_cve_2026_80097.sh — checks the connected device and exits 0 (PATCHED), 1 (VULNERABLE), or 2 (UNKNOWN).

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/usr/bin/env bash
# CVE-2026-80097 Verification — Microsoft Authenticator Android version check
# Target: connected Android device via ADB
# Output: VULNERABLE / PATCHED / UNKNOWN
set -euo pipefail

PACKAGE="com.azure.authenticator"
FIXED_MAJOR=6
FIXED_MINOR=2606
FIXED_PATCH=4246

if ! command -v adb &>/dev/null; then
  echo "UNKNOWN — adb not found in PATH"
  exit 2
fi

if ! adb get-state &>/dev/null 2>&1; then
  echo "UNKNOWN — no Android device connected via ADB"
  exit 2
fi

VERSION=$(adb shell dumpsys package "$PACKAGE" 2>/dev/null \
  | grep -m1 'versionName=' | sed 's/.*versionName=//' | tr -d '[:space:]')

if [ -z "$VERSION" ]; then
  echo "UNKNOWN — Microsoft Authenticator ($PACKAGE) not installed"
  exit 2
fi

IFS='.' read -r V_MAJOR V_MINOR V_PATCH <<< "$VERSION"
V_MAJOR=${V_MAJOR:-0}; V_MINOR=${V_MINOR:-0}; V_PATCH=${V_PATCH:-0}

echo "Installed: $VERSION  |  Fixed: ${FIXED_MAJOR}.${FIXED_MINOR}.${FIXED_PATCH}"

if (( V_MAJOR > FIXED_MAJOR )) \
   || (( V_MAJOR == FIXED_MAJOR && V_MINOR > FIXED_MINOR )) \
   || (( V_MAJOR == FIXED_MAJOR && V_MINOR == FIXED_MINOR && V_PATCH >= FIXED_PATCH )); then
  echo "PATCHED — CVE-2026-80097 is fixed in $VERSION"
  exit 0
else
  echo "VULNERABLE — CVE-2026-80097 affects Microsoft Authenticator < ${FIXED_MAJOR}.${FIXED_MINOR}.${FIXED_PATCH}"
  exit 1
fi