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.
5 steps from start to impact.
Deliver malicious app to target device
- 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
- 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
Enumerate installed Microsoft apps and derive redirect URIs
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.- Malicious app is running on the same device
- Target Microsoft app (e.g., Teams) is installed
- None — this is standard Android API behavior available to any app
Craft spoofed broker request and launch exported activity
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.- Exported activity is reachable (always true pre-patch)
- Attacker knows the target app's client_id and redirect_uri (computed in Step 2)
- None — exploitation is trivial once the malicious app is running
Bypass redirect URI validation
getCallingActivity() data is available but unused in the authorization decision.- Authenticator is unpatched (< 6.2606.4246)
- Patched versions use the verified caller identity for authorization decisions
Receive and exfiltrate stolen tokens
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.- Steps 1–4 succeeded
- 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
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.- 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.
The supporting signals.
| In-the-wild exploitation | No confirmed exploitation. Microsoft stated the flaw was not exploited in the wild prior to patch. Not listed on CISA KEV. |
|---|---|
| PoC / weaponization | Detailed 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. |
| EPSS | 0.00442 (~96th percentile is unlikely). Low predicted exploitation probability, consistent with the local attack vector and mobile-specific delivery requirement. |
| KEV status | Not listed. No CISA Known Exploited Vulnerabilities catalog entry as of 2026-10-27. |
| CVSS vector | CVSS: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 versions | Microsoft Authenticator for Android < 6.2606.4246. All prior versions with the exported AccountChooserActivity in the MSAL broker are vulnerable. |
| Fixed version | 6.2606.4246 (deployed via Google Play, advisory dated September 8, 2026). Patch enforces caller identity verification using getCallingActivity() for authorization decisions. |
| Researcher | Ofek Levin, Enclave Fellowship Program. Research published as AuthMask on October 23, 2026. |
| Scanning / exposure | Not 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 timeline | Reported to MSRC via coordinated disclosure → patch released September 8, 2026 → technical write-up published October 23, 2026 (45-day gap). |
Sources.
- MSRC Advisory CVE-2026-80097
- Enclave — AuthMask: We Made Microsoft Authenticator Hand Over Tokens
- Help Net Security — Microsoft Authenticator vulnerability
- GBHackers — Microsoft Authenticator Flaw Allows Zero-Permission Token Theft
- CyberPress — Microsoft Authenticator Flaw Lets Malicious Apps Steal Tokens
- TheCyberSecGuru — CVE-2026-80097 Broker Bypass Analysis
- BetaNews — Microsoft patches high severity flaw in Authenticator
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:Lin 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.
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).
#!/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