What’s the issue?
OLE Automation Procedures are a set of system stored procedures that allow T-SQL code to instantiate and interact with OLE Automation objects. These procedures provide a way for SQL Server to call out to COM objects on the host operating system, manipulate them, and use their methods and properties from within database code.The functionality is controlled by the Ole Automation Procedures server configuration option, which is disabled by default. When enabled, any login with permission to execute the OLE Automation procedures (typically members of the sysadmin role by default) can use them.
This finding identifies instances where OLE Automation Procedures are currently enabled.
Why is this a problem?
OLE Automation Procedures expand the attack surface of SQL Server beyond traditional T-SQL operations, allowing managed code paths to interact with operating system COM objects. The objects accessible through this mechanism can perform a wide range of activities including file system operations, network calls, registry manipulation, and execution of external commands, all running under the SQL Server service account context.The feature is a known SQL injection amplifier in the same way that xp_cmdshell and Ad Hoc Distributed Queries are. An injection vulnerability in an application connecting with sufficient privileges becomes significantly more dangerous when OLE Automation Procedures are enabled, since the attacker gains a path to interact with operating system functionality through COM objects rather than only through database operations.
Modern alternatives exist for nearly every legitimate use case that historically required OLE Automation Procedures. PowerShell job steps in SQL Server Agent, SSIS packages, CLR integration with strict security, and external orchestration tools all provide better, more auditable, and more maintainable approaches to interacting with operating system functionality. The presence of OLE Automation Procedures in an environment usually indicates older code patterns that could be modernized.
The condition often persists because OLE Automation Procedures were enabled years ago for a specific use case, and the original requirement may have been retired or replaced without anyone disabling the feature. Forgotten enablement leaves the attack surface available with no offsetting benefit.
What should you do about this?
Determine whether the feature is actually being used by reviewing application code, stored procedures, scheduled jobs, and ETL processes for references to sp_OACreate and the related OLE Automation procedures. Capture any uses found and identify whether they are still required.If the feature is not in active use, disable it with EXEC sp_configure ‘Ole Automation Procedures’, 0; RECONFIGURE;. The change takes effect immediately and prevents future use of the procedures. Add a check for the setting to your standard health check process so any future enablement is detected and reviewed.
For each remaining use case, evaluate whether the requirement can be met without OLE Automation Procedures. Most operations that historically used these procedures can now be accomplished more cleanly through PowerShell job steps in SQL Server Agent, SSIS packages, external orchestration tools, or properly signed CLR assemblies under strict security. Migrating to these alternatives reduces dependency on a deprecated pattern and produces better audit trails.
If the feature must remain enabled, the most important security work is on the principals who can use it. Review the membership of sysadmin and other roles that grant permission to execute the OLE Automation procedures, since these are the accounts that can use the feature regardless of the configuration setting. Remove unnecessary privileged access.