SQL Server Check

xp_cmdshell enabled

This is one of many SQL Server checks performed by our free sp_Check tools.

Learn More About Our sp_check Tools

Checks Performed

What’s the issue?

xp_cmdshell is an extended stored procedure in SQL Server that executes a command string as an operating system shell command and returns the output as rows of text. It runs the command under the context of the SQL Server service account by default, or under a proxy account if one has been configured. The feature is disabled by default starting with SQL Server 2005 and is controlled by the xp_cmdshell server configuration option.

This finding identifies instances where xp_cmdshell is enabled. The setting is sometimes turned on intentionally to support administrative scripts, scheduled jobs that need to interact with the file system, or vendor applications that depend on shell access, and other times it is enabled by an administrator who simply wanted to run a single command and never disabled it afterward.

Why is this a problem?

xp_cmdshell is widely discussed as a security concern, but the actual risk picture is more nuanced than the configuration setting alone suggests. By default, only members of the sysadmin fixed server role can execute xp_cmdshell, and members of sysadmin already have the ability to enable or disable the feature at will using sp_configure. This means that for an attacker who has already obtained sysadmin level access, the on or off state of xp_cmdshell is essentially a formality, since they can flip the setting and run commands at any time.

For this reason, the more important security control is who has membership in the sysadmin role (and the equivalent CONTROL SERVER permission and securityadmin role), not whether xp_cmdshell is currently enabled. An instance with xp_cmdshell disabled but with excessive sysadmin membership is no more secure against a compromised privileged account than an instance with the feature enabled, since the elevated account can change the setting in seconds.

That said, xp_cmdshell does increase risk in specific scenarios that warrant attention. When the xp_cmdshell proxy account is configured, non sysadmin users can be granted execute permission on xp_cmdshell and run commands under the proxy account context. This delegated access path is sometimes used to allow application accounts or scheduled jobs to run shell commands, and the proxy account’s permissions on the host become a critical security boundary. A poorly scoped proxy account, or one with excessive permissions, can become a privilege escalation path that does not require sysadmin to exploit.

Enabling xp_cmdshell also expands the impact of certain attack patterns, including SQL injection. An injection vulnerability in an application connecting with a privileged account becomes significantly more dangerous when xp_cmdshell is available, since the attacker can move from data exfiltration to operating system command execution in a single step. Disabling xp_cmdshell does not prevent the injection vulnerability itself, but it does limit the immediate options available to the attacker if they reach the database.

What should you do about this?

Determine whether xp_cmdshell is actually being used on the instance. Review SQL Server Agent jobs, stored procedures, and application code for references to xp_cmdshell, and capture any that depend on the feature being enabled. Confirm with application and operations owners whether each use case is still required.

If xp_cmdshell is not in active use, disable it with EXEC sp_configure ‘xp_cmdshell’, 0; RECONFIGURE;. The change takes effect immediately and prevents the feature from being executed until it is explicitly re enabled. 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 xp_cmdshell. Most administrative tasks that historically used xp_cmdshell can now be accomplished through PowerShell jobs in SQL Server Agent, CmdExec or PowerShell job step types, SSIS packages, or Azure Automation and similar external orchestrators. Migrating to these alternatives reduces dependency on xp_cmdshell and produces cleaner audit trails for the operations being performed.

Read more…

The Real Danger Regarding the xp_cmdshell Setting – SQL Server Consulting – Straight Path Solutions (straightpathsql.com) xp_cmdshell (server configuration option) – SQL Server | Microsoft Learn

Type

Instance Settings

Importance

Medium

sp_Checks