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.
4 steps from start to impact.
Find a victim running the vulnerable app
- Victim uses Microsoft Authenticator on Android <
6.2605.2973or iOS <6.8.47 - Attacker can target or influence the victim user
- 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
Trigger the vulnerable client path
- Victim performs the required interaction
- A reachable vulnerable code path exists in the mobile client
- 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
Exfiltrate sensitive Authenticator data over the network
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.- The vulnerable flow handles secrets or security-relevant metadata
- The attacker can receive or observe the disclosed material
- 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
Convert leaked data into account impact
- Leaked data is reusable or actionable
- Targeted accounts have meaningful privileges
- 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
The supporting signals.
| In-the-wild status | No 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 availability | No 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. |
| EPSS | 0.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 status | Not listed in CISA KEV; there is therefore no federal due-date signal or public exploitation designation from CISA. Source: KEV catalog. |
| CVSS vector reality check | Microsoft 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 versions | Affected 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 versions | Update 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 reality | This 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 timeline | Published by Microsoft on 2026-05-14; NVD shows publication on 2026-05-14 and modification on 2026-05-15. Sources: OpenCVE, NVD. |
| Researcher / reporting org | Public record identifies Microsoft as the CNA/source, but the reviewed sources did not name an external reporting researcher. Source: OpenCVE, MSRC advisory. |
noisgate verdict.
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.
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.
What to do — in priority order.
- Enforce app minimum versions — Use MDM/UEM policy to require Android
6.2605.2973+and iOS6.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. - 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.
- 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.
- 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.
- 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.
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.
#!/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())
If you remember one thing.
Sources
- Microsoft Security Response Center advisory
- NVD record
- OpenCVE mirror of CVE record
- CISA Known Exploited Vulnerabilities catalog
- FIRST EPSS data and statistics
- Microsoft Support - Troubleshoot problems with Microsoft Authenticator
- Apple App Store - Microsoft Authenticator
- Google Play - Microsoft Authenticator
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.