A cumulative update with a large security surface
Microsoft released the SQL Server 2025 CU8 security update on September 8, 2026. The update moves SQL Server 2025 to product version 17.0.4085.5 and applies to all editions on Windows and Linux. It combines the cumulative servicing model with fixes for dozens of vulnerabilities spanning remote code execution, elevation of privilege, information disclosure, denial of service and a security-feature bypass. Those labels describe possible effects, not identical attack paths or exposure across every installation.
The detailed fix list shows why the release cannot be reduced to one headline vulnerability. Microsoft documents changes to SQL Server Agent, the WMI provider, PolyBase, Microsoft Entra authentication, backup processing, query execution, Extended Events, replication, In-Memory OLTP, XML handling and other security infrastructure. Some fixes reject malformed input or add bounds checks. Others change authorization, deserialization or internal data handling. Administrators need to map enabled components and trust boundaries to the update rather than treating the vulnerability count as a uniform risk score.
The release record also supplies a SHA-256 hash for the Windows update package and identifies installation routes through Windows Update, Microsoft Update Catalog and Microsoft Download Center. Linux systems use the configured cumulative-update repository. A published hash can help confirm that a downloaded package matches Microsoft’s listed artifact, but it does not establish that an installation completed correctly or that every database instance is running the new build.
Remote execution does not mean unauthenticated access
One included advisory, CVE-2026-67373, demonstrates the importance of prerequisites. Microsoft classifies it as an Important remote-code-execution vulnerability caused by a heap-based buffer overflow. Its CVSS vector describes a network path with low privileges required and no user interaction. Microsoft’s executive summary says an authorized attacker could trigger memory corruption through an affected SQL Server connection. Authentication is therefore part of the documented path, even though the potential impact after exploitation is severe.
At publication, Microsoft marked CVE-2026-67373 as not publicly disclosed, not exploited and less likely to be exploited. Those statements are Microsoft’s assessment at that date, not proof that exploitation is impossible or will remain absent. They also do not show how broadly the vulnerable code is exposed in real installations. The practical conclusion is narrower: CU8 supplies an official fix for a confirmed vulnerability whose documented path requires database access.
CVE-2026-66814 has a different weakness and result. Microsoft classifies it as an Important elevation-of-privilege vulnerability involving insufficiently granular access control. The advisory says an authenticated attacker with explicit permissions could elevate to SQL sysadmin. Its published vector also requires low privileges and no user interaction. Microsoft reported no public disclosure or observed exploitation and rated exploitation less likely when the advisory was issued.
These two advisories illustrate why a list containing remote execution and privilege escalation must still be read at the individual-record level. Both require an authenticated or authorized starting position according to Microsoft, but they cross different boundaries. One concerns memory corruption and code execution; the other concerns expansion of database authority. Neither supports a claim that an unauthenticated internet user can compromise every SQL Server 2025 installation.
The fixes extend beyond two representative advisories
CU8 strengthens several input-processing paths that can encounter untrusted or malformed data. Microsoft reports improved validation for S3-compatible external-storage responses in PolyBase, backup metadata handled by the Windows VSS writer and parameters used by replication procedures. It also identifies arithmetic and out-of-bounds problems in bit-shift functions, memory-corruption risks in Extended Events and failure conditions involving specially formed XML inputs.
Other changes address operational components whose exposure depends on configuration. Microsoft documents a PolyBase flaw involving deprecated raw TCP listeners, but the described path requires administrative permissions to alter service command-line parameters. A managed-backup fix matters to installations using the affected Azure procedures. Several In-Memory OLTP corrections concern native procedures processing particular string encodings, truncation behavior or packet sizes. These are material fixes, yet their prerequisites differ from an ordinary unauthenticated query against a default deployment.
The update also contains replication hardening across identifier validation, caller-supplied paths, deserialization, attestation fields and enclave buffer lengths. That breadth is useful because replication crosses service and data boundaries, but the release notes do not provide independent measurements of exploit prevalence or prevented incidents. Microsoft’s documentation establishes the intended corrections and affected components. It does not establish how often each vulnerable path appears in production.
Stricter validation breaks some linked servers
The first known regression affects linked-server queries that use the MSDASQL provider with a provider string. Microsoft says a stricter Database Engine connection-validation check can reject configurations that earlier builds accepted, returning error 7416 because no login mapping is recognized. The change is connected to a security check, but a more restrictive check can still interrupt legitimate integrations when existing identity mappings depend on the prior behavior.
This issue makes authentication topology part of CU8 planning. Teams using OLE DB over ODBC linked servers need to identify affected connections and distinguish a rejected legacy configuration from a database outage or remote-server failure. The presence of a workaround does not erase the operational cost of discovering an incompatibility after deployment. Microsoft’s release record should therefore be treated as both a security notice and a compatibility document.
Recovery monitoring can trigger an access violation
The second known regression occurs when sys.dm_exec_requests is queried while a database is recovering. Microsoft says the query can raise an access violation and produce a dump during restore, startup recovery or before an availability-group replica finishes coming online. The documented cause is an internal structure being referenced before initialization has completed. Monitoring activity can therefore trigger the failure while the database is already in a sensitive transition.
Microsoft lists three temporary responses: enabling trace flag 4696, avoiding the affected query during recovery or uninstalling the update. The trace flag restores earlier behavior but can cause monitoring queries on secondary replicas to return errors 976 or 978. Each option changes observability, security posture or patch state, so none should be described as a cost-free correction. Microsoft says it is investigating a fix, but the September 8 record does not supply a resolution date.
This regression is especially relevant to automated monitoring because a routine diagnostic query may run without an operator deliberately targeting a recovering database. Teams need to account for jobs, stored procedures and availability-group monitoring that call the affected dynamic management view. That is a deployment concern created by the update itself, not evidence that the security fixes are unnecessary.
Patching remains one layer of database security
CU8 closes documented vulnerabilities while exposing two concrete rollout risks. The sound interpretation is neither to delay every installation nor to assume that cumulative updates are operationally transparent. Administrators can prioritize the security fixes according to enabled features and access paths, while separately accounting for MSDASQL linked servers and recovery-time monitoring before moving the build across production systems.
Microsoft also recommends Extended Protection encryption for SQL Server on Windows. That control is separate from the CU8 fixes. Installing version 17.0.4085.5 does not establish least privilege, network isolation, encrypted transport, protected backups or reliable recovery. The release advances the software’s security boundary, but its value depends on completing the update and preserving the surrounding controls that determine who can connect, which components are exposed and how a failed database is restored.