No it's not. Poor ol' xp_CmdShell gets blamed for other very poor security practices a lot. It's not actually a security risk. Bad security is a security risk.

Stop and think about it. Who can use xp_CmdShell? If you've done it right, only people who have "SA" privs can use it. Who can turn it on or off? Right again... only those folks that have "SA" or "Control Server" privs.

If an attacker breaks in as a non-SA prived user, can he use xp_CmdShell if even if it's enabled? No. If an attacker breaks in as an SA prived user, can he use xp_CmdShell even if it's disabled? Since he also has the privs to enable it, the answer is "Yes". Even if xp_CmdShell could be permanently disabled, an unauthorized person getting into your system can still get to other systems using the command block of a job, PowerShell, and SQLCmd. The REAL security risk isn't having xp_CmdShell enabled... the real security risk is allowing unauthorized people in as "SA".

What about DBAs using it to elevate their privs as you have just done? It's not the usage of xp_CmdShell that caused that risk. It's the fact that you think DBAs have to have "SA" privs to do their job. 😉

"DBA" is an abbreviation for "Database Administrator"... not "System Administrator". If your DBAs have SA privs and you don't actually want them to be a "security risk", then give them the correct privs for the job instead of blaming xp_CmdShell.

Stop blaming xp_CmdShell for otherwise poor security. Instead, fix the security holes that allow for its misuse.