CVE-2026-54117 is a high-severity Microsoft SQL Server 2025 remote code execution vulnerability that Microsoft disclosed on July 14, 2026, with a CVSS 3.1 score of 8.8. Its Network attack vector and Low attack complexity make exploitation comparatively practical, but the vulnerability is not unauthenticated: an attacker must already possess some level of authorization to the targeted SQL Server.
Microsoft’s Security Response Center describes the flaw as deserialization of untrusted data in SQL Server. The National Vulnerability Database, reproducing Microsoft’s assessment, identifies it as CWE-502 and lists the complete vector as
That full vector matters. AV:N and AC:L do not, by themselves, mean that every vulnerable SQL Server can be immediately compromised by anyone on the internet. They mean that an attacker can send the exploit over a network and does not need to overcome unusual technical conditions once the other prerequisites have been satisfied.
The Network rating, written as
That network might be the public internet, but it could also be an internal corporate network, a cloud virtual network, a VPN-connected environment, or a network segment reachable after another system has been compromised. CVSS describes the technical reach of the exploit; it does not inspect an organization’s firewall rules or determine whether a particular database is publicly exposed.
An internet-facing SQL Server is therefore at greater immediate risk than an instance accessible only from a restricted application subnet. However, an internal-only server should not be treated as safe. Attackers commonly use compromised workstations, application servers, stolen VPN credentials, and cloud workloads as footholds from which to reach databases that are not directly exposed to the internet.
Administrators should determine where SQL Server’s listening ports are reachable rather than relying solely on whether an instance appears in a public asset inventory. Named instances, nonstandard ports, SQL Server Browser, load balancers, firewall forwarding rules, and cloud security-group changes can all create paths that are easy to overlook.
The practical distinction is:
In operational terms, the attacker should not need to win a race condition, predict a highly variable memory state, intercept another user’s session, or wait for an administrator to perform an unusual action. A working exploit is consequently more likely to behave consistently across suitable targets than one rated High complexity.
Low complexity does not necessarily mean that writing the first exploit is trivial. Deserialization vulnerabilities can require knowledge of accepted object formats, reachable code paths, and the behavior of the affected component. The rating instead describes the conditions needed to exploit the flaw once an attacker has a suitable payload.
That distinction matters after technical details or proof-of-concept code become available. A repeatable network-delivered exploit is easier to automate and incorporate into post-compromise tooling than an exploit that depends on narrow timing or deployment-specific circumstances.
Microsoft’s vector also assigns
An attacker therefore needs some existing access, such as a valid low-privilege account or another form of authorization accepted by the affected SQL Server configuration. The public advisory information does not establish that every ordinary database login can necessarily reach the vulnerable path, so administrators should avoid inventing narrower exploit requirements until Microsoft provides more technical detail.
The authorization requirement lowers exposure compared with an unauthenticated network RCE, but it does not make the vulnerability minor. Database credentials may be stored in application configuration files, deployment pipelines, service accounts, scripts, backups, developer workstations, or cloud secret stores. A compromise elsewhere in the environment can turn those credentials into a route toward SQL Server.
Low-privilege access also appears in environments where users, reporting tools, vendors, or applications receive restricted database accounts. CVE-2026-54117 potentially converts that limited access into code execution, crossing the security boundary that database permissions were intended to enforce.
The remaining CVSS metrics explain the 8.8 High score. Microsoft rates confidentiality, integrity, and availability impact as High, indicating that successful exploitation could have severe consequences for data secrecy, data modification, and service availability. Scope is Unchanged, meaning the assessed security impact remains within the vulnerable component’s security authority rather than formally crossing into a separately managed security boundary.
Remote code execution should still be treated as a host-level incident risk. SQL Server commonly runs under a dedicated Windows service identity, and any code obtained through exploitation would initially be constrained by the rights and environment associated with the affected process. Those rights vary considerably between deployments, making service-account privileges and local hardening important secondary controls.
SQL Server servicing branches should not be mixed casually. Organizations following the General Distribution Release path generally apply security and critical fixes without adopting the broader collection of changes in a cumulative update, while CU deployments should remain on the appropriate cumulative servicing path. Administrators should select the Microsoft package matching the instance’s installed edition, architecture, and servicing branch.
Before deployment, IT teams should identify every SQL Server 2025 instance, record its exact build, and map which systems can connect to it. Internet exposure and broad internal reachability should raise patching priority, as should instances using shared credentials or serving applications that could be compromised independently.
Until the update is installed, defensive steps should reduce opportunity rather than be mistaken for a complete fix:
Microsoft’s Security Response Center describes the flaw as deserialization of untrusted data in SQL Server. The National Vulnerability Database, reproducing Microsoft’s assessment, identifies it as CWE-502 and lists the complete vector as
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H.That full vector matters. AV:N and AC:L do not, by themselves, mean that every vulnerable SQL Server can be immediately compromised by anyone on the internet. They mean that an attacker can send the exploit over a network and does not need to overcome unusual technical conditions once the other prerequisites have been satisfied.
Network Reachability Expands the Attack Surface
The Network rating, written as AV:N, means exploitation does not require local access to the Windows server, physical access to the machine, or the ability to run an executable directly on it. The attacker can interact with the vulnerable SQL Server component through a network connection.That network might be the public internet, but it could also be an internal corporate network, a cloud virtual network, a VPN-connected environment, or a network segment reachable after another system has been compromised. CVSS describes the technical reach of the exploit; it does not inspect an organization’s firewall rules or determine whether a particular database is publicly exposed.
An internet-facing SQL Server is therefore at greater immediate risk than an instance accessible only from a restricted application subnet. However, an internal-only server should not be treated as safe. Attackers commonly use compromised workstations, application servers, stolen VPN credentials, and cloud workloads as footholds from which to reach databases that are not directly exposed to the internet.
Administrators should determine where SQL Server’s listening ports are reachable rather than relying solely on whether an instance appears in a public asset inventory. Named instances, nonstandard ports, SQL Server Browser, load balancers, firewall forwarding rules, and cloud security-group changes can all create paths that are easy to overlook.
The practical distinction is:
- An internet-accessible instance may be reachable directly by a remote attacker who also obtains valid credentials.
- An internal instance may become reachable during lateral movement from another compromised system.
- A tightly segmented instance limits possible attack paths, but segmentation does not remove the need to patch.
AV:N as proof that the vulnerability is automatically internet exploitable in every deployment would be too broad.Low Complexity Means Fewer Things Must Go Right
The Low attack complexity rating,AC:L, indicates that exploitation does not depend on conditions outside the attacker’s control beyond the documented prerequisites. Microsoft says an attacker does not require significant prior knowledge of the target and can achieve repeatable success with a payload against the vulnerable component.In operational terms, the attacker should not need to win a race condition, predict a highly variable memory state, intercept another user’s session, or wait for an administrator to perform an unusual action. A working exploit is consequently more likely to behave consistently across suitable targets than one rated High complexity.
Low complexity does not necessarily mean that writing the first exploit is trivial. Deserialization vulnerabilities can require knowledge of accepted object formats, reachable code paths, and the behavior of the affected component. The rating instead describes the conditions needed to exploit the flaw once an attacker has a suitable payload.
That distinction matters after technical details or proof-of-concept code become available. A repeatable network-delivered exploit is easier to automate and incorporate into post-compromise tooling than an exploit that depends on narrow timing or deployment-specific circumstances.
Microsoft’s vector also assigns
UI:N, meaning no separate user interaction is required. An administrator does not need to open a document, click a link, or approve a prompt for exploitation to proceed. Once an authorized attacker can communicate with the vulnerable functionality, exploitation can occur without recruiting another user into the attack chain.The Required Login Changes the Threat Model
CVE-2026-54117 carriesPR:L, or Low privileges required. Microsoft’s description specifically refers to an authorized attacker, making this different from a pre-authentication flaw that can be triggered by any anonymous client reaching the database service.An attacker therefore needs some existing access, such as a valid low-privilege account or another form of authorization accepted by the affected SQL Server configuration. The public advisory information does not establish that every ordinary database login can necessarily reach the vulnerable path, so administrators should avoid inventing narrower exploit requirements until Microsoft provides more technical detail.
The authorization requirement lowers exposure compared with an unauthenticated network RCE, but it does not make the vulnerability minor. Database credentials may be stored in application configuration files, deployment pipelines, service accounts, scripts, backups, developer workstations, or cloud secret stores. A compromise elsewhere in the environment can turn those credentials into a route toward SQL Server.
Low-privilege access also appears in environments where users, reporting tools, vendors, or applications receive restricted database accounts. CVE-2026-54117 potentially converts that limited access into code execution, crossing the security boundary that database permissions were intended to enforce.
The remaining CVSS metrics explain the 8.8 High score. Microsoft rates confidentiality, integrity, and availability impact as High, indicating that successful exploitation could have severe consequences for data secrecy, data modification, and service availability. Scope is Unchanged, meaning the assessed security impact remains within the vulnerable component’s security authority rather than formally crossing into a separately managed security boundary.
Remote code execution should still be treated as a host-level incident risk. SQL Server commonly runs under a dedicated Windows service identity, and any code obtained through exploitation would initially be constrained by the rights and environment associated with the affected process. Those rights vary considerably between deployments, making service-account privileges and local hardening important secondary controls.
SQL Server 2025 Builds Need Immediate Inventory
The CVE record available on July 14 lists Microsoft SQL Server 2025 on the CU servicing branch and SQL Server 2025 for x64-based systems on the GDR branch. The published affected-version data points administrators toward fixed build levels of 17.0.4060.2 for the CU branch and 17.0.1125.2 for the GDR branch.SQL Server servicing branches should not be mixed casually. Organizations following the General Distribution Release path generally apply security and critical fixes without adopting the broader collection of changes in a cumulative update, while CU deployments should remain on the appropriate cumulative servicing path. Administrators should select the Microsoft package matching the instance’s installed edition, architecture, and servicing branch.
Before deployment, IT teams should identify every SQL Server 2025 instance, record its exact build, and map which systems can connect to it. Internet exposure and broad internal reachability should raise patching priority, as should instances using shared credentials or serving applications that could be compromised independently.
Until the update is installed, defensive steps should reduce opportunity rather than be mistaken for a complete fix:
- Restrict SQL Server access to application hosts, management networks, and explicitly approved administrators.
- Remove unnecessary public exposure and review cloud firewall, network security group, and load-balancer rules.
- Disable or rotate unused SQL logins, application secrets, and service credentials.
- Review the Windows account running SQL Server and remove rights not required by the deployment.
- Monitor for unexpected database connections, unusual authentication patterns, and child processes originating from SQL Server services.
References
- Primary source: MSRC
Published: 2026-07-14T07:00:00-07:00
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Official source: support.microsoft.com
KB5058712 - Description of the security update for SQL Server 2022 GDR: July 8, 2025 | Microsoft Support
KB5058712 - Description of the security update for SQL Server 2022 GDR: July 8, 2025support.microsoft.com - Official source: techcommunity.microsoft.com
- Related coverage: keenfinity-group.com
