Microsoft Releases Critical GDR Updates for SQL Server 2022, 2019, and 2017

Microsoft has issued emergency GDR (General Distribution Release) security updates for SQL Server 2022, 2019, and 2017 to address a remote code execution vulnerability in the SQL Server connection driver. If you're running any of these versions without the latest GDR applied, your environment is exposed. This isn't a routine patch cycle update - this is a targeted fix for a specific, exploitable security flaw that warrants immediate attention.

Remote code execution vulnerabilities sit at the top of the severity scale for good reason. An attacker who successfully exploits one doesn't just read your data - they can execute arbitrary code on affected systems. That changes the risk profile entirely.

What Is the Vulnerability?

The flaw exists in the SQL Server connection driver. A threat actor can manipulate a compromised driver, and when that driver establishes a connection to SQL Server, it can trigger arbitrary code execution on the client side. The client machine runs code it never asked to run, code it has no visibility over, and code that could do anything from exfiltrating credentials to deploying ransomware.

This is classified as a remote code execution (RCE) vulnerability, which Microsoft rates as Critical. Under Microsoft's Security Response Centre severity guidelines, Critical is the highest classification, reserved for vulnerabilities that can be exploited remotely without user interaction or with minimal interaction.

The attack vector here targets the connection layer, which means it sits between your applications and your SQL Server instances. Any system using an affected driver to connect to SQL Server is potentially in scope - not just the SQL Server host itself.

Which SQL Server Versions Are Affected?

The GDR updates cover three actively supported SQL Server versions:

  • SQL Server 2022 - GDR update available
  • SQL Server 2019 - GDR update available
  • SQL Server 2017 - GDR update available

If you're running SQL Server 2016 or earlier, check Microsoft's Security Update Guide directly. Older versions that have passed end of support may not receive patches, which is a separate risk conversation worth having if you're still on those builds.

What Is a GDR Update?

For those less familiar with SQL Server's patching model, Microsoft releases updates through two distinct tracks:

GDR (General Distribution Release) updates contain only security fixes and critical reliability patches. They're narrow in scope and designed to be applied quickly with minimal risk of introducing regressions.

CU (Cumulative Update) releases bundle all GDR fixes plus a larger set of bug fixes and non-security improvements. CUs are more comprehensive but carry a slightly higher change surface.

When Microsoft releases a standalone GDR outside of the normal CU cycle, it signals urgency. They're not waiting for the next scheduled CU - they're pushing a fix now because the vulnerability is serious enough to warrant it.

In practice, if you're already on a recent CU for your version, the GDR fix may already be incorporated. Check your current build number against the Microsoft SQL Server builds list to confirm whether you're protected.

How Do You Check Your Current SQL Server Build?

Run this query against any SQL Server instance to confirm the current version and build:

SELECT
    @@SERVERNAME AS ServerName,
    @@VERSION AS FullVersion,
    SERVERPROPERTY('ProductVersion') AS ProductVersion,
    SERVERPROPERTY('ProductLevel') AS ProductLevel,
    SERVERPROPERTY('ProductUpdateLevel') AS UpdateLevel;

Compare the ProductVersion output against the official Microsoft documentation for SQL Server builds. If your build number is lower than the GDR release for your version, you need to patch.

For environments with multiple instances, run this across all instances. It's a common gap - DBAs patch the primary instance and miss a secondary, a reporting instance, or a developer environment sitting on the same network.

How to Apply the GDR Updates

The process is straightforward, but it does require a service restart, so plan accordingly:

  1. Identify all affected instances - Audit every SQL Server instance in your environment and record the current build number.
  2. Download the correct GDR - Go to the Microsoft Update Catalogue or the official SQL Server update pages. Confirm you're downloading the GDR that matches your version (2022, 2019, or 2017) and edition.
  3. Test in a non-production environment first - Even GDR updates should be validated before hitting production. Run your standard post-patch smoke tests.
  4. Schedule a maintenance window - SQL Server services must restart to complete the patch. For high-availability environments using Always On Availability Groups, patch secondary replicas first, fail over, then patch the remaining nodes.
  5. Apply and verify - After patching, re-run the version query above to confirm the build number has incremented to the expected GDR level.
  6. Document the change - Update your configuration management records. Knowing exactly when and what was patched matters for compliance and future troubleshooting.

For Always On environments, the rolling upgrade approach keeps downtime to a minimum. Patch one secondary at a time, validate it comes back online cleanly, then proceed. Don't patch all nodes simultaneously.

Why Prompt Patching Matters More Than Ever

The window between a vulnerability disclosure and active exploitation in the wild has shortened dramatically over the past few years. Security researchers and threat actors both monitor Microsoft's patch releases closely. Once a CVE is published, reverse engineering the patch to understand the underlying flaw is a well-established technique. Environments that remain unpatched for weeks after a Critical RCE disclosure are genuinely at elevated risk.

SQL Server instances are high-value targets. They hold financial records, customer data, operational systems, and often credentials that can be leveraged for lateral movement. A remote code execution vulnerability in the connection layer is exactly the kind of entry point a ransomware operator looks for.

This isn't about being alarmist. It's about understanding that patching SQL Server promptly is one of the highest-return security activities your team can perform. The effort is low. The risk reduction is significant.

What If You Can't Patch Immediately?

In some environments, patching requires change advisory board approval, extended testing cycles, or coordination across multiple teams. If you genuinely cannot apply the GDR within 48 to 72 hours of disclosure, consider these interim measures:

  • Review network access controls - Restrict which systems can establish connections to your SQL Server instances. Limit exposure to known application servers and management hosts.
  • Audit connection drivers - Identify which versions of ODBC, OLE DB, and other connection drivers are deployed across your application estate.
  • Increase monitoring - Enable SQL Server Audit or review existing audit logs for anomalous connection attempts or unexpected client behaviour.
  • Communicate the risk - Make sure your security team and management are aware of the exposure and the timeline for remediation.

These are mitigations, not solutions. The fix is the patch.

Key Takeaways

  • Microsoft has released Critical-rated GDR security updates for SQL Server 2022, 2019, and 2017 to address a remote code execution vulnerability in the connection driver.
  • The vulnerability allows arbitrary code execution on the client side when a compromised driver connects to SQL Server - a Critical-severity risk under Microsoft's own classification.
  • GDR updates are narrow, security-focused patches. Applying them quickly with a planned maintenance window is the correct response.
  • Check your current build number using SERVERPROPERTY('ProductVersion') and compare against Microsoft's published GDR build levels to confirm whether you're protected.
  • For Always On environments, use the rolling upgrade approach to minimise downtime while patching all nodes.

Keeping SQL Server environments patched and secure is a core part of what DBA Services does for organisations across Australia. If you don't have a consistent patching process in place, or if you're unsure whether your instances are up to date, a SQL Server health check is a practical starting point. Our team can audit your current build levels, identify security exposure, and help you establish a patching cadence that fits your change management process. Get in touch to find out more.