Azure SQL Database CVE-2026-68789

Exploitation requires the attacker to already be an authorized, authenticated principal on the target Azure SQL Database (CVSS PR:L) with network reachability to the service (AV:N); it does not require user interaction or high privileges. The limiting factor is that low-privileged database access must first be obtained - a compromised application login, an over-provisioned service account, or a semi-trusted tenant user - so purely external, unauthenticated attackers cannot trigger it directly. No specific non-default feature toggle is named in the description; the vulnerable SQL-command path is part of the managed service, making the authenticated foothold the primary prerequisite.

The CVSS 3.1 base score is 9.9 (Critical) with vector AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H: network-reachable, low attack complexity, only low privileges required, no user interaction, scope change, and full confidentiality/integrity/availability impact. The one genuine barrier is PR:L - the attacker must already hold an authenticated, low-privileged foothold in the target database, so this is a post-authentication privilege escalation rather than an unauthenticated internet-wide threat. No EPSS score, KEV listing, or POC was supplied, so real-world exploitation pressure cannot be quantified from the input; the absence of KEV means no confirmed active exploitation, and the absence of POC data means public exploit status is unknown rather than negative. On balance this is a real priority for any tenant that grants database access to semi-trusted principals (application service accounts, multi-tenant apps, contractors), but the required authenticated foothold makes mass, opportunistic exploitation less likely than the raw 9.9 suggests.

An attacker who already holds a low-privileged login to a target Azure SQL Database - for example a compromised application service account or an over-shared multi-tenant credential - submits input crafted to inject additional SQL into a vulnerable command path. The injected statements execute across a privilege boundary, letting the attacker read or modify data and escalate to higher database privileges. No user interaction is needed and attack complexity is low; no public POC was identified in the provided data.