CVE-2026-94511: Patch SQL Server 2017–2025 Against Authenticated Remote Code Execution

Note the word "authorized." An anonymous attacker on the internet can't exploit this one. Still, if someone already has a low-privilege login, a memory-corruption bug that leads to code execution on the database server is a serious problem.

What we know about CVE-2026-94511​

The public description is short, which is normal for Microsoft SQL Server advisories:

• Weakness class: CWE-122, heap-based buffer overflow.
• Impact: Remote code execution over the network.
• Severity: It has a CVSS score of 8.8/10 (HIGH severity).
• Attacker requirements: The CVSS v3.1 vector is AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. In plain terms, the attack works over the network, has low complexity, needs low privileges and requires no user interaction. The scope is unchanged, and the impact on confidentiality, integrity and availability is high.
• Exploitation status: Senserva's patch-tracking pages list the CVE as not exploited. For the SQL Server 2017 update set, Senserva reported no confirmed in-the-wild exploitation in this set today. Feedly's CVE tracker also reports no public proof of concept and no exploitation evidence so far.

In the OffSeq threat radar's words, a successful attack could mean potentially leading to full compromise of the affected SQL Server instance. In practice, a database server often holds the data attackers want, plus credentials and connections to other systems, so this is a bad place to give someone code execution.

What we don't know: Microsoft's public advisory text doesn't name the vulnerable feature, the request that triggers the bug or the attack chain. Any write-up that claims to know exactly which T-SQL feature is broken is guessing.

Section summary: This is a High-rated (8.8) heap overflow that lets an authenticated attacker run code on the server. No exploitation is known, and no root cause has been published.

Who is affected: the version map​

Several CVE databases reproduce the vendor data from the CVE record, and they agree on the affected ranges. Strix's listing, sourced to the CNA advisory (CVE.org), gives these ranges and fixed builds:

The build ranges in the table match Strix's listing. OffSeq's record gives the same 2017, 2019 and 2022 ranges and fixed builds, so that part of the table is independently corroborated.

Microsoft's own support pages confirm two of the eight updates directly:

• SQL Server 2019 GDR: KB5132751, the November 10, 2026 security update, lists CVE-2026-94511 - Microsoft SQL Server Remote Code Execution Vulnerability among its fixes.
• SQL Server 2025 GDR: Microsoft's KB5132748 page applies to SQL Server 2025 on Windows and Linux, all editions. It raises the product version to 17.0.1155.3 and lists CVE-2026-94511 among roughly three dozen SQL Server CVEs it fixes.

The other KB numbers in the table come from third-party aggregators that reproduce Microsoft's advisory data. Before you schedule a deployment, check the KB that matches your servicing branch.

Section summary: Every supported SQL Server release from 2017 through 2025 is affected, on both the GDR and CU branches. Your fix depends on which branch you're on, not just which version year.

GDR vs. CU: choosing the right update​

This is where SQL Server patching trips people up. Microsoft services each major version on two tracks:

• GDR (General Distribution Release): Security fixes only, for servers that have stayed on the baseline release without cumulative updates.
• CU + GDR: The security fix layered on top of a specific cumulative update level, such as CU27 for SQL Server 2022 or CU10 for SQL Server 2025.

A server running SQL Server 2022 CU27 needs the CU-branch package, not the GDR one. Microsoft's 2025 GDR KB makes the same point in its prerequisites: you must already have SQL Server 2025, or an earlier SQL Server 2025 GDR release, installed.

There's also a CU wrinkle in the table. The CU-branch fixes are tied to particular CU levels: CU31 for 2017, CU32 for 2019, CU27 for 2022 and CU10 for 2025. If you're on an older CU, you probably need to move up to a covered CU level as part of this cycle. Confirm that against Microsoft's guidance for your branch before you assume anything.

How to check and patch your servers​

Here's a practical sequence for Windows Server shops (and SQL Server 2025 on Linux, which is also covered):

1. Inventory every instance. That includes forgotten dev boxes, application-embedded instances and the "temporary" server from 2019 that is still in production.
2. Get each instance's build. Run SELECT SERVERPROPERTY('ProductVersion'); or SELECT @@VERSION; against each one.
3. Match the build to its branch. Use the build ranges in the table to tell whether the instance is on GDR or a CU, and which fixed build it needs.
4. Pick a delivery method. For KB5132748, Microsoft documents three routes: Windows Update, the Microsoft Update Catalog and the Microsoft Download Center. The 2025 GDR package is SQLServer2025-KB5132748-x64.exe, and Microsoft publishes its SHA-256 hash: CB08B7AB9D18CC6DC16FF519DCFBD4316D0D6275A1B1FAC7EE021BBD9BC69086. Check that hash before you install a manually downloaded package.
5. Plan a maintenance window. Senserva's analysis of the SQL Server 2022 GDR update talks about closing everything in a single reboot-and-restart window. Expect a service restart at minimum, and check the restart requirement in your branch's KB.
6. Verify after patching. Run the version query again and confirm the build matches the fixed build in the table.

One caution about the 2025 GDR KB. Microsoft notes that the Catalog package is offered to all SQL Server machines, even ones without Power BI Report Server, and says installation is optional on computers that don't host Power BI Report Server. That note is about how the Catalog distributes this package. It doesn't mean you can skip a SQL Server security fix. Read it alongside the advisory before you skip anything.

Section summary: Find each instance's build and branch, apply the matching KB, then confirm the new build number. Don't assume one package covers everything.

Why this patch cycle is bigger than usual​

CVE-2026-94511 isn't the only fix. Microsoft's SQL Server 2025 GDR KB lists 37 CVEs, a mix of remote code execution, elevation of privilege and information disclosure bugs. Senserva counts 51 CVEs in KB5132746 (SQL Server 2017 CU31) and 44 in KB5132749 (SQL Server 2017 GDR), and reports a maximum CVSS of 9.8 for both.

CVE-2026-94511 also has company in its own bug class. CVE-2026-67637, CVE-2026-67632 and CVE-2026-67391 are each listed as a heap-based buffer overflow in SQL Server [that] allows an authorized attacker to execute code over a network, each at 8.8. Patching one of these without the others gains you nothing, and since they ship in the same packages, there's no reason to try.

Reading the CVSS "Report Confidence" metric​

Some advisory pages for this CVE show an explanation of a CVSS metric about how certain it is that the vulnerability exists. That text is FIRST's definition of the CVSS v3.1 Report Confidence (RC) temporal metric. It isn't a technical description of this bug. FIRST defines three values:

• Confirmed (C): Detailed reports exist, the bug can be reproduced, or the vendor or author has confirmed it.
• Reasonable (R): Significant details are public, but some uncertainty about the root cause remains.
• Unknown (U): Reports of impact exist, but the cause is unclear or reports disagree.

In Microsoft's case the vendor published the advisory and shipped the fix, which is about as confirmed as it gets. A secondary record lists the extended vector E:U/RL:O/RC:C: exploit code maturity Unproven, an Official Fix available, and Report Confidence Confirmed. The 8.8 base score doesn't include these temporal values.

What that means in practice: "Unproven" exploitation plus "Confirmed" existence means attackers know where to start looking. Patch diffing, where researchers compare the patched and unpatched binaries, often turns a fix into a working exploit within weeks. Being listed as "not exploited" on November 13 doesn't guarantee it will stay that way.

The bottom line​

Should you panic? No. Should you patch this cycle? Yes. The login requirement lowers the risk somewhat, but SQL Server logins are rarely as scarce as security teams would like. Service accounts, shared application credentials and overprivileged reporting users are common, and any of them could be the "low privileges" this CVE needs.

Restricting network access to SQL Server ports and tightening who can log in are good habits. They don't replace the patch. If you only do three things: check each instance's build and branch, install the matching November 10, 2026 update, and confirm the new build number afterward.