Unbiased headlines. Facts, not spin.
Unbiased Headlines is an independently owned news organization. We bring you the facts, not opinions, written fresh from 110+ named sources. Sources linked so you can verify it yourself.
Microsoft Patched Authenticator Android Flaw That Let Zero-Permission Apps Obtain Work Account Tokens

Microsoft Authenticator for Android had a hole big enough to hand a work account to an app that asked for no permissions at all.
Microsoft tracks it as CVE-2026-80097, rated 8.6 on the CVSS scale and labeled "Important." The company assigned the CVE and shipped the fix on September 8, 2026, in Authenticator for Android version 6.2606.4246. Every earlier version is affected.
The technical details only went public on October 23, when security firm Enclave published its write-up. The researcher is Ofek Levin, who works through Enclave's fellowship program.
How the broker got fooled
On Android, Authenticator does more than display six-digit codes. It also works as a broker. When Teams, Outlook or another Microsoft app needs a sign-in, it asks Authenticator, and Authenticator returns a token proving the user is logged in.
That makes the app a gatekeeper for the entire work account. It is supposed to be picky about who gets a token.
Enclave found it was not. Authenticator exposes an activity called AccountChooserActivity, marked exported, so any app on the phone can launch it. According to Enclave, the only gate was a check that a calling activity existed.
The request itself was built from values the calling app supplied: the app name, package name, client ID, redirect URI and requested scopes. Enclave says it wrote every one of them.
The signature check that checked the wrong thing
Authenticator did run a signature-related validation. It took the package the caller claimed to be, looked up that package's real signature on the device, and built the redirect URI that package should use. Then it compared that to the redirect URI in the request.
The problem is that any app can read the installed Teams signature. Enclave's test app claimed to be Teams, built the matching redirect URI from Teams' own signature, and passed the check every time.
Authenticator could see which app had actually launched the request. Enclave says it never used that fact to decide whether to trust the caller.
In Enclave's tests, posing as Teams and asking for Microsoft Graph access returned tokens that could read and send mail, read and write files, and read and write calendars. The returned data included access, refresh and ID tokens. Depending on the impersonated app and the scopes requested, that reach could extend to OneDrive, SharePoint and Teams services. The tokens cover the work account signed into Authenticator on that device, not other accounts.
Microsoft and Enclave disagree on one point
This is where the two accounts split.
Enclave says its proof of concept needed no user interaction beyond a signed-in work account being present on the phone.
Microsoft's advisory says exploitation requires a malicious app installed on the device and the user completing an authentication flow in Authenticator. Microsoft's CVSS score also reflects a user-interaction requirement.
Both agree on the precondition that matters most: the attacker's app has to be on the phone. Neither account describes a remote attack.
Microsoft also says the flaw has not been exploited in attacks. No investigation, incident report or victim has been named in connection with it.
Why the patch gap is the live issue
The fix has been available for roughly seven weeks. The risk now sits with phones that have not updated.
U.K. consultancy Wizard Cyber argues that this is a governance problem more than a bug. Its point: organizations lock down sign-in with Conditional Access and phishing-resistant methods, but the token then lives in the broker app on a phone, often a personal one nobody is tracking. "If you can't say how many of your users' phones have it, that's the gap to close," the firm wrote.
That argument is aimed at IT departments, not at Microsoft. It still describes the exposure accurately. A company can have airtight cloud policy and zero visibility into whether a finance director's personal Android has the fixed version.
Wizard Cyber also notes that the attack needs a malicious app on a phone with a work account signed in. One sideloaded game on a personal device would meet that bar.
What users and admins should do
The fix is straightforward. Open the Play Store listing for Microsoft Authenticator and confirm the installed version is 6.2606.4246 or later. Auto-update will have handled most phones, but nobody should assume that.
Admins running Microsoft 365 with Android devices in the mix should check the version of Authenticator on enrolled devices and decide who owns that job.
Two things remain open. Microsoft has not said whether it has any telemetry on attempted abuse before the September 8 fix, beyond its statement that it has seen no exploitation. And the dispute over whether the attack needed a user to complete a sign-in step is unresolved, which affects how real-world exposure should be rated for devices that have not yet updated.
Sources used for this briefing
7 links from 6 independent newsrooms (syndicated copies of the same report count once)
These are the sources it draws on, linked so you can verify.