⛓️💥 CVE-2026-80097: Microsoft Authenticator didn't check to see if an app calling itself "Microsoft" was actually Microsoft
Source
Hacker News, 10/27/2026
https://thehackernews.com/2026/10/microsoft-authenticator-flaw-let.html
Microsoft has fixed a flaw in its Authenticator app for Android that let a malicious app with no permissions pose as a trusted Microsoft app, such as Teams, and collect sign-in tokens for a victim's work account.
Commentary
by Claude Fable 5.1, 10/27/2026
The chain: Microsoft fixed a flaw in Authenticator for Android that let a malicious app with no permissions pose as a trusted Microsoft app, such as Teams, and collect sign-in tokens for a victim’s work account. It’s tracked as CVE-2026-80097 and fixed in version 6.2606.4246.
The mechanism is the broker role: on Android, Authenticator acts as a broker; when Teams, Outlook, or another Microsoft app needs to sign a user in, it asks Authenticator, and Authenticator hands back a token. Authenticator exposes a component, an activity named AccountChooserActivity, that any app on the device can start. When the attacker’s app started it, Authenticator built its token request from values the attacker’s app supplied, including the name of the app it claimed to be. A signature check was supposed to stop this: it looked up the real signature of the app being impersonated and confirmed the request matched it. Because Teams was genuinely installed, its real signature was there to read, so the check passed. And the part that’ll make you wince: Authenticator could also see which app had actually made the request, but it did not use that to decide whether to hand over a token.
Q&A
my questions, Claude's answers. Critique & refinement welcome.
Authenticator as the broker
Isn't Authenticator just used for multi-factor authentication (MFA)?
The six-digit codes are the retail face of the app. Underneath, on a phone, Authenticator is the vault for your work identity. When you first sign into a Microsoft app on an Android device, the login doesn’t really end in that app; it ends in the broker (Authenticator, or Company Portal on managed devices), which registers the device with Entra ID and holds a long-lived master credential for it. Microsoft calls that a Primary Refresh Token. Every other Microsoft app on the phone — Teams, Outlook, OneDrive — doesn’t keep its own login. When it needs to prove who you are, it asks the broker, and the broker uses the master credential to mint a short-lived access token scoped to that app.
Experientially, this is why you sign in once and Outlook just opens. It’s also how Conditional Access works: “only managed, compliant devices” is enforceable because the broker is the one party on the phone that can prove the device is registered. So the broker isn’t an MFA accessory. It’s the thing that holds the stamp for your whole account on that device — which is exactly why handing a pass to the wrong app is a full-account problem.
"Nametag" trick
Did the malware basically use a "Microsoft app" nametag to trick Authenticator into accepting the connection?
Yes, straight: the broker checked whether Teams was real instead of whether the caller was Teams.
Android identifies apps by package name plus the signing certificate. The broker protocol has the calling app pass its identity along with the request — “I’m com.microsoft.teams, here’s what I need” — and the broker is supposed to make sure that’s true. Authenticator took the name the caller supplied, looked up the signature of the app with that name on the device, and confirmed it was Microsoft’s. It was. Teams was installed. So the check passed.
The check validated the nametag, not the wearer. And the damning part, per the article, is that Android does tell a receiving component which app actually sent the intent — the calling package and UID are available at the OS level — and Authenticator had that information and didn’t use it to decide. The right check was one call away. This wasn’t a missing capability; it was a logic bug in the single most privileged component on the device.
Why does this happen at Microsoft? Because identity-in-IPC is a confused-deputy problem, and confused deputies are genuinely easy to write. The deputy (the broker) has authority; it acts on behalf of callers; and the moment it trusts a caller’s description of itself instead of the OS’s, it becomes a forging machine for whoever asks. The original check was almost certainly written to catch a tampered Teams — a repackaged app with the wrong signature — and it does catch that. Nobody asked the adjacent question: what if the request isn’t from Teams at all? That’s the same failure as CSRF-from-inside and the mu-plugins folder: the control answers the question it was built for, and the attacker asks a different one.
AccountChooserActivity component
Who owns the ACA process -- Android or Authenticator?
Authenticator’s. On Android, an app is built out of components called activities (roughly: screens), and the app’s manifest declares which ones are exported — startable by other apps through Android’s messaging system, called intents. That’s Android’s mechanism; it’s how “share to” works, how one app opens another. The activity in question is Authenticator’s own account-picker screen, and Authenticator marked it exported, which is how an outside app could start it. So: Authenticator’s component, Android’s door. Exported components that take untrusted input are one of the oldest bug classes on the platform.