Azure SQL Database EUVD-2026-63622

Exploitation requires the attacker to already hold a high-privileged, authenticated Azure SQL Database principal (CVSS PR:H); it is not reachable from an unauthenticated or low-privileged position, and there is no path for anonymous network attackers. Given AV:N/AC:L/UI:N, once that privileged access exists the escalation is remote, low-complexity, and needs no user interaction. Limiting factors: the mandatory pre-existing high-privilege foothold, and that the impact concerns Microsoft's managed service where the vendor has already deployed the fix; the primary residual exposure is any environment where highly-privileged accounts are broadly distributed or shared across tenants or databases.

The CVSS 3.1 base score is 9.1 (Critical), driven by network vector (AV:N), low complexity (AC:L), no user interaction (UI:N), scope change (S:C), and full CIA impact - but tempered by PR:H, meaning the attacker must already hold high privileges. That PR:H requirement is the decisive limiter: this is not an unauthenticated internet takeover but an escalation available to an already-trusted, high-privileged account. EPSS and SSVC data were not provided, so exploitation probability cannot be quantified - state explicitly that no probabilistic signal is available. There is no CISA KEV listing and no referenced POC, so exploitation status is 'no public exploit identified at time of analysis.' Net assessment: a genuine high-severity authorization-boundary flaw whose real-world priority is bounded by the need for pre-existing privileged access - high priority for shared/multi-tenant Azure SQL environments, but not a mass, drive-by exploitation risk.

An attacker who has already obtained a high-privileged Azure SQL principal - for example via compromised admin credentials or an over-permissioned service account - sends crafted requests over the network that exploit the improper access-control check to elevate beyond their intended authorization, crossing a trust boundary to reach data or control it should not have. Given AV:N/AC:L/UI:N, the action is remotely repeatable and needs no victim interaction once the privileged foothold exists. No public POC is currently identified.