← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2026-41615 · CWE-200 · Disclosed 2026-05-14

Exposure of sensitive information to an unauthorized actor in Microsoft Authenticator

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
01 · The Real Story

This is a bank vault key left in a coat pocket, not the vault door blown off

CVE-2026-41615 is a Microsoft Authenticator information disclosure bug affecting Android versions before 6.2605.2973 and iOS versions before 6.8.47. Microsoft’s description is sparse: an unauthorized attacker can disclose sensitive information over a network, and the affected product is the mobile Authenticator client, not an internet-facing server. NVD enrichment shows the affected ranges and also records a lower-impact interpretation of the CVSS vector than Microsoft’s CNA entry.

The vendor’s 9.6/CRITICAL label overrates the real-world enterprise urgency. This is not an unauthenticated perimeter RCE on a broadly exposed service; it is a client-side mobile app leak with user interaction required, no KEV listing, and a near-floor EPSS. The reason this still lands at HIGH instead of MEDIUM is the product: if the leaked data includes authenticator state, OTP-related material, or sign-in artifacts, the downstream business impact can be disproportionate even though the attack surface is narrower than the score implies.

"Treat this as a high-value client-side secret leak, not a wormable critical."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Find a victim running the vulnerable app

The attacker first needs a user with Microsoft Authenticator installed on a vulnerable Android or iOS build. This is a client targeting problem, not a mass internet scanning problem, because the software runs on end-user mobile devices rather than on a server reachable from Shodan/Censys. *Inference from product type and affected platforms in NVD/OpenCVE.*
Conditions required:
  • Victim uses Microsoft Authenticator on Android < 6.2605.2973 or iOS < 6.8.47
  • Attacker can target or influence the victim user
Where this breaks in practice:
  • No internet-facing daemon to scan at scale
  • Enterprise inventories often know managed mobile app versions via MDM, but attackers usually do not
  • BYOD and app auto-update reduce dwell time on vulnerable versions
Detection/coverage: Traditional network scanners will miss this entirely. Coverage usually comes from MDM/UEM inventory, mobile app version reporting, or telemetry from Entra/Intune-adjacent device posture tools.
STEP 02

Trigger the vulnerable client path

Because the CNA and NVD both carry UI:R, the attacker likely has to induce some user-driven flow such as opening a crafted link, responding to an authentication prompt, or interacting with a malicious app/content path that causes Authenticator to process data. No public root-cause write-up was available from Microsoft at time of assessment, so the exact trigger is inferred from the CVSS and product behavior.
Conditions required:
  • Victim performs the required interaction
  • A reachable vulnerable code path exists in the mobile client
Where this breaks in practice:
  • User interaction is mandatory
  • Modern mobile OS controls, enterprise app protection, and phishing-resistant MFA flows can interrupt the chain
  • If the bug requires a specific sign-in or deep-link workflow, only a subset of users are reachable
Detection/coverage: Email gateways, mobile threat defense, browser safe-browsing, and deep-link reputation controls may catch the delivery vector, but they do not directly detect the vulnerability itself.
STEP 03

Exfiltrate sensitive Authenticator data over the network

Successful exploitation causes sensitive information to be disclosed from the app. NVD’s analysis downgrades the impact to confidentiality only (C:H/I:N/A:N), which is materially more believable for an information disclosure bug than Microsoft’s original C:H/I:H/A:H claim. That discrepancy is the biggest reason to distrust the raw 9.6 headline.
Conditions required:
  • The vulnerable flow handles secrets or security-relevant metadata
  • The attacker can receive or observe the disclosed material
Where this breaks in practice:
  • Microsoft has not publicly documented the exact data class exposed
  • Some leaked data may be short-lived or require immediate operational follow-through
  • Device binding or additional server-side checks may limit reuse
Detection/coverage: There is no reliable signature-based scanner for the data leak itself. Detection is more likely indirect: suspicious sign-in activity, impossible-travel anomalies, unusual MFA prompts, or mobile EDR telemetry if malware is involved.
STEP 04

Convert leaked data into account impact

The attacker’s endgame is not just reading data; it is using the disclosed material to improve phishing, replay sign-in context, or bypass parts of the MFA workflow. On its own this CVE is not a fleet-wide outage primitive, but against privileged users it can become an account takeover amplifier.
Conditions required:
  • Leaked data is reusable or actionable
  • Targeted accounts have meaningful privileges
Where this breaks in practice:
  • Blast radius is generally per-user/per-device, not enterprise-wide by default
  • Phishing-resistant methods and conditional access can still block final account abuse
  • Short token lifetimes and prompt fatigue defenses may reduce reuse value
Detection/coverage: Best detection is in the identity plane: Entra ID risky sign-ins, abnormal MFA registrations, new-device sign-ins, impossible travel, and token abuse analytics.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo CISA KEV listing found and no authoritative public exploitation notice surfaced in the sources reviewed as of 2026-06-03. Source: CISA KEV catalog.
PoC availabilityNo public PoC/exploit repository was located in GitHub-focused web search, and the reviewed CVE aggregators did not expose a public exploit reference. Treat this as a low-confidence negative because Microsoft has not published root-cause details.
EPSS0.00079 (0.079%), which is extremely low and consistent with a client-side bug that is hard to operationalize at scale. FIRST EPSS is a threat-likelihood input, not an impact measure: FIRST EPSS.
KEV statusNot listed in CISA KEV; there is therefore no federal due-date signal or public exploitation designation from CISA. Source: KEV catalog.
CVSS vector reality checkMicrosoft CNA published CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H = 9.6, but NVD’s enrichment records AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N. For an information disclosure bug in a mobile authenticator client, NVD’s impact profile is more plausible than total integrity/availability loss. Source: NVD.
Affected versionsAffected ranges recorded by Microsoft/NVD/OpenCVE: Android 6.0.0 to < 6.2605.2973 and iOS 6.0.0 to < 6.8.47. Source: OpenCVE mirror of CVE record, NVD.
Fixed versionsUpdate to at least Android 6.2605.2973 and iOS 6.8.47. Apple’s App Store page shows 6.8.47 in version history, corroborating the fixed iOS build: App Store.
Exposure/scanning realityThis is not meaningfully Shodan/Censys/FOFA-scannable because the vulnerable component is a mobile client app. Exposure is determined by fleet app inventory, not open ports.
Disclosure timelinePublished by Microsoft on 2026-05-14; NVD shows publication on 2026-05-14 and modification on 2026-05-15. Sources: OpenCVE, NVD.
Researcher / reporting orgPublic record identifies Microsoft as the CNA/source, but the reviewed sources did not name an external reporting researcher. Source: OpenCVE, MSRC advisory.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to HIGH (7.1/10)

The decisive downgrade factor is attack-surface reality: this is a mobile client-side bug with user interaction required, not a remotely exploitable perimeter service. It stays HIGH because the affected product sits directly in the MFA trust chain, so even a narrow secret leak can translate into high-value identity compromise for targeted users.

MEDIUM Overall severity reassessment
LOW Exact exploit chain details due to sparse vendor technical disclosure
HIGH Affected version ranges and patch floor

Why this verdict

  • Downgrade from 9.6: the vulnerable component is a mobile app, not a mass-exposed server; that alone cuts reachable population and scanner-discoverable exposure.
  • Further downgrade: both Microsoft and NVD mark UI:R, which implies the attacker must win a user-driven step rather than firing blind pre-auth requests at a service.
  • Further downgrade: there is no KEV listing, no public exploitation evidence located, and the supplied EPSS 0.00079 is near floor, which argues against emergency-grade operational exploitation risk.
  • Partial upward adjustment: the app is part of the identity/MFA control plane, so disclosed secrets can have outsized downstream impact relative to a normal client-side info leak.
  • Credibility adjustment: NVD’s confidentiality-only interpretation is more consistent with the bug class than Microsoft’s total-CIA 9.6 vector, so the vendor baseline appears inflated.

Why not higher?

There is no evidence this is wormable, unauthenticated server-side, or widely internet-reachable. The mandatory user interaction and client-device targeting requirements put real friction in front of scale exploitation, and the absence of KEV or public exploit reporting removes the biggest urgency amplifier.

Why not lower?

This is not harmless client noise: the vulnerable product is Microsoft Authenticator, which sits next to MFA prompts, device trust, and sign-in workflows. Even with a narrow path, compromise of secrets from that location can materially assist account takeover or identity abuse, especially for admins and other high-value users.

05 · Compensating Control

What to do — in priority order.

  1. Enforce app minimum versions — Use MDM/UEM policy to require Android 6.2605.2973+ and iOS 6.8.47+, and block or quarantine devices that fall below that floor. For a HIGH verdict, deploy this control within 30 days if patching is not already complete.
  2. Prioritize privileged-user devices — Start with admins, help desk, finance, executives, and anyone with tenant-wide roles because identity-adjacent leaks hurt most there. If you cannot patch the whole fleet immediately, use the HIGH / 30-day window to collapse exposure on privileged cohorts first.
  3. Tighten conditional access — Require compliant devices, phishing-resistant methods where available, and step-up checks for sensitive apps so leaked client data is harder to convert into account abuse. Put these guardrails in place within 30 days where they are missing.
  4. Hunt for suspicious MFA activity — Review risky sign-ins, anomalous MFA prompts, new device registrations, and abnormal approval patterns around users known to run vulnerable Authenticator builds. This gives you compensating visibility while patch rollout completes, and should begin immediately even though the formal HIGH mitigation window is 30 days.
What doesn't work
  • Perimeter vulnerability scanning doesn't help because there is no exposed server component to scan.
  • WAF rules don't help because the vulnerable software is a mobile client app, not a web application endpoint you control.
  • Password resets alone are incomplete because the risk is tied to Authenticator-side data exposure, not just static credentials.
06 · Verification

Crowdsourced verification payload.

Run this on an auditor workstation, MDM admin box, or CI job, not on the phones themselves. Export your mobile app inventory to CSV with columns like user,device,platform,version, then run python3 check_authenticator_cve_2026_41615.py mdm_export.csv; no local admin rights are needed, but you do need access to the inventory export.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# check_authenticator_cve_2026_41615.py
# Purpose: Assess Microsoft Authenticator versions from an MDM/UEM CSV export
# Output: VULNERABLE / PATCHED / UNKNOWN per row, plus overall result
# Exit codes:
#   0 = all relevant rows patched
#   1 = one or more vulnerable rows found
#   2 = input/format error or only unknown results

import csv
import re
import sys
from typing import List, Tuple

ANDROID_FIXED = '6.2605.2973'
IOS_FIXED = '6.8.47'


def normalize_platform(value: str) -> str:
    v = (value or '').strip().lower()
    if v in ('android', 'aosp'):
        return 'android'
    if v in ('ios', 'iphone', 'ipad', 'ipados'):
        return 'ios'
    return 'unknown'


def parse_version(v: str) -> List[int]:
    if not v:
        return []
    parts = re.findall(r'\d+', v)
    return [int(p) for p in parts]


def cmp_versions(a: str, b: str) -> int:
    pa = parse_version(a)
    pb = parse_version(b)
    if not pa or not pb:
        return 0
    max_len = max(len(pa), len(pb))
    pa += [0] * (max_len - len(pa))
    pb += [0] * (max_len - len(pb))
    if pa < pb:
        return -1
    if pa > pb:
        return 1
    return 0


def assess(platform: str, version: str) -> Tuple[str, str]:
    p = normalize_platform(platform)
    if p == 'android':
        if not parse_version(version):
            return ('UNKNOWN', 'unparseable Android version')
        return ('VULNERABLE', f'Android < {ANDROID_FIXED}') if cmp_versions(version, ANDROID_FIXED) < 0 else ('PATCHED', f'Android >= {ANDROID_FIXED}')
    if p == 'ios':
        if not parse_version(version):
            return ('UNKNOWN', 'unparseable iOS version')
        return ('VULNERABLE', f'iOS < {IOS_FIXED}') if cmp_versions(version, IOS_FIXED) < 0 else ('PATCHED', f'iOS >= {IOS_FIXED}')
    return ('UNKNOWN', 'unsupported or missing platform')


def main() -> int:
    if len(sys.argv) != 2:
        print('Usage: python3 check_authenticator_cve_2026_41615.py <mdm_export.csv>')
        return 2

    path = sys.argv[1]
    vulnerable = 0
    patched = 0
    unknown = 0
    relevant = 0

    try:
        with open(path, newline='', encoding='utf-8-sig') as f:
            reader = csv.DictReader(f)
            required = {'platform', 'version'}
            header = {h.strip().lower() for h in (reader.fieldnames or [])}
            if not required.issubset(header):
                print('UNKNOWN - CSV must include at least: platform, version')
                return 2

            print('user,device,platform,version,status,reason')
            for row in reader:
                platform = row.get('platform', '')
                version = row.get('version', '')
                user = row.get('user', row.get('username', ''))
                device = row.get('device', row.get('device_name', row.get('hostname', '')))

                status, reason = assess(platform, version)
                if normalize_platform(platform) in ('android', 'ios'):
                    relevant += 1
                if status == 'VULNERABLE':
                    vulnerable += 1
                elif status == 'PATCHED':
                    patched += 1
                else:
                    unknown += 1

                print(f'{user},{device},{platform},{version},{status},{reason}')

    except FileNotFoundError:
        print(f'UNKNOWN - file not found: {path}')
        return 2
    except Exception as e:
        print(f'UNKNOWN - error reading CSV: {e}')
        return 2

    print('---')
    print(f'Relevant rows: {relevant}')
    print(f'VULNERABLE: {vulnerable}')
    print(f'PATCHED: {patched}')
    print(f'UNKNOWN: {unknown}')

    if vulnerable > 0:
        print('OVERALL: VULNERABLE')
        return 1
    if patched > 0 and vulnerable == 0:
        print('OVERALL: PATCHED')
        return 0

    print('OVERALL: UNKNOWN')
    return 2


if __name__ == '__main__':
    sys.exit(main())
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning, treat this as a targeted identity-client exposure, not a perimeter emergency: pull an MDM/UEM report for Microsoft Authenticator versions, isolate the subset below Android 6.2605.2973 and iOS 6.8.47, and force-update privileged users first. Because the reassessed verdict is HIGH, the noisgate mitigation SLA is ≤30 days for compensating controls such as minimum-version enforcement and conditional-access hardening, and the noisgate remediation SLA is ≤180 days for full patch completion across the managed fleet.

Sources

  1. Microsoft Security Response Center advisory
  2. NVD record
  3. OpenCVE mirror of CVE record
  4. CISA Known Exploited Vulnerabilities catalog
  5. FIRST EPSS data and statistics
  6. Microsoft Support - Troubleshoot problems with Microsoft Authenticator
  7. Apple App Store - Microsoft Authenticator
  8. Google Play - Microsoft Authenticator
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.