SQL Server Privilege Escalation via DatabaseManager-role: Newly discovered Attack Paths Explained

First of all: full credit to Emad Al-Mousa for identifying and publishing two privilege escalation paths.

His findings show how members of the ##MS_DatabaseManager## server-role in SQL Server can escalate to sysadmin by chaining existing functionality in unexpected ways.

He has published his findings responsibly after more than 8 months’ notice to MSRC: Microsoft SQL Server Privilege Elevation Through ##MS_DatabaseManager## Role [CVE-2025-24999]

Elevation attack details

The first elevation attack abused the sp_syspolicy_purge_history-stored procedure and was fixed recently (Security update for SQL Server 2022 CU23+GDR and Security update for SQL Server 2025 CU2+GDR).

Emad then identified a second method that allows escalation to sysadmin via a different path:

Simplified flow:

At a high level, the attack paths rely on:

• Database lifecycle operations (create / drop / modify)
• Indirect execution through system components
• Execution paths that eventually run under elevated privileges

This is a perfect example of how legitimate capabilities can be chained into a privilege escalation path.

It also highlights recurring risk areas:

• Indirect execution paths
• Overly broad permissions
• Assumptions about “safe” capabilities

Key insight

Emad also points out an important observation:

“You don’t necessarily need the server-level role ##MS_DatabaseManager## – ALTER ANY DATABASE is sufficient.”

I will come back to this in a follow-up article.

Current state

Microsoft decided not to fix the second path and instead updated the documentation (July 2025, after MSRC notification).

(Fixed server-level roles introduced in SQL Server 2022 )

Given the relatively silent nature of that change, when I mentioned this recently on LinkedIn, I received comments and private messages, telling the same story:

no one was aware of this (including myself until recently).

Also notable:

No common baseline I am aware of flags this

• DISA STIG
• CIS Benchmarks
• Microsoft Defender for SQL (VA)

Practical implications and my recommendations

If this is not going to be addressed in the product, it needs to be considered part of the threat model.

2) Review permissions

Identify accounts with:

• ALTER ANY DATABASE
• Membership in ##MS_DatabaseManager##

2) Ensure Server Auditing
If you are following solid auditing practices, you should already have visibility here.

If not, this is the time to implement it

(see: Recommendation for Security Auditing for databases – with example for Microsoft SQL Server )

Focus on:

• Changes to role membership
• Attempts to alter login privileges (takeover scenarios)

Also described in detail here by Emad: https://databasesecurityninja.wordpress.com/2025/12/24/sql-server-2025-privilege-elevation-from-alter-any-login-permission-to-sysadmin-role-vulnerability/ )

3) Add Database Auditing on system Databases

• Monitor Changes to system objects in msdb and master.

These are key points in the demonstrated attack paths.
(More on that in a follow-up article.)

A note on assessments

Does this get detected in real-world security assessments?

Yes – in our case, this is covered in the Sarpedon Quality Lab Security Assessment (Standard and Premium tiers), even though this exact escalation path was not explicitly modeled yet.

Going deeper

If you’re interested in how these kinds of privilege escalation paths emerge in real-world environments – and how to systematically detect and prevent them – I’ll be covering SQL Server Security in depth in my full-day pre-conference session: “SQL Server Security vs. Security Theater: Build a Defensible Data Estate” PASS Data Community Summit (Chicago), May 7

Closing

Again, full credit to Emad for surfacing these paths.

This is a good reminder that security issues are often not about missing features

but about how existing features interact.

Andreas