SQL Server Guidance to protect against speculative execution side-channel vulnerabilities


Microsoft is aware of a new publicly disclosed class of vulnerabilities referred to as “speculative execution side-channel attacks” that affect many modern processors and operating systems including Intel, AMD, and ARM. Note: this issue will affect other systems such as Android, Chrome, iOS, MacOS, so we advise customers to seek out guidance from those vendors.

Microsoft has released several updates to help mitigate these vulnerabilities. We have also taken action to secure our cloud services. See the following sections for more details.

Microsoft has not received any information to indicate that these vulnerabilities have been used to attack customers at this time. Microsoft continues working closely with industry partners including chip makers, hardware OEMs, and app vendors to protect customers. To get all available protections, hardware/firmware and software updates are required. This includes microcode from device OEMs and in some cases updates to AV software as well.

More information about the vulnerabilities can be found here: Microsoft Security Advisory ADV180002.

Supported SQL Server versions impacted

The following versions are impacted when running on x86 and x64 processor systems: SQL Server 2008, SQL Server 2008R2, SQL Server 2012, SQL Server 2014, SQL Server 2016, SQL Server 2017. IA64 (SQL Server 2008) is not believed to be impacted.


The following table outlines what customers should do, depending on the environment SQL Server is running in and what functionality is being used. Microsoft recommends customers deploy fixes using normal procedures to validate new binaries before deploying to production environments.

Scenario Number Scenario Description Priority Recommendation(s)
1 SQL Server is run on bare metal (no virtual machines)
AND no other untrusted application logic (application tier) is run on the same machine
AND no untrusted SQL Server extensibility interfaces are being used (see below for list)
No immediate need to patch. Please deploy updated OS and SQL patches after normal pre-production validation testing. Do not enable the registry settings in Windows to enable the microcode changes.
2 SQL Server is run in a virtual machine in a public hosting environment For Azure: No VM image update necessary (see KB 4073235 for details). For other public hosts: refer to their guidance.
3 SQL Server is run in a virtual machine in a private hosting environment Apply patch to Host OS or isolate SQL Server on dedicated physical hardware. Please refer to Windows OS guidance on whether microcode changes should be enabled.
4 SQL Server is run in a physical or virtual machine and is not isolated from other application logic running on the same machine or is using extensibility interfaces in SQL Server with untrusted code
  1. Apply OS patches as described in Scenario 3
  2. Apply SQL Server patches, when available
  3. If running with untrusted code on the same machine, please enable the microcode changes as described in the Windows OS guidance.


  1. Restrict use of extensibility interfaces to block untrusted code from executing on the machine (see below)
5 Customers running SQL Server 2017 on Linux OSes (independent of whether extensibility interfaces are being used)
  1. Apply Linux OS patches
  2. Apply Linux SQL Server patches
  3. Consult with your Linux OS vendor about whether and how to enable the firmware changes

Performance Advisory:

Microsoft continues to do performance evaluation on the patched binaries. However, at the time of publication, Microsoft has not yet validated SQL Server performance with all microcode patches, nor has it validated performance in all Linux environments. Customers are advised to evaluate the performance of their specific application when applying patches. Please validate the performance impact of enabling microcode changes before deploying into a production environment. Microsoft will update this section with more information when it is available.

Available Builds:

At the time of publication, the following patched SQL Server builds are available for download:
Servicing Release

This document will be updated when additional patched builds are available.

For Windows OS Builds, please refer to the following guidance for the latest on available Windows builds:

Windows Guidance for Consumers

For Linux builds, please contact the Linux vendor to find the latest patched builds for your specific Linux distribution.

Untrusted SQL Server extensibility mechanisms

  • SQL CLR assemblies
  • R and Python packages running through the external scripts mechanism or run from the standalone R/Machine Learning studio on the same physical machine as SQL Server
  • SQL Agent extensibility points running on the same physical machine as SQL Server (ActiveX scripts)
  • Non-Microsoft OLE DB providers used in Linked Servers
  • Non-Microsoft Extended Stored Procedures

Mitigations to take if using untrusted code in SQL Server:

Scenario/Use Case Mitigations/Suggested Steps
Running SQL Server with CLR enabled (sp_configure ‘clr enabled’, 1)
  1. If possible, disable CLR if it is not needed in your application to reduce the risk of any untrusted code being loaded into SQL Server
  2. (SQL Server 2017+) If CLR is still needed in your application, enable only specific assemblies to be loaded using the “CLR Strict Security” feature (https://docs.microsoft.com/en-us/sql...trict-security) using sys.sp_add_trusted_assembly (https://docs.microsoft.com/en-us/sql...y-transact-sql)
  3. Consider whether CLR code can be migrated to T-SQL equivalent code
  4. Review security permissions to lock down scenarios where CLR-based operations can be used. Limit CREATE ASSEMBLY, EXTERNAL ACCESS ASSEMBLY, and UNSAFE ASSEMBLY permission to the minimum set of users/code paths to disallow loading new assemblies in an existing, deployed application
Running R/Python external scripts from within SQL Server (sp_configure 'external scripts enabled', 1)
  1. If possible, disable the external scripts capability if not needed in your application to reduce attack surface area.
  2. (SQL Server 2017+) If possible, migrate external scripts doing scoring to use the native scoring feature instead (https://docs.microsoft.com/en-us/sql...native-scoring)
  3. Review security permissions to lock down scenarios where external scripts can be used. Limit EXECUTE ANY EXTERNAL SCRIPT permission to the minimum set of users/code paths to disallow arbitrary scripts from being executed
Using Linked Servers (sp_addlinkedserver)
  1. Please review installed OLEDB providers and consider removing any untrusted OLEDB providers from the machine. (Please make sure that you do not remove OLEDB providers if they are used outside of SQL Server on the machine). An example on how to enumerate existing OLEDB providers is here: https://msdn.microsoft.com/en-us/lib...numerator.aspx
  2. Please review and remove any unneeded linked servers from SQL Server (sp_dropserver) to reduce the possibility of any untrusted code being executed within the sqlservr.exe process
  3. Review security permissions to lock down ALTER ANY LINKED SERVER permission to the minimum number of users.
  4. Review Linked Server Login/Credential mappings (sp_addlinkedsvrlogin/sp_droplinkedsvrlogin) to limit who can execute operations over linked servers to the minimum set of users/scenarios.
Using Extended Stored Procedures (sp_addextendedproc) As Extended Stored Procedures are deprecated, please remove all uses of these and do not use them in production systems.

Source: https://support.microsoft.com/en-us/...for-sql-server