Azure AD B2C EUVD-2026-70795

Per the CVSS vector (AV:N/AC:L/PR:N/UI:N), exploitation requires only network reachability to the affected Azure AD B2C endpoint, with no authentication and no user interaction against default service behavior. The specific prerequisite from CWE-639 is the ability to supply or manipulate the user-controlled key/identifier that the service trusts for authorization; the limiting factor is that Microsoft operates and has remediated the service centrally, so the exploitable window is bounded by Microsoft's deployment and the exact affected configuration is not enumerated in the sparse MSRC advisory.

The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N) is the theoretical worst case: network-reachable, low complexity, no privileges, no user interaction, scope change, high confidentiality and integrity impact, no availability impact - yielding the 10.0. As a signal this is a genuine top-priority issue: authorization bypass in a widely used cloud identity service is directly exploitable and high-value. However, corroborating signals are thin - no EPSS score, no KEV listing, and no POC are present in the input, so 'automatable/widespread exploitation' cannot be asserted, only the high potential impact. Two caveats: (1) as a Microsoft-operated cloud service, the vulnerable code is fixed server-side by Microsoft rather than by customer patching, which limits the exposure window; and (2) the single MSRC reference is a sparse update-guide stub, so exact affected configurations and exploit specifics are not independently verifiable. Treat as high priority for awareness/monitoring, but note the impact rating rests on Microsoft's self-report, not on public exploitation evidence.

An unauthenticated attacker sends crafted requests to a B2C endpoint, substituting another principal's identifier in a user-controlled key field to bypass the authorization check and obtain elevated access to accounts or protected resources. Because scope is changed (S:C), the impact reaches resources beyond the attacker's own security context, such as other users' or tenants' data. No public POC is currently identified, so this reflects the CVSS-implied attack path rather than an observed exploit.