What’s the issue?
The clr enabled server configuration option controls whether SQL Server allows the execution of managed code through the Common Language Runtime (CLR) integration feature. When enabled, developers can create stored procedures, triggers, user defined functions, and aggregates written in .NET languages such as C# and have them execute inside the SQL Server process.
This finding identifies instances where clr enabled is set to 1. The setting is off by default and is enabled either explicitly to support CLR based code or as a side effect of installing certain features and vendor applications that depend on CLR functionality.
Why is this a problem?
CLR integration extends the attack surface of SQL Server beyond traditional T-SQL, allowing managed code to perform operations that T-SQL alone cannot, including file system access, network calls, and direct interaction with operating system resources. While CLR assemblies are sandboxed by default, the protections depend on how the assembly is registered and on the overall security model of the instance.
Historically, CLR assemblies could be registered with one of three permission sets: SAFE, EXTERNAL_ACCESS, or UNSAFE. SAFE was the default and provided the strongest containment, while EXTERNAL_ACCESS and UNSAFE allowed progressively broader access to system resources.
Microsoft introduced a security advisory and a new configuration option, clr strict security, in SQL Server 2017 and later. With strict security enabled (which is the default in SQL Server 2017 and later), all assemblies are treated as UNSAFE regardless of their declared permission set, and the engine requires either that the assembly be signed with a certificate or asymmetric key that has been granted UNSAFE ASSEMBLY permission, or that it be added to the trusted assemblies list using sp_add_trusted_assembly. This change closes the older privilege escalation paths but requires that assemblies be properly signed or trusted, which not all environments have done.
When clr enabled is on without clr strict security enforced, or when assemblies are run as UNSAFE without proper signing, the instance is exposed to risks including code that can read or modify files on the SQL Server host, make outbound network connections to exfiltrate data, execute arbitrary operating system commands under the SQL Server service account context, and bypass SQL Server permission checks through the elevated execution context.
What should you do about this?
First, determine whether CLR integration is actually being used on the instance. Query sys.assemblies in each user database to see if any user assemblies have been registered. If no user assemblies exist, the feature can almost certainly be disabled.
If CLR integration is not in use, disable it with EXEC sp_configure ‘clr enabled’, 0; RECONFIGURE;. The change takes effect immediately and prevents any future attempt to load or execute managed code in the engine.
If CLR integration is in use, on SQL Server 2017 and later confirm that clr strict security is enabled (which is the default) by checking sys.configurations for the clr strict security option. Leave this setting enabled, as Microsoft strongly recommends against disabling it.