SCCM Console Extension Chain (CVE-2026-47301): From Domain User to SYSTEM on the Site Server

Executive Summary

• CVE-2026-47301 is a broken authorization check on the Configuration Manager administration service. Microsoft scores it CVSS 8.8 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H), maps it to CWE-284, and rates it Important. Microsoft's advisory credits Omri Baso with XM Cyber and, independently, mick3y with Team SaturnX.
• The lever is a single omission. The administration service exposes two ways to upload a console extension cabinet, and only one of them checked whether the caller held the Create permission on SMS_ConsoleExtensionData.
• XM Cyber's published chain is four weaknesses: the broken RBAC check, weak code-signing verification, a cabinet path traversal they call CabSlip, and an unverified secondary DLL load in SMS Executive. Together they can lead to code execution as SYSTEM on a primary site server.
• Microsoft released KB38232642 in June 2026 and published the CVE record on July 14, 2026. The update closes the unauthenticated-by-role entry point. XM Cyber reports Microsoft planned to address the remaining links in Configuration Manager 2609, expected October 2026; that is a vendor plan relayed by the researcher, not confirmed 2609 behavior, so verify it against Microsoft's release notes when 2609 ships.
• Affected builds per Microsoft: 2503 below 5.0.9135.1031, 2509 below 5.0.9141.1030, 2603 below 5.0.9146.1021.
• Microsoft's temporal vector records E:U, exploit code unproven, and the advisory states the issue was neither publicly disclosed nor exploited at publication. A full exploit suite has since been published on the researcher's GitHub, so treat that temporal rating as stale.
• After the update, the remaining chain still matters for principals holding Create on SMS_ConsoleExtensionData. The built-in Operations Administrator role carries it, according to the research.

The Vulnerability

Configuration Manager exposes a REST API called the administration service, hosted by the SMS Provider over HTTPS on port 443. Microsoft's contract for it is explicit: "To access the administration service, your user account needs to be an administrative user in Configuration Manager." Every operation behind that endpoint is supposed to be gated by role-based administration, the same model that governs the console.

One of those operations imports a console extension. An extension ships as an Authenticode-signed .cab file that the site server unpacks and stores, and that console operators can later install locally. Microsoft documents the supported import paths: a PowerShell script that posts the cabinet through the administration service, or the Import Console Extension wizard in 2111 and later. Both are administrative actions.

The AdminService offers this upload twice. There is a single-shot UploadExtension method, and there is a chunked variant for larger payloads:

/AdminService/v1.0/ConsoleExtensionMetadata/AdminService.UploadExtensionInChunks

Baso found that the single-shot path performs the RBAC check and the chunked path does not. Same destination, same effect on the site server, one of them unguarded. He identifies the skipped permission as Create (bitmask 1024) on object type 230, SMS_ConsoleExtensionData. Microsoft does not publish that mapping, so treat the object id as the researcher's reading of the product rather than a documented constant.

That is CVE-2026-47301. Microsoft's own FAQ describes the consequence without ceremony: an attacker "could exploit this vulnerability by sending specially crafted requests to the affected service interface, allowing them to upload content without the required permissions", and "could gain SYSTEM privileges".

The Rest of the Chain

Getting a cabinet accepted is not the same as getting code to run. XM Cyber describes the full chain as four weaknesses, of which the CVE is the first:

Link	Weakness	What it gives the attacker
1	Broken RBAC on the chunked upload endpoint (CVE-2026-47301)	A cabinet reaches the site server without the Create permission
2	Weak code-signing verification: any Authenticode signature chaining to a trusted root is accepted, and CRL checking is disabled	A commodity certificate satisfies the check, with no approved-publisher boundary
3	CabSlip, a path traversal during cabinet extraction via the .cab format's own destination-directory directive	An arbitrary file write primitive anywhere on the site server file system
4	adsource.dll is loaded without an independent signature or integrity check	Attacker-controlled code runs inside a SYSTEM service

Link 2 is the one that sets the price. Validation asks whether the cabinet is signed by someone trusted, not whether it is signed by an approved publisher. The research reports a commercial code-signing certificate costing about $58 as sufficient; CSO Online identifies it as a Certum open-source developer certificate. An internally issued certificate from an organization's own AD CS hierarchy sits in the same category. Because CRL checking is disabled, a revoked certificate would still need only to satisfy the remaining checks, such as its validity period.

Link 4 is the payoff, and the mechanism is worth stating precisely. SMS Executive loads adsysdis.dll, the Active Directory System Discovery component, and that library is itself verified. adsysdis.dll then imports adsource.dll through its static import table, and that second-level load carries no signature check of its own. The hijack point is not "before verification"; it is a dependency that is never verified at all. Baso's proof of concept forwards the legitimate exports through to the original library so the service keeps running normally, which is why the technique is quiet.

How the Attack Works

1. Authenticate as a domain user. The AdminService accepts integrated Windows authentication. Before KB38232642, no Configuration Manager role assignment was needed, only a valid domain account and network reach to the SMS Provider on 443.

2. Post a crafted cabinet through the chunked upload endpoint. The missing check means the request is accepted and the cabinet is written to a temporary extraction area on the site server.

3. Satisfy the signature check with a purchased or borrowed certificate. The validator confirms the cabinet is Authenticode-signed and chains to a trusted root. It does not confirm who signed it, and it does not check revocation.

4. Escape the extraction directory. The cabinet format carries its own destination-directory directive, which is prefixed onto member file names. Traversal sequences in that prefix survive the extraction path handling, so members land wherever the attacker points them, including the Configuration Manager installation directory.

5. Wait for the service to load the planted library. SMS Executive picks it up on its normal cycle, within minutes. Code runs as SYSTEM on the primary site server.

From there the attacker inherits the site's own reach. A primary site can deploy applications, scripts, and task sequences to the devices assigned to it, so the blast radius is whatever that site manages. In a hierarchy where one primary carries most of the estate, a server compromise and a fleet compromise are the same event.

What the Security Update Fixes

This is where the advisory and the operational reality diverge, and it is worth being precise about dates as well as behavior. Microsoft lists June 2026 as the initial release of KB38232642, the console-extension security update, delivered through Updates and Servicing. The CVE record itself was published on July 14, 2026.

The update restores the permission check on the chunked upload endpoint. After it is installed, an account with no Configuration Manager role cannot post a console extension. That closes the "any domain user" entry point, and it is the difference between a chain that starts with a mailbox-level account and one that starts with a delegated administrator.

XM Cyber reports that it does not touch links 2 through 4, and that the remaining weaknesses stay reachable through the checked upload endpoint by a caller who legitimately holds the Create permission. They also report Microsoft planned to address the remainder in Configuration Manager 2609. Because 2609 had not shipped at the time of writing, treat that as a plan relayed by the researcher rather than confirmed product behavior, and re-check it against Microsoft's release notes when the version lands.

That permission is not exotic. Microsoft describes the built-in Operations Administrator role as granting "permissions for all actions in Configuration Manager except for the permissions to manage security", and notes that this role "can't manage administrative users, security roles, and security scopes". The documented intent is a powerful operator explicitly walled off from the security boundary. XM Cyber found that the role includes Create on SMS_ConsoleExtensionData, which is enough to use the checked path.

So the practical reading of the update is that it changed who can start the chain rather than whether the chain exists. That does not mean every Configuration Manager operator can exploit the remainder. The open questions for a given principal are whether they hold the object permission, can reach the endpoint, can satisfy the certificate requirement, and are targeting a topology where the documented file-write and DLL-load path applies. What it does mean is that the ConfigMgr administrator list is now worth auditing as a security boundary, and that is work you can do this week.

Prerequisites and Scope

• Before KB38232642: any authenticated domain account with network reach to the administration service on an affected SMS Provider. No Configuration Manager permissions of any kind.
• After KB38232642: an account holding Create on SMS_ConsoleExtensionData, plus access to the regular upload endpoint. The built-in Operations Administrator role carries that permission, as do Full Administrator and custom roles copied from either.
• A code-signing certificate whose chain the target trusts and that passes the checks the product still enforces. Commercially available, or issued by the organization's own CA.
• Affected versions: Configuration Manager current branch 2503 below 5.0.9135.1031, 2509 below 5.0.9141.1030, and 2603 below 5.0.9146.1021.
• Not required: Domain Admin, local access to the site server, or any interaction from an administrator.

One topology point matters for both exploitation and detection. Microsoft supports installing the SMS Provider on the primary site server, on the site database server, or on another server entirely, and a site can have several providers. SMS Executive runs on the site server. So the upload lands on a provider, while the DLL load happens on the site server, and those are not always the same machine. The published research describes the path where they line up. Validate each provider host separately rather than assuming one set of paths across the hierarchy.

Detection and Hunting

Three questions are worth answering: did someone try it, who could still do it, and is the site server already carrying a planted library.

The checks below were written against WMI classes Microsoft documents. We did not reproduce the exploit chain in our own lab, so nothing here is presented as lab-confirmed output. The mechanism is established by Microsoft's own advisory and FAQ, by the fix Microsoft shipped, and by the discloser's published proof of concept.

Catch the attempt (AdminService log). Microsoft's log reference places adminservice.log on the computer with the SMS Provider, in the Configuration Manager installation directory, and documents its request format in the administration service setup guide. Their own worked example reads:

Processing incoming request for resource [https://smsprovider.contoso.com/adminservice/v1.0/%24metadata], method: [GET], User - [CONTOSO\jqadmin]
...
Completing request with response code [200] reason [OK]

That line is long enough to scroll sideways in most readers, and the two fields that matter are at the end of it: method: and User -. An extension upload appears in the same shape, as a POST to a ConsoleExtensionMetadata resource, with the caller's account in that User - field. Two things are worth alerting on. The first is any request touching the console extension upload endpoints from an account that is not a known console operator. Extension imports are rare, deliberate, and usually traceable to a change ticket, so the baseline is close to empty. The second is the failure signature Baso reports when extraction goes wrong: a System.IO.DirectoryNotFoundException for a path under the expanded-cabinet folder, immediately followed by an HTTP 500 response. The extraction folder identifier changes on every attempt, so the pattern to look for is repeated 500s with differing identifiers rather than a single fixed string.

Run this locally on each SMS Provider, not against the site server, since those can be different hosts:

# Local to the SMS Provider. Adjust if Configuration Manager is not on the default path.
$AdminServiceLog = 'C:\Program Files\Microsoft Configuration Manager\Logs\adminservice.log'

Select-String -Path $AdminServiceLog `
              -Pattern 'UploadExtension|DirectoryNotFoundException|response code \[500\]' |
  Select-Object LineNumber, Line

Pair it with the console itself. Administration > Updates and Servicing > Console Extensions lists every extension the hierarchy has ever accepted. An entry nobody recognizes, or one that appeared outside a change window, is the same event seen from the other side.

Hunt the exposure (native, no extra tooling). Three checks, all against WMI classes Microsoft documents, all read-only, all runnable from a host with rights to the SMS Provider.

First, confirm the site is actually on a fixed build. Version drift between what a patching report claims and what the site reports is common in ConfigMgr because the update installs through the console rather than through Windows Update:

$loc = Get-CimInstance -Namespace 'root\SMS' -ClassName SMS_ProviderLocation |
       Where-Object ProviderForLocalSite | Select-Object -First 1
$ns  = "root\SMS\site_$($loc.SiteCode)"

# Fixed builds, keyed by the third version field (2503 -> 9135, 2509 -> 9141, 2603 -> 9146)
$fixed = @{ '9135' = 1031; '9141' = 1030; '9146' = 1021 }

Get-CimInstance -ComputerName $loc.Machine -Namespace $ns -ClassName SMS_Site |
  Select-Object SiteCode, SiteName, ServerName, Version, InstallDir,
    @{ n='Type';   e={ switch ($_.Type) { 1 {'Secondary'} 2 {'Primary'} 4 {'CAS'} } } },
    @{ n='Status'; e={
         $p = $_.Version -split '\.'
         if (-not $fixed.ContainsKey($p[2])) { 'Unknown branch, check manually' }
         elseif ([int]$p[3] -ge $fixed[$p[2]]) { 'Fixed' }
         else { "AFFECTED (needs $($p[0]).$($p[1]).$($p[2]).$($fixed[$p[2]]))" } } }

The branch mapping is 5.0.9135.x for 2503, 5.0.9141.x for 2509, and 5.0.9146.x for 2603. If the site reports a branch that is not in that table, it is either older than the affected set or newer than this post, and the Security Update Guide entry is the authority.

Second, list who can still reach the chain after the patch. SMS_Admin exposes every role-based administration principal, and RoleNames is a plain read-only property rather than a lazy one, so it comes back from an ordinary query:

Get-CimInstance -ComputerName $loc.Machine -Namespace $ns -ClassName SMS_Admin |
  Select-Object LogonName, DisplayName, IsGroup,
                @{n='Roles'; e={ $_.RoleNames -join ', ' }} |
  Where-Object { $_.Roles -match 'Operations Administrator|Full Administrator' } |
  Sort-Object LogonName | Format-Table -AutoSize

This is a prioritization aid, not a complete permission audit. It matches on role names, so a custom role carrying Create on SMS_ConsoleExtensionData under a different name will not appear, and a listed principal may still lack another prerequisite. Expand nested Active Directory groups, and check custom role permissions in the console. Treat the IsGroup rows as the important ones: a single Operations Administrator group can hide a large and stale membership behind one line of output.

Third, check whether anything has already been planted. This one belongs on the site server, where SMS Executive runs, which is not necessarily the provider you just queried. Legitimate Configuration Manager binaries are Microsoft-signed, so an unsigned or third-party-signed library in the binary directory is worth explaining:

# Local to the site server. Confirm the path first, or read SMS_Site.InstallDir.
$installDir = 'C:\Program Files\Microsoft Configuration Manager'

Get-ChildItem -Path (Join-Path $installDir 'bin\x64') -Filter *.dll -ErrorAction SilentlyContinue |
  ForEach-Object {
    $sig = Get-AuthenticodeSignature $_.FullName
    if ($sig.Status -ne 'Valid' -or $sig.SignerCertificate.Subject -notmatch 'O=Microsoft Corporation') {
      [pscustomobject]@{
        File   = $_.Name
        Status = $sig.Status
        Signer = $sig.SignerCertificate.Subject
        Written = $_.LastWriteTime
      }
    }
  } | Sort-Object Written -Descending | Format-Table -AutoSize

The two names to look hardest at are adsysdis.dll and adsource.dll, the discovery component and the library it imports, since those are the pair the published chain targets. A copy of adsource.dll renamed to something like adsource_original.dll sitting alongside a fresh unsigned adsource.dll is the proxy-DLL pattern, not a servicing artifact.

A word on false positives. Each of these has honest noise, and it is worth stating it rather than pretending otherwise:

• The signature check returns legitimate rows. Third-party console extensions, redistributables, and some support tooling land in the same directory tree and are not Microsoft-signed. The signal is not "unsigned file exists", it is an unsigned or unfamiliar library whose write time does not line up with a site update or an extension you approved.
• The log pattern will also fire on genuine failed imports, including an operator importing a malformed or unsigned cabinet. What distinguishes exploitation is repetition: many 500s with different extraction GUIDs, from an account that has no history of importing extensions.
• The RBAC query is not a list of attackers. It is a list of people who currently hold more authority than the role description implies. Most of them are supposed to be there. The point is that the number is usually larger than the ConfigMgr owner expects.

Mitigation

1. Update to a fixed build. Install the console extension security update, KB38232642, through Updates and Servicing in the console. It applies directly to 2603, and to 2503 with update rollup KB32851084 already installed. On 2509 it is included in the second update rollup, KB37864969, so no separate hotfix is needed. Confirm the result with the SMS_Site.Version check above rather than with the patching report: 2503 at 5.0.9135.1031, 2509 at 5.0.9141.1030, 2603 at 5.0.9146.1021.
2. Restrict who can reach the AdminService. The service listens on HTTPS 443 on the SMS Provider. Nothing outside the console estate and your automation needs to talk to it. Firewall it to that set. This is the control that holds while the remaining links are unpatched, and the provider cannot simply be disabled without breaking the console. Account for other services sharing port 443 before applying host-level rules.
3. Audit Configuration Manager RBAC, specifically Operations Administrator. Run the SMS_Admin query and take the output seriously. Any principal holding Operations Administrator or Full Administrator can still reach SYSTEM on the site server through the checked upload path until ConfigMgr 2609. Remove grants that are no longer needed, replace broad built-in roles with custom roles that drop the console-extension create permission where operators do not need it, and expand nested groups before deciding a grant is small.
4. Protect the site server as a control-plane system, and review who already administers it. A primary site can deploy applications, scripts, and task sequences to the devices it manages, so its effective reach is set by hierarchy design, collections, and security scopes rather than by its server role. Where that reach is broad, give the host the administrative separation, jump-host requirement, and credential hygiene you give a Domain Controller. Then read its local Administrators membership, because those principals already hold a one-step path to the same SYSTEM context, and no update in this advisory changes that.
5. Baseline the extension inventory and the binaries. Record what is legitimately in the Console Extensions node, then alert on additions. Snapshot the signature state of the site server's binary directory so that an unsigned library appearing later is a diff rather than a judgement call.
6. Reassess when ConfigMgr 2609 ships. XM Cyber reports Microsoft planned to address the path traversal, the signature validation, and the DLL load there. Confirm the actual fixes in Microsoft's release notes before closing the finding. Until then, the mitigations above are the control.

Conclusion

The missing check on the chunked upload endpoint is the kind of defect that gets found by reading two functions side by side and noticing that one of them is shorter. KB38232642 closes it. What keeps CVE-2026-47301 on a risk register after that is everything behind it in the published chain: a signature check that asks whether a file is signed rather than by whom, an extractor that trusts a path it was handed, and a second-level DLL that nothing verifies.

So the update changed who can start this rather than whether the chain exists. The concrete work is unchanged by that nuance: install the applicable update, confirm the version the site actually reports, restrict who can reach each SMS Provider, audit which principals hold Create on SMS_ConsoleExtensionData, and baseline adsource.dll on the site server. Then re-check the remaining links when 2609 ships rather than assuming they closed.

References

1. Omri Baso (XM Cyber): From Domain User to Enterprise Control
2. XM Cyber: Potential for Remote Code Execution in Microsoft SCCM
3. Microsoft Security Update Guide: CVE-2026-47301
4. NVD: CVE-2026-47301
5. Microsoft: KB38232642 Security update for Microsoft Configuration Manager Console Extension
6. Microsoft: KB37864969 Second update rollup for Configuration Manager version 2509
7. Microsoft: What is the administration service in Configuration Manager?
8. Microsoft: Import Configuration Manager console extensions
9. Microsoft: Fundamentals of role-based administration for Configuration Manager
10. Microsoft: Plan for the SMS Provider
11. Microsoft: SMS_Admin server WMI class
12. Microsoft: SMS_Site server WMI class
13. Microsoft: How to set up the administration service in Configuration Manager
14. Microsoft: Configuration Manager log file reference
15. CSO Online: It took $58 to break Microsoft's SCCM, but a patch made it harder