Dangerous SQL Server Builds: How to Check Your Version and Patch Safely

Every SQL Server instance runs on a specific build, and that build tells you which updates have been applied to the server. From time to time, Microsoft identifies bugs in particular builds that can cause data corruption, incorrect query results or security vulnerabilities, and fixes them in subsequent updates. Those fixes only help once the update is installed, however, and a significant share of the servers we review are still running the build they were installed with.

In this guide, we explain what a build number tells you, which situations make a build genuinely risky, how to check where your servers stand and how to plan updates without putting production at risk.

What a SQL Server Build Number Tells You

A SQL Server version is expressed as a four-part number such as 16.0.4035.4. The first part identifies the major version, and the third part is the build number, which shows which Cumulative Update (CU) or security update (GDR) has been applied. The major version numbers map to product versions as follows:

You can retrieve your server’s version and update details with the SERVERPROPERTY function, without having to parse any text:

SELECT
    SERVERPROPERTY('ProductVersion')             AS product_version,
    SERVERPROPERTY('ProductMajorVersion')        AS major_version,
    SERVERPROPERTY('ProductLevel')               AS product_level,   -- RTM, SP1 ...
    SERVERPROPERTY('ProductUpdateLevel')         AS update_level,    -- CU4 ...
    SERVERPROPERTY('ProductUpdateReference')     AS kb_article,      -- KB5026717 ...
    SERVERPROPERTY('Edition')                    AS edition,
    SERVERPROPERTY('ResourceLastUpdateDateTime') AS last_update_applied;

ProductUpdateLevel and ProductUpdateReference were introduced with updates released from late 2015 onwards, so they may return NULL on older builds. ResourceLastUpdateDateTime gives a practical indication of when the server was last updated.

What Makes a Build Risky

Every update contains dozens of fixes, and most of them address problems that only appear under specific conditions. For a build to be considered genuinely risky, one of the following four situations usually applies.

1. Bugs that cause data corruption

The best-known example in this category is the online index rebuild bug in certain builds of SQL Server 2012 and SQL Server 2014. When an online index rebuild ran in parallel while concurrent operations modified many rows in the same table, specific conditions could lead to clustered index corruption and data loss. A common trigger was index maintenance running on a table that replication was updating heavily at the same time. Microsoft resolved the issue with KB2969896, and until the fix was applied the recommended workaround was to run online index rebuilds serially with MAXDOP = 1.

2. Bugs that return incorrect results

Because they don’t raise an error, these bugs often go unnoticed for a long time. In SQL Server 2022 CU4, for example, queries that used indexes defined with descending sort order (DESC) and contained WHERE ... IN or multiple equality predicates could return incorrect results. Microsoft listed the problem among CU4’s known issues and fixed it in CU5. The documented workarounds were to uninstall the update, or to enable trace flag 13166 and then run DBCC FREEPROCCACHE.

3. Updates that Microsoft has withdrawn

Occasionally, a serious problem is discovered after an update has been released, and Microsoft withdraws it from distribution. SQL Server 2019 CU7 is one example. Because of a reliability issue in the database snapshot feature, CU7 was removed from the Download Center, the Microsoft Update Catalog and the Linux repositories, and the fix was delivered in CU8. The issue was relevant not only to environments that used snapshots explicitly, but to any environment running DBCC CHECKDB, which relies on an internal database snapshot. Keeping a locally downloaded copy of a withdrawn update also creates the risk of installing it later without realizing it was pulled.

4. Security vulnerabilities and unsupported versions

Security exposure also depends on the build level. The MS15-058 bulletin released in July 2015, for instance, addressed remote code execution vulnerabilities across SQL Server versions from 2008 to 2014, and builds that never received that update still carry the same exposure today. More importantly, a version that has reached the end of support no longer receives new security fixes. Extended support for SQL Server 2016 ended in July 2026, and from that point security updates are available only through the paid Extended Security Updates program. For planning a move to a supported version, see our SQL Server upgrade guide.

How to Check Where Your Servers Stand

Scripts that hard-code specific build ranges quickly become outdated, because new updates and new known issues are published every month. Instead, we recommend turning the following steps into a regular process:

1. Collect build information. Run the query above on every instance. If you manage many servers, you can run it across a group of servers at once with SSMS Registered Servers or a Central Management Server.
2. Compare against Microsoft’s version list. Microsoft’s “Latest updates and version history for SQL Server” page lists every CU and GDR build released for each version, together with its KB number. This shows which update you’re on and how far you are behind the latest build.
3. Read the known issues. Each CU’s KB article includes a “Known issues in this update” section. Review it both for the CU you’re running and for the CU you plan to install.
4. Focus on the features you use. Search the fix lists of later CUs for entries related to features in your environment, such as Always On, columnstore, Query Store or replication. If a data corruption or incorrect results fix applies to you, prioritize the update.

GDR or CU?

Since SQL Server 2017, Microsoft no longer releases service packs, and all fixes are delivered through Cumulative Updates. Alongside them, Microsoft publishes GDR updates that contain only security fixes. The difference between the two paths has a direct impact on your update strategy:

• The GDR branch includes only security and critical fixes. It keeps changes to a minimum, but you don’t receive fixes for non-security bugs such as data corruption or incorrect results.
• The CU branch includes all fixes, security fixes among them. Security updates are also released as a separate package for this branch.

Microsoft states that CUs are certified to the same level as service packs and recommends installing them proactively as they become available. For most production environments, our recommendation is likewise to stay on the CU branch and apply updates on a regular schedule.

Planning Updates Safely

Updating is the way out of a risky build, but the update itself is a change that needs to be managed carefully. On production systems, the process we follow consists of these steps:

• Allow a short observation period. Rather than moving a newly released CU straight into production, it’s common and sensible practice to wait a few weeks in case Microsoft adds to the known issues list or re-releases the package. This period should be shortened when a critical security vulnerability is involved.
• Apply it to a test environment first. Test the update under a workload similar to production, and check critical reports, jobs and application workflows.
• Confirm backups and consistency. Before updating, make sure that a valid full backup exists and that a recent DBCC CHECKDB completed without errors.
• Proceed node by node in high-availability environments. In Always On availability groups and failover clusters, update the secondary nodes first, then fail over and update the former primary. Our guide to patching Always On environments covers this in more detail.
• Verify the result. Check the build number again, review the error log and confirm that Agent jobs run as expected. In rare cases a database upgrade script can fail after a CU; the emergency tools for that situation are covered in our trace flags guide.
• Prepare a rollback plan. CUs can be uninstalled through “Programs and Features” in Windows. The rollback steps, and how long they will take, should be established before the update begins.

If You Can’t Update Right Away

Maintenance windows, application vendor approval or change management processes sometimes make an immediate update impossible. In that case, the following measures can reduce the risk in the meantime:

• Apply the workaround documented in the relevant Microsoft KB article, for example running index maintenance jobs with MAXDOP = 1 for the online index rebuild bug, or enabling the documented trace flag for the CU4 incorrect results issue.
• For security vulnerabilities, restrict the server’s network exposure and review privileged accounts. Our SQL Server security article provides guidance on this.
• On builds with a known corruption risk, run DBCC CHECKDB more frequently and keep backup retention long enough to reach a clean backup taken before any corruption could have occurred.
• Schedule the update for the next maintenance window and record the date in your change log, so that temporary workarounds don’t quietly become permanent.