TL;DR: I found two privilege escalation vulnerabilities, one in MSSQL (CVE-2025-49758) and one in Microsoft Configuration Manager (CVE-2025-47179), while mapping their permission models for inclusion in BloodHound, an open-source tool with Maps-style navigation and an interactive graph that helps users visualize and remediate attack paths. I learned a few things about submitting a good bug report to Microsoft along the way.

The initial reason I wrote MSSQLHound was to create the foundational nodes and edges needed to depict SCCM hierarchy TAKEOVER-1 using a BloodHound OpenGraph collector for SCCM that I recently released called ConfigManBearPig (yes, I’m super cereal).

While researching the MSSQL and SCCM permission models to build these tools, I found permissions that allowed elevation of privileges to the MSSQL sysadmin server role and the SCCM Full Administrator security role. These roles have the highest privileges in their respective technologies. 

I also found it interesting that, after modeling the permissions for MSSQL in OpenGraph, I found the issue in BloodHound!

The MSSQL flaw was present since SQL Server 2005 and patches were applied to all supported versions, while the SCCM issue was present in versions 2403 (April 2024) through 2503 (April 2025).

I want to share these because they weren’t particularly difficult to find or abuse, and to encourage other researchers out there to keep looking at widely-used, ancient technologies like MSSQL and SCCM. They may seem like they must have already been exhaustively picked over by other security researchers, but there are still systemic issues lurking and worth searching for.

I also want to share my experiences reporting issues to Microsoft Security Response Center (MSRC) in case it helps improve your coordinated disclosure success rate.

Disclosure Process

In the past, I’ve reported several vulnerabilities in SCCM that MSRC rejected, including authentication coercion via automatic client push installation and an issue in Intune that Microsoft silently patched without a CVE, and have left the experience disappointed. This time, I had a positive experience during the disclosure process with Microsoft and learned some things I think are worth noting. They boil down to:

• Set a desired public disclosure date (and venue, if releasing details at a conference)
• Use Microsoft’s documentation to prove that the issue is valid and requires a fix:
  • Documented intended functionality vs. observed functionality
  • Microsoft Security Servicing Criteria for Windows
  • Microsoft Vulnerability Severity Classification for Windows
• Include clear steps to reproduce

First, and probably the most obvious and talked about, is that setting a public disclosure timeline seems to be the best way to get a report reviewed in a timely fashion. Help MSRC prioritize the report by letting them know when you plan to talk about it.

I included a note that I intended to disclose these issues in the future and MSRC’s response time drastically reduced from 28 and 127 days for my two previously reported vulns (with no disclosure timelines) to 14 and 7 days. I also got responses from a human instead of automated, canned emails.

Microsoft ended up needing more time to roll out fixes, so we coordinated disclosure dates at a later time than in my initial report. Still, I believe the intent to disclose was what got their attention and you can always work with MSRC to change the disclosure timeline later.

Second, framing my report in the context of Microsoft’s documented vulnerability criteria helped a lot. Previously, I basically treated the vulnerability report like I would a pentest report for a client, describing the issue with as much technical accuracy and detail as possible. While including this detail is important so that MSRC can reproduce the issue, I was more successful when copying and pasting verbiage from the criteria into my report and justifying exactly why the reported vuln met those criteria.

Summary of Findings

CVE-2025-49758: MSSQL Server ALTER ANY LOGIN Permission Elevation of Privilege

Severity: Important

CVSS 3.1 Score: 8.8 (High)

Any principal granted the ALTER ANY LOGIN permission could change the password for a SQL login with the securityadmin role without knowing the current password, allowing them to grant themselves (or any other login) the sysadmin (or any other) role, effectively grant themselves all permissions in the MSSQL Server instance.

I came across this issue just by reading Microsoft’s documentation for the ALTER LOGIN command, which said:

If the login that is being changed is a member of the sysadmin fixed server role or a grantee of CONTROL SERVER permission, also requires CONTROL SERVER permission when making the following changes: Resetting the password without supplying the old password.

However, it didn’t mention that changing the password for a securityadmin member, who can add themselves to the sysadmin role, was prevented. I checked, and resetting a securityadmin’s password was allowed, bypassing the intended control.

It also didn’t mention that changing the password for a principal with the IMPERSONATE ANY LOGIN permission, who can impersonate a default member of sysadmin like the sa login, required the current password to be provided. Sure enough, resetting such a principal’s password was allowed, bypassing the intended control.

I’m not sure why Microsoft’s website says that the vulnerability is SQL injection in their executive summary. Definitely not a requirement to exploit this.

To remediate this issue, you can apply the listed updates to MSSQL Server for SQL Server versions 2016 and higher. Cloud versions of MSSQL in Azure were also patched.

At the time of this writing, Microsoft has not yet updated the documentation to reflect that sysadmin, securityadmin, or CONTROL SERVER is required to change the password for a login with the securityadmin role or IMPERSONATE ANY LOGIN permission after the patch, but I tested the patched version and it is no longer vulnerable.

MSSQLHound has also been updated so the MSSQL_ChangePassword edge is not drawn in the scenarios above if the server has been patched.

CVE-2025-47179: Configuration Manager Elevation of Privilege

Severity: Important

CVSS 3.1 Score: 6.7 (Medium)

I found this one just by browsing through the Permissions tab for each security role in the SCCM console and noticing that the new-ish CMPivot Administrator role, which only “Grants permissions to run CMPivot”, also had permissions to modify any user or security role.

This allowed any CMPivot Administrator member to grant themselves the Full Administrator role or add any permissions to an existing assigned role, allowing complete control of SCCM.

To remediate this issue, you can apply the listed upgrade rollup for Configuration Manager, then the excessive permissions are removed.

BloodHound Attack Path Analysis

To find the MSSQL issue in BloodHound, first run MSSQLHound, then query for principals that can change the password of SQL_LOGIN type principals that are either members of the securityadmin server role or have the IMPERSONATE ANY LOGIN permission:

MATCH p = ()-[:MSSQL_ChangePassword]->(target:MSSQL_Login)
WHERE target.type = 'SQL_LOGIN'
AND (
  'securityadmin' IN target.memberOfRoles
  OR 'IMPERSONATE ANY LOGIN' IN target.explicitPermissions
)
RETURN p

Next, execute the Cypher in the Composition field of the MSSQL_ChangePassword edges:

MATCH (source {objectid: 'ALTERANYLOGINTEST_LOGIN_HASALTERANYLOGIN@S-1-5-21-843997178-3776366836-1907643539-1108:1433'}), (server:MSSQL_Server {objectid: 'S-1-5-21-843997178-3776366836-1907643539-1108:1433'}), (login:MSSQL_Login {objectid: 'SECADMIN@S-1-5-21-843997178-3776366836-1907643539-1108:1433'}) 
MATCH p0 = (source)-[:MSSQL_ChangePassword]->(login) 
MATCH p1 = (server)-[:MSSQL_Contains]->(source) 
MATCH p2 = (server)-[:MSSQL_Contains]->(login) 
MATCH p3 = (source)-[:MSSQL_AlterAnyLogin]->(server) 
RETURN p0, p1, p2, p3

MATCH (source {objectid: 'ALTERANYLOGINTEST_LOGIN_HASALTERANYLOGIN@S-1-5-21-843997178-3776366836-1907643539-1108:1433'}), (server:MSSQL_Server {objectid: 'S-1-5-21-843997178-3776366836-1907643539-1108:1433'}), (login:MSSQL_Login {objectid: 'IMPERSONATOR@S-1-5-21-843997178-3776366836-1907643539-1108:1433'}) 
MATCH p0 = (source)-[:MSSQL_ChangePassword]->(login) 
MATCH p1 = (server)-[:MSSQL_Contains]->(source) 
MATCH p2 = (server)-[:MSSQL_Contains]->(login) 
MATCH p3 = (source)-[:MSSQL_AlterAnyLogin]->(server)
RETURN p0, p1, p2, p3

Issue Reports

Here is the full, unaltered text from each report to MSRC:

MSSQL Server ALTER ANY LOGIN Permission Elevation of Privilege

Summary

When mixed mode authentication is enabled on SQL Server 2005 or higher (tested on 2005 and 2022) and there is at least one SQL login assigned the fixed securityadmin server role, any login granted the ALTER ANY LOGIN permission can elevate privileges and gain complete control of the SQL Server instance, allowing execution of all available actions on the instance of SQL Server, including actions that allow execution of commands at the operating system level (e.g., xp_cmdshell).

As a result, any login granted ALTER ANY LOGIN may grant themselves (or any other login) the sysadmin (or any other) role, impersonate any existing login, or modify and assign user-defined security role permissions, effectively allowing them to bypass intended security boundaries and grant themselves all permissions in MSSQL.

According to the documentation for the ALTER LOGIN permission (https://learn.microsoft.com/en-us/sql/t-sql/statements/alter-login-transact-sql?view=sql-server-ver17#permissions), “If the login that is being changed is a member of the sysadmin fixed server role or a grantee of CONTROL SERVER permission, also requires CONTROL SERVER permission when making the following changes: Resetting the password without supplying the old password.”

However, the password can be reset for a member of the fixed securityadmin server role without supplying the old password and without the source login being a member of the sysadmin fixed server role or a grantee of CONTROL SERVER permission. The securityadmin role is highly privileged and should be treated in the same manner as the sysadmin role that has all permissions on SQL Server. This is the intent according the the documentation for the securityadmin role (https://learn.microsoft.com/en-us/sql/relational-databases/security/authentication-access/server-level-roles?view=sql-server-ver17), which states that “The ability to grant access to the Database Engine and to configure user permissions allows the security admin to assign most server permissions. The securityadmin role should be treated as equivalent to the sysadmin role.”

Servicing

If the login that is being changed is a member of the securityadmin fixed server role, require that the login attempting to reset the password provide the current password or be a member of the securityadmin fixed server role as well.

According to https://www.microsoft.com/en-us/msrc/windows-security-servicing-criteria and https://www.microsoft.com/en-us/msrc/sdlbugbar, the Microsoft Security Servicing Criteria for Windows and Microsoft Vulnerability Severity Classification for Windows warrant a security update for this issue.

Does the vulnerability violate the goal or intent of a security boundary or a security feature?

Yes, the User boundary is violated, as logins with ALTER ANY LOGIN can access and tamper with the data of any other login or user on the server and may access data at the operating system layer in the context of the service account running MSSQL Server. In addition, the Identity and access control and User safety security features are bypassed, allowing users with the ALTER ANY LOGIN permission access to any resource without explicit authorization and ability to make system-wide changes without administrator consent.

Does the severity of the vulnerability meet the bar for servicing?

Yes, this issue allows a Remote Authenticated User with the ALTER ANY LOGIN permission to obtain more privilege than authorized via Elevation of Privilege, resulting in a Severity of Important. With elevated privileges, the remote authenticated user could conduct Denial of Service (DoS), Information Disclosure (Targeted), Spoofing, Tampering, and Security Feature Bypass attacks in SQL Server or on the host system.

Disclosure

The ability to detect the conditions for exploitation of this vulnerability will be added to BloodHound Community Edition (https://github.com/SpecterOps/BloodHound) during the Black Hat USA [2025] conference.

Follow-up

I wanted to follow up as I just realized that in addition to escalating to sysadmin by changing the password of a SQL login with the securityadmin role, a server login with ALTER ANY LOGIN permission can also change the password of a SQL login with IMPERSONATE ANY LOGIN permission without providing the current password, then log in with the new password and impersonate the “sa” account to gain control of the SQL Server instance. Could you please take a look at this as well?

Recommended servicing is similar: If the login that is being changed has the IMPERSONATE ANY LOGIN permission, require that the login attempting to reset the password provide the current password or have the IMPERSONATE ANY LOGIN permission as well.

Configuration Manager Elevation of Privilege

Summary

The Microsoft Configuration Manager built-in CMPivot Administrator administrative user security role is granted unnecessary permissions that allow elevation of privilege to Full Administrator of the hierarchy, allowing arbitrary remote code execution on any client device managed by any site in the hierarchy (e.g., via application/package/script deployment). 

Specifically, the following permissions associated with the CMPivot Administrator security role exceed the documented purpose of this role and allow elevation of privileges:

• Users.Add – Allows the user to create a new administrative user and grant it any security role
• Users.Modify – Allows the user to modify an existing administrative user to grant it any security role
• Security Roles.Modify – Allows the user to modify an existing custom security role to grant any users assigned the role additional permissions

As a result, any user account assigned the built-in CMPivot Administrator security role may grant themselves (or any other account) the Full Administrator (or any other) role or modify existing security role permissions, effectively allowing them to bypass intended user/role security boundaries and grant themselves all permissions in the hierarchy.

Servicing

The CMPivot Administrator security role should be stripped of these unnecessary permissions and restricted to only the minimum necessary permissions to fulfill the security role’s documented purpose, “Grant permissions to run CMPivot”. The Collection.Read and Collection.Run CMPivot permissions are the minimum required to successfully run CMPivot, although read access to other objects may be desirable for console navigation without presenting a security risk.

According to https://www.microsoft.com/en-us/msrc/windows-security-servicing-criteria and https://www.microsoft.com/en-us/msrc/sdlbugbar, the Microsoft Security Servicing Criteria for Windows and Microsoft Vulnerability Severity Classification for Windows warrant a security update for this issue.

Does the vulnerability violate the goal or intent of a security boundary or a security feature?

Yes, the User boundary is violated, as users with CMPivot Administrator security role can access and tamper with the data of any other user in the hierarchy. In addition, the Identity and access control and User safety security features are bypassed, allowing users with the CMPivot Administrator role access to any resource without explicit authorization and ability to make system-wide changes without administrator consent.

Does the severity of the vulnerability meet the bar for servicing?

Yes, this issue allows a Remote Authenticated User with the CMPivot Administrator security role to obtain more privilege than authorized via Elevation of Privilege, resulting in a Severity of Important. With elevated privileges, the remote authenticated user could conduct Denial of Service (DoS), Information Disclosure (Targeted), Spoofing, Tampering, and Security Feature Bypass attacks on any site system or client device in the hierarchy.

Notes

This role may have other permissions that are unnecessary for the documented purpose but do not constitute a vulnerability or security boundary violation. For example, Collection.Modify, Collection.Create, Collection.Delete, Collection.Modify Collection Setting, Collection.Modify Folder, Security Roles.Delete, Security Scopes.Modify, Security Scopes.Create, Security Scopes.Delete, and Users.Remove (essentially anything beyond *.Read and Collection.Run CMPivot may be unnecessary. A thorough review to restrict permissions to the minimum for the role to fulfill its documented purpose is recommended.

Disclosure

Abusable security roles in Configuration Manager will be identified by the BloodHound attack path management software in a future release

Disclosure Timelines

CVE-2025-49758: MSSQL Server ALTER ANY LOGIN Permission Elevation of Privilege

• 2025-06-16: Reported to Microsoft with disclosure date MSSQLHound release during BlackHat USA
• 2025-06-23: Microsoft requested I delay public disclosure until they addressed the issue
• 2025-06-23: I updated the report with an additional permission with the same issue
• 2025-06-23: Microsoft confirmed the reported behavior
• 2025-06-23: Microsoft requested I delay public disclosure again
• 2025-06-26: Microsoft requested I delay public disclosure again
• 2025-07-01: Microsoft requested I delay public disclosure again
• 2025-07-01: Microsoft requested I delay public disclosure again
• 2025-07-09: I apologized that I missed their requests because the messages did not come through as email notifications (required sign-in to the MSRC portal). I explained that only the ability to enumerate permissions as documented would be added to MSSQLHound and released during Black Hat USA. I agreed to not draw any public attention to the issue.
• 2025-07-10: Fix rollout estimated August 8, 2025 (cloud fix to follow)
• 2025-07-14: I asked about CVE/bounty eligibility
• 2025-07-21: Microsoft requested I delay public disclosure again
• 2025-07-24: I explained that the tool release couldn’t be delayed but reiterated that it wouldn’t reach all BloodHound users (only those who downloaded the tool and ran it manually), would only enumerate the documented permissions, and wouldn’t highlight the issue in any publicly-facing content before the patch was released
• 2025-07-25: Assigned CVE-2025-49758
• 2025-07-25: I reported that the tool would be released on July 29, 2025 (a few days ahead of schedule, a surprise to me as well) and apologized for the last-minute change
• 2025-08-12: Fixes released for on-prem MSSQL
• 2025-08-18: Cloud fix rollout estimated September 4, 2025
• 2025-08-25: Issue confirmed out of scope of the bounty program
• 2025-09-25: Fix released for cloud MSSQL and case closed

CVE-2025-47179: Configuration Manager Elevation of Privilege Vulnerability

• 2025-03-21: Reported to Microsoft with note that a future BloodHound collector release would disclose and enable enumeration of the issue
• 2025-04-07: Microsoft responded to ask for a specific disclosure date and details
• 2025-04-11: Microsoft confirmed the reported behavior
• 2025-04-25: Microsoft confirmed a fix would be released
• 2025-04-29: I responded to explain that I’d like to update BloodHound to identify the issue in Q3/Q4 and asked about CVE/bounty eligibility
• 2025-05-21: Issue assigned Important severity
• 2025-05-22: Microsoft requested I delay public disclosure until they addressed the issue
• 2025-05-29: I agreed
• 2025-06-09: Fix rollout estimated November 2025
• 2025-06-23: Issue confirmed out of scope of the bounty program
• 2025-08-27: Fix rollout moved up to October 14, 2025 release and CVE-2025-47179 assigned
• 2025-10-09: Fix rollout pushed to November 11, 2025 release
• 2025-11-11: Fixes released and case closed

I hope this post helps you get a reported issue the attention it deserves or encourages you to take a deep dive into a monolithic technology, maybe even write an OpenGraph module for it! Thanks for reading and please hit me up on X (@_Mayyhem) or in the BloodHound Slack (@Mayyhem) if you have any questions or feedback for this post!