Patch CVE-2026-26116: SQL Server GDR and CU Updates by Build

Microsoft released an important SQL Server security advisory on March 10, 2026 that maps CVE‑2026‑26116 — an elevation‑of‑privilege SQL Server vulnerability (SQL injection class) — to per‑SKU security updates; the immediate, non‑negotiable action for any SQL Server administrator is to identify your instance build and apply the exact GDR or CU security package Microsoft published for your installed baseline.

Background / Overview​

CVE‑2026‑26116 is reported by Microsoft as an SQL‑injection–style flaw in SQL Server that can allow an authorized network actor with low privileges to escalate to higher privileges on the database engine. Public scoring and vulnerability trackers list the issue with a high base severity (CVSS 3.1 ≈ 8.8), reflecting network attack vector, low complexity, and high confidentiality/integrity/availability impact if successfully exploited. As with many elevation‑of‑privilege flaws, successful exploitation could permit data exposure, modification, or persistent compromise of administrative accounts.
Microsoft addressed CVE‑2026‑26116 in the March 10, 2026 security wave by publishing multiple per‑product updates (GDR and CU bundles) mapped to concrete SQL Server build numbers. The vendor’s guidance — and community best practice — is straightforward: determine your SQL Server build number, find the matching security package in the mapping Microsoft published, and install that update. Community reporting and patch‑mapping writeups have reinforced this one‑to‑one mapping approach for SQL Server builds.

---

Which SQL Server releases are affected​

Microsoft’s March 10, 2026 security updates target supported SQL Server baseline releases and cover multiple build ranges via either GDR or CU update packages. The vendor’s KB entries for the March 10 updates list the per‑product packages that include the fix (examples below — apply the matching package for your build):

• SQL Server 2025: GDR and RTM/CU mappings are available (see the SQL Server 2025 KB entries).
• SQL Server 2022: CU and RTM GDR packages were released for the relevant build ranges.
• SQL Server 2019, 2017, 2016: Microsoft published CU+GDR and RTM+GDR update packages per build range; the SQL Server 2019 KB entry for March 10, 2026 is an example.

Important operational note: if your SQL Server build is not represented in Microsoft’s published mapping then that specific build is outside of vendor support for this update; in practice that means you must either (a) upgrade the instance to a supported baseline (apply the latest Service Pack or move to a newer SQL Server product) or (b) move to a supported CU/GDR path before you can install this security fix.

---

Immediate actions — what you must do now​

Follow this prioritized checklist. Each item is short, actionable, and safe for production environments when done correctly.

• Inventory: Identify every SQL Server instance (on‑premises, virtual machines, containers, and cloud IaaS) and record instance name, machine name, and network exposure (public/internet‑facing vs internal).
• Discover build: For each instance, capture the exact SQL Server product build string. The quickest, authoritative ways are:
• Run SELECT @@VERSION; in a query window (returns product build and edition).
• Use SELECT SERVERPROPERTY('ProductVersion'), SERVERPROPERTY('ProductLevel'), SERVERPROPERTY('Edition'); for discrete fields you can parse automatically.
• Alternatively, consult the SQL Server ERRORLOG or the file properties of sqlservr.exe for the installed file version. Microsoft documents these methods in its “how to determine the version, edition, and update level of SQL Server” guidance.
• Map build to the correct package: Take the ProductVersion number and look up the exact build range in Microsoft’s published mapping table for the March 10, 2026 security wave. The KB articles for each SQL Server release list the build numbers and the corresponding KB package you must apply. Do not approximate — install the package that corresponds to the build range your instance reports.
• Test and stage: Prepare a test environment that mirrors your production configuration (same CU/GDR level, same clustered or Availability Group topology). Apply the update to test instances and run application smoke tests and representative workloads.
• Backup and snapshot: Before any production patching, take full database backups and create VM snapshots or host backups as applicable. Confirm restore / rollback procedures.
• Patch in maintenance windows: For clustered or high‑availability topologies follow a rolling updatsive replica / node first, failover, then update the now‑passive node, validate, and repeat until all nodes are patched. Microsoft and community guidance for Always On and FCI patching describes this approach.

If you run SQL Server in cloud IaaS (Azure VMs, AWS EC2, etc.), Microsoft notes these security updates can be delivered via Microsoft Update or by manual download and installation; either approach is acceptable — but ensure you test the exact package before mass deployment.

---

How to determine the exact KB you need (practical example)​

• Step A — capture the build: run SELECT SERVERPROPERTY('ProductVersion'); Suppose the result is 16.0.4240.4.
• Step B — match the build to Microsoft’s mapping table: if 16.0.4240.4 appears in the SQL Server 2022 CU23+GDR mapping then the KB package for that mapping (for March 10, 2026) is the SQL Server 2022 CU23+GDR security update. Microsoft’s per‑release KB pages explicitly list the “Apply if current product version is …” ranges — use those values.

Do this for each instance. Community posts and patching guides echo this method and emphasize: the single most common patching mistake is applying the wrong package because the build value was misread or assumed.

---

GDR vs CU updates — what they mean and how to choose​

Microsoft maintains two servicing channels for SQL Server updates:

• GDR (General Distribution Release) — cumulative packages that include security fixes targeted for the specific baseline (RTM or Service Pack). GDR packages are intentionally minimal and focus on security and important reliability fixes only.
• CU (Cumulative Update) — cumulative packages that include all functional fixes and the security fixes for the given baseline. CU packages are larger, include behavioral and functional changes, and are commonly used by teams that accept a faster cadence of nonsecurity fixes.

Key operational rules you must know:

• If your installation is on a baseline and you have only applied GDR updates to date, you may choose the GDR security package for this advisory. If you have already applied past CU updates, choose the CU security package for this advisory. Microsoft respects the existing servicing channel used on that installation.
• You are allowed to switch from the GDR servicing path to the CU servicing path one time. Importantly, once you apply a CU package to an installation that previously only received GDR updates, you cannot revert back to the GDR servicing track for that installation. This is a one‑way decision; plan accordingly.

If you’re unsure which path your servers have been following, check the build history of each instance; deployments that received cumulative updates in the past are on the CU path. When in doubt and when long‑term stability is a priority, many enterprises prefer to stay on GDR updates for security‑only fixes, and evaluate CU adoption in a controlled release window.

---

Deployment notes for clustered and high‑availability environments​

Patching SQL Server on a single instance is straightforward. Patching an Always On Availability Group (AOAG) or a Failover Cluster Instance (FCI) needs planning:

• For AOAG (Always On Availability Groups): patch secondary replicas first (manual failover if planned), fail over to the patched replica, and patch the former primary. Validate that the database state, replication, and client connectivity remain intact. Microsoft and community guidance recommend staging and rolling updates to avoid simultaneous downtime.
• For FCIs: perform node‑by‑node updates. Move cluster ownership off the node you plan to patch, patch it, validate, then move roles back and proceed to the next node. Use cluster‑aware maintenance and follow vendor guidance for patch order and host‑level vs instance‑level steps.
• For Availability Groups with distributed replicas or cross‑region replicas: schedule additional validation steps (seed validation, latency checks) after patching before returning to normal production load.

Document the steps and automate what you can. Several community playbooks and Microsoft tech community posts provide tested runbooks for these procedures; adopt one that matches your topology and test it in a non‑production environment before rolling to production.

---

If you cannot patch immediately — short‑term mitigations​

If for operational reasons you cannot apply the Microsoft security update right away, apply compensating controls to minimize risk:

• Limit network exposure: ensure SQL Server endpoints are not internet‑facing. Block SQL Server TCP port 1433 and related management ports at the perimeter and internal firewalls except for known, necessary hosts.
• Restrict access: enforce least privilege for SQL logins; remove or restrict accounts that are not required. Use Windows Authentication where possible and enforce multi‑factor authentication for support/admin accounts.
• Harden surface area: disable SQL Browser service if not required, disable unused features (xp_cmdshell when not used), and review server‑level permissions.
• Monitor aggressively: enable auditing, Extended Events, and alerting for unexpected schema‑altering statements, privilege changes, or unusual high‑privilege queries. Correlate logs in your SIEM and enable alerts for suspicious SQL commands and large data exfiltration patterns.
• Credential hygiene: rotate high‑privilege credentials and service account passwords that could be abused if a local privilege is obtained.
• Network segmentation: isolate database servers on protected subnets with strict ACLs and deny by default.

These mitigations reduce the attack surface but are not substitutes for installing the official security update. Community patch guidance and vendor advisories urge fast patching because compensating controls are only partial defenses.

---

Detection and verification post‑patch​

After you install the published update:

• Confirm the ProductVersion matches the patched build using SERVERPROPERTY('ProductVersion').
• Check SQL Server Error Logs and the Windows Application Event Log for any service restart or error messages produced during installation.
• Run application smoke tests, run key queries under load, and validate backup/restore and HA failover workflows.
• Monitor telemetry and security logs for any anomalous activity that predates the patch (possible indicators of prior exploitation). If you observe suspicious activity, escalate to incident response and preserve logs for forensic analysis.

Community writeups around recent SQL Server patches have seen a handful of post‑update operational issues (service restarts or specific configuration interactions); verify functional behavior in a test window before mass rollout and have a rollback plan (database backups + VM snapshot) in place.

---

Practical commands and quick reference​

• Determine SQL Server version and edition:
• SELECT @@VERSION;
• SELECT SERVERPROPERTY('ProductVersion') AS ProductVersion, SERVERPROPERTY('ProductLevel') AS ProductLevel, SERVERPROPERTY('Edition') AS Edition;
• Check error log: the startup banner includes the build string.
• What to map to Microsoft’s release table:
• Use the numeric ProductVersion (for example, 16.0.4240.4) and match to the ranges in Microsoft’s KB for the March 10, 2026 release. Do not rely on the year or major version alone — exact build matters.
• Example KB entries (March 10, 2026 wave):
• SQL Server 2025 GDR/RTM mapping is listed under the SQL Server 2025 KB package for March 10, 2026.
• SQL Server 2019 CU32+GDR mapping is in the SQL Server 2019 KB for March 10, 2026.
• SQL Server 2022 CU23+GDR mapping is in the SQL Server 2022 KB for March 10, 2026.

---

Risks, implications, and what to watch for​

• Exploitability and impact: public trackers list this CVE as high severity with a CVSS near 8.8. The combination of network attack vector + low privileges required raises the risk profile for internal and lateral movement exploitation. Prioritize instances that are network‑accessible or host sensitive data.
• Operational friction: some organizations experience installer or clustering interactions when applying certain SQL Server updates. Mitigate by testing in staging and by following vendor‑recommended rolling update steps for HA topologies.
• Servicing path decisions: switching servicing tracks (GDR → CU) is one‑way. If your environment depends on absolute behavioral stability and minimal functional changes, evaluate staying on the GDR branch where feasible; if you accept ongoing fixes and functional improvements, CU may be preferable. Plan the one‑time switch carefully.
• Third‑party drivers and clients: Microsoft’s SQL Server security updates often include related driver or component updates. Confirm that your application stacks and third‑party drivers are compatible with the patched build and test client connectivity after patching.

---

Recommended timeline and priority matrix​

• Within 24 hours: inventory and build capture for all instances; identify public‑facing or internet‑connected instances and classify them as highest pri–72 hours: test the vendor KB package that maps to each high‑risk instance in a staging system that mirrors production.
• Within 7 days: deploy to production for high‑risk and internet‑facing instances during scheduled maintenance windows.
• Within 30 days: complete rollout to internal and lower‑risk systems, unless business constraints require a longer window — in that case, apply compensating controls and document residual risk.

This schedule matches industry practice for high‑severity, high‑impact vulnerabilities and aligns with guidance issued during the March 2026 Patch Tuesday wave.

---

Final checklist — practical, at‑a‑glance​

• Capture build: SELECT SERVERPROPERTY('ProductVersion').
• Match build to Microsoft’s KB mapping for March 10, 2026 and choose the correct GDR or CU package.
• Test in a staging environment identical to production topology.
• Backup databases and snapshot VMs prior to installation.
• Apply update using a rolling strategy for AOAG/FCI topologies, validate, then move to the next node.
• Validate application functionality and monitor for errors/anomalies after patching.
• If you cannot patch immediately, isolate and harden SQL endpoints and intensify monitoring.

---

Closing analysis — strengths of Microsoft’s response and remaining risks​

Microsoft’s approach for CVE‑2026‑26116 follows a proven pattern: map each supported SQL Server baseline and build range to a specific security package (GDR or CU), publish KB entries per release, and allow admins to pick the servicing path consistent with their prior servicing decisions. This approach gives administrators clear, prescriptive steps to remediate the issue while preserving servicing preferences (GDR or CU). The vendor’s per‑build mapping reduces ambiguity about which package to install and helps avoid the common mistake of applying the wrong update.
However, risks remain:

• The vulnerability’s high severity and low privilege requirement mean exposed or misconfigured instances are attractive targets; defenders must prioritize patching network‑accessible SQL Servers.
• Operational complexity in clustered and HA environments can delay deployments; organizations must invest in test and rollout automation to avoid long unpatched windows.
• The one‑way servicing path decision (GDR → CU) requires coordination between DBAs, platform engineering, and application owners. Poorly coordinated servicing choices can create long‑term maintenance problems.

Finally, while Microsoft’s KB mapping and updates are authoritative, any claim about the presence or absence of in‑the‑wild exploitation must be treated as time‑sensitive. At the time Microsoft published the March 10, 2026 advisories the public technical information did not show a widely circulating proof‑of‑concept; that can change rapidly. If you have a security operations function, treat this CVE as high priority for both patching and for retrospective log review to identify suspicious pre‑patch activity.

---

Apply the vendor guidance now: identify your build, pick the exact KB package Microsoft mapped to that build (GDR or CU as appropriate), test, and deploy with backups and rolling procedures for HA topologies. The technical steps are simple; the operational discipline to execute them across an estate is what separates secure environments from compromised ones.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center