Critical SQL Server Security Updates: What DBAs Need to Know Right Now

Microsoft has released General Distribution Release (GDR) updates addressing multiple security vulnerabilities in SQL Server itself, including SQL injection flaws in system stored procedures. These are not application-level bugs you can fix with better coding practices. The vulnerabilities exist in Microsoft's own shipped code, and patching is the only remediation.

That distinction matters. Most SQL injection guidance targets developers and focuses on parameterised queries, input validation, and ORM hygiene. This situation is different. Your code could be perfectly written and your environment could still be exposed. When the vulnerability lives inside SQL Server's own system procedures, the fix has to come from Microsoft, and it has.

What Vulnerabilities Were Fixed in These Updates?

Microsoft patched four distinct security issues in this GDR release. Each one is serious in its own right. Together, they represent a meaningful attack surface that warrants immediate attention.

SQL Injection in System Stored Procedures

A SQL injection vulnerability was discovered inside a system stored procedure that ships with SQL Server. This is uncommon. Microsoft's internal code goes through security review processes, which is why flaws at this level tend to be treated with more urgency than typical application vulnerabilities. The practical risk is that an attacker with the ability to execute that procedure could potentially manipulate its behaviour in ways that were never intended.

Excessive Privilege Through ALTER ANY LOGIN

Users holding the ALTER ANY LOGIN permission were able to reset passwords for high-privilege logins, including those with elevated server-level access. In a well-managed environment, ALTER ANY LOGIN is already a tightly controlled permission. But in organisations where permission creep has occurred over years of growth, this vulnerability could be exploited by a malicious insider or a compromised account to escalate privileges without triggering obvious alerts. This fix closes that path.

SQL Agent Job Step Permission Abuse

Built-in SQL Agent jobs could be manipulated to execute job steps with more permissions than the job was designed to use. SQL Agent is a common attack vector that gets less scrutiny than it deserves. Jobs run on schedules, often under service accounts with broad permissions, and they're not always reviewed during security audits. This fix tightens the permission boundary so that job steps cannot run with elevated access they were never supposed to have.

Stored Procedure Exploitation Leading to Arbitrary Code Execution

Certain stored procedures could be abused by users who had legitimate access to them, enabling SQL injection and, in some cases, arbitrary code execution with elevated privileges. This is the most severe category in the list. Arbitrary code execution with elevated privileges is a worst-case scenario in any environment. The attack path here does not require the attacker to have admin rights. It requires only that they have access to a vulnerable procedure.

Why Are Vulnerabilities in SQL Server's Own Code So Significant?

Most security guidance assumes the database engine itself is trustworthy and that the risk comes from how it is used. That assumption holds the vast majority of the time. SQL Server is a mature, heavily scrutinised product with a strong security track record.

But when a vulnerability exists in the engine's own code, the usual mitigations do not apply. You cannot fix a flaw in a system stored procedure by rewriting your application. You cannot parameterise your way out of a vulnerability in Microsoft's shipped code. The only fix is the patch.

This also matters for compliance and audit purposes. Organisations operating under frameworks like ISO 27001, the Australian Government's Essential Eight, or industry-specific requirements such as PCI DSS have obligations around timely patching of known vulnerabilities. A GDR release from Microsoft addressing SQL injection and privilege escalation is exactly the kind of update those frameworks expect you to apply promptly.

Why Hasn't Microsoft Published Full Technical Details?

Microsoft has deliberately limited the technical detail published about these vulnerabilities, and that is the right call. Publishing a detailed breakdown of how to exploit a flaw in a system stored procedure before the majority of the installed base has patched would hand attackers a ready-made guide.

This approach is consistent with responsible disclosure practice. The CVE identifiers and high-level descriptions give defenders enough information to understand the risk and prioritise patching. The specifics of exploitation mechanics are withheld until the window for opportunistic attacks narrows.

The absence of technical detail should not be read as an indication that the risk is low. It is standard practice, and it should not slow down your patching timeline.

What SQL Server Versions Are Affected?

Microsoft released GDR updates covering multiple supported versions of SQL Server. If you are running any of the following, you should be checking whether you have applied the relevant update:

  • SQL Server 2019
  • SQL Server 2022
  • SQL Server 2017
  • SQL Server 2016

Older versions that have reached end of extended support do not receive GDR updates. If you are running SQL Server 2014 or earlier in production, these fixes will not be available to you, and the underlying vulnerabilities may still be present. That is a separate conversation worth having with your team.

For Azure SQL Database and SQL Managed Instance, Microsoft handles patching at the platform level. If you are running fully managed Azure SQL services, you do not need to take action for these specific vulnerabilities.

How Do You Apply These Updates?

The process for applying a GDR update is straightforward, but it requires planning in a production environment. Here is the standard approach:

  1. Identify the current build number of each SQL Server instance. Run the following query to confirm your version:
SELECT @@VERSION;

  1. Compare your current build against the patched build numbers published in Microsoft's support documentation for each CVE. The SQL Server Builds reference maintained by the community is a useful cross-reference for tracking build numbers across versions.

  2. Download the appropriate GDR installer from the Microsoft Update Catalog or via Windows Update, depending on your patching infrastructure.

  3. Test the update in a non-production environment first. GDR updates are generally low-risk, but any change to a production database server warrants validation.

  4. Schedule a maintenance window. SQL Server service restarts are required to complete the installation.

  5. Apply the update, confirm the new build number with SELECT @@VERSION, and verify that critical services are operating normally after the restart.

  6. Document the change in your change management system and update your asset register with the new build number.

For environments with multiple SQL Server instances, consider whether your patching tooling (WSUS, SCCM, or a third-party patch management platform) can deploy the update at scale rather than patching each instance manually.

Should You Wait for the Next Patch Tuesday?

No. GDR updates are released out-of-band specifically because the vulnerabilities they address are serious enough to warrant immediate action. Waiting for the next scheduled Patch Tuesday cycle is not appropriate when the update addresses SQL injection and privilege escalation in the database engine itself.

In practice, "patch immediately" needs to be balanced against the operational realities of your environment. A maintenance window, change approval, and a brief test cycle are reasonable. Waiting weeks because patching is inconvenient is not.

If your change management process makes it genuinely difficult to apply a critical security update within a few days, that is worth raising as a process risk, not just a technical one.

Key Takeaways

  • Microsoft has patched SQL injection vulnerabilities in SQL Server's own system stored procedures. These cannot be mitigated at the application level. Patching is the only fix.
  • Four distinct vulnerabilities were addressed, covering SQL injection, privilege escalation via ALTER ANY LOGIN, SQL Agent job step abuse, and arbitrary code execution through stored procedure exploitation.
  • Affected versions include SQL Server 2016, 2017, 2019, and 2022. Azure SQL Database and SQL Managed Instance are patched automatically by Microsoft.
  • Apply the update in a test environment first, then schedule a production maintenance window. Do not wait for the next Patch Tuesday cycle.
  • Organisations with compliance obligations under frameworks like the Essential Eight or PCI DSS should treat this as a priority patching event and document accordingly.

Keeping SQL Server environments patched, secure, and compliant is exactly what DBA Services does for organisations across Australia. If you need help assessing your current patch levels, managing a complex patching rollout across multiple instances, or reviewing your SQL Server security posture more broadly, get in touch with the team.