Microsoft Authenticator CVE 2026 26123 explained for security teams

Can AI-driven automation bridge the cybersecurity skills gap effectively?

CVE 2026 26123 is an information disclosure vulnerability in Microsoft Authenticator for Android and iOS. In plain terms, it is a weakness in how the app and the mobile operating system handle a custom URL scheme handoff during an authentication flow. Under the right conditions, a malicious app on the same device can receive sensitive sign-in material that should have been handled only by Microsoft Authenticator. (nvd.nist.gov)

Microsoft rated the issue as medium severity, with a local attack vector and user interaction required, consistent with real-world exploitation being more likely in targeted scenarios than in broad, silent compromise. (nvd.nist.gov)

What actually broke in CVE 2026 26123

The public weakness classification is CWE-939: improper authorisation in the handler for a custom URL scheme. (nvd.nist.gov)

Most modern authentication experiences on mobile rely on deep links and app-to-app handoffs, for example:

A browser sign-in flow that redirects to an authenticator app to complete a prompt or device registration
A QR code or enrolment link that launches the authenticator to finish binding the account
A link that carries state parameters and context so the authenticator can continue a flow that started elsewhere

The core security assumption is that only the intended app should receive that deep link payload. CVE 2026 26123 indicates that, in some cases, the receiving logic did not enforce that assumption strongly enough.

Attack chain and prerequisites

This is not a remote exploit on its own. The attacker typically needs several things to line up:

1. The attacker needs code on the device

A malicious application must be installed on the device and capable of registering to handle the relevant URL scheme or a similar intent-based handoff.

This aligns with the reporting that exploitation can involve a malicious app presenting itself as Microsoft Authenticator in the handoff experience. (rapid7.com)

2. Some user interaction is required

The published CVSS vector includes the UI required vector, meaning the user must take an action during the flow. (nvd.nist.gov)

In practice, this could be any action that causes the deep link to be opened and handled by the wrong application, such as selecting the wrong handler when prompted, or following a crafted link during sign-in or enrolment.

3. The malicious app captures sensitive material

The impact described publicly is information disclosure. Microsoft and third-party write-ups describe the exposure as one-time sign-in codes or authentication deep links, which can be enough to complete or replay part of an authentication sequence if the rest of the conditions are favourable. (forbes.com)

Impact: what can be disclosed and why it matters

Given the CVSS confidentiality impact is high, this is not just a cosmetic leak. (nvd.nist.gov)

Even if what leaks is short-lived, security teams should treat it like an identity incident because:

Deep links can embed a state that helps complete an auth flow.
One-time codes are often time-bound, but still operationally useful during active phishing or device compromise
If an attacker already has device access, harvested auth material can be used to move faster and reduce noisy interaction.

This is especially relevant for executives and high-risk users who frequently approve sign-ins and are more likely to be targeted by convincing social engineering.

Affected versions and fixed versions

Microsoft published affected version ranges through the CVE record. At the time of publication:

Microsoft Authenticator for Android is affected from 6.0.0 up to, but not including, 6.2511.7533 (app.opencve.io)
Microsoft Authenticator for iOS is affected from 6.0.0 up to, but not including, 6.8.40 (app.opencve.io)

If you run a mixed fleet, assume partial exposure until you can prove compliance with updates across both mobile platforms.

Required user interaction: what to train and what to test

Because UI is required, user behaviour and user experience design matter.

For awareness and simulation, focus training on:

Only approve prompts initiated by the user.
Avoiding unexpected app selection prompts during sign-in flows
Treating QR codes for enrolment and device registration as sensitive, especially when received by email or chat

For engineering and assurance, test your common identity journeys:

Device registration and re-registration flows
Passwordless and passkey-related flows if Authenticator is used as a provider
Any internal apps that rely on deep links to start authentication on mobile

Indicators of compromise you can realistically look for

You will not always get perfect telemetry for URL scheme invocations at the operating system level, but you can still hunt for signals that fit the exploitation pattern.

Device and app signals

Installation of suspicious apps shortly before account anomalies
Repeated sign-in attempts that align with user-reported unusual prompts
Mobile security signals from your EDR, especially on rooted or jailbroken devices

Microsoft has also been rolling out stronger jailbreak and root detection for Authenticator in enterprise contexts, which may help reduce risk from higher-friction device-compromise paths. (mc.merill.net)

Identity and access signals

Unusual sign-in activity from new locations immediately after a user reports an Authenticator oddity
Short bursts of failed sign-ins followed by a success that the user cannot explain
New device registrations or MFA method changes that follow a suspicious interaction.

Deep link and handler clues

If you can capture mobile application launch telemetry through your mobile threat defence or EDR tooling, look for:

Repeated invocations of authenticator-related deep links that do not correlate with normal user journeys
Handler selection prompts or app switching loops reported by users

Even when you cannot log the raw URL, the timing of app focus changes can still correlate strongly with a malicious interception attempt.

Mitigation plan for security teams

1. Patch fast, then verify

Microsoft and multiple security advisories recommend updating Microsoft Authenticator to the latest version on both platforms. (rapid7.com)

For enterprise teams, the most important step is not the update action itself, but verification:

Enforce minimum app versions via MDM where possible.
Measure update coverage and report exceptions, especially among privileged users
Block or heavily restrict unmanaged devices from performing sensitive identity actions.

2. Reduce the blast radius of device local attacks

Because the attack is local, you reduce risk by reducing what an attacker can do on a device:

Require compliant devices for high-risk roles.
Strengthen mobile app controls and restrict unknown app installs where feasible.
Keep phishing-resistant authentication as the end state for privileged access, for example, FIDO2 or certificate-bound flows, with Conditional Access controls to match

3. Operationalise detection with Microsoft Sentinel SOC automation

This vulnerability is a good reminder that identity events, endpoint events, and user reports need to land in one workflow.

A practical approach is to build Microsoft Sentinel SOC automation that:

Opens a case when a user reports unusual Authenticator behaviour
Enriches the case with recent sign-in logs, MFA events, and device risk signals
Guides triage actions consistently, including forced sign out, token revocation, and MFA method review where appropriate

If your SOC is short on KQL expertise, prioritise approaches that support KQL-free Sentinel triage so analysts can still ask the right questions, validate hypotheses, and act quickly during time-sensitive auth events.

Treat CVE 2026 26123 as an identity adjacent issue, not just a mobile app patch. Your best outcome is fast update coverage plus a repeatable identity incident playbook.

What to tell your CISO and leadership

Keep it crisp and action driven:

This is a local vulnerability that requires user interaction and a malicious app presence, so it is not a mass remote worm risk. (nvd.nist.gov)
It can disclose sensitive sign in material, so targeted abuse is plausible, especially for executives and admins. (forbes.com)
The control plan is straightforward: update enforcement, device compliance, and identity monitoring with automated response paths.