A newly disclosed vulnerability chain in Microsoft’s System Center Configuration Manager (SCCM) allows any ordinary Active Directory user — with no administrative rights on SCCM and no elevated Windows privileges — to achieve remote code execution on an organization’s primary site server. Tracked as CVE-2026-47301 and reported to Microsoft by researchers at XM Cyber in May, the flaw was partially patched in July, with a complete fix not expected until SCCM’s ConfigMgr 2609 release in October.

Why This Matters

SCCM sits at the center of software deployment, patch management, operating-system imaging, and device configuration for many enterprise Windows fleets. A remote code execution flaw reachable by a standard domain account — rather than one requiring insider access or stolen admin credentials — collapses the effort needed to go from “any employee’s login” to controlling the infrastructure that pushes software and policy to every managed endpoint in the organization.

Four Flaws Chained Into One Exploit

Rather than a single bug, the attack strings together four separate weaknesses in how SCCM handles package uploads and validation:

• Authorization bypass: A chunked-upload endpoint fails to enforce the same authorization checks applied to the standard upload path, letting an authenticated domain user submit a malicious CAB (cabinet archive) file that should otherwise be off-limits.
• Signature validation bypass: SCCM does not confirm that the certificate signing an uploaded package actually belongs to Microsoft or the target organization, and it skips certificate-revocation checks altogether — meaning any accepted, even unrelated, certificate can be used to sign a hostile package.
• Path traversal (“CabSlip”): During extraction of the CAB archive, SCCM fails to properly block relative path sequences, giving the attacker the ability to write files to arbitrary locations on the server’s file system.
• Unverified DLL loading: The SMS Executive service subsequently loads a file named adsource.dll without performing integrity checks equivalent to those used elsewhere in the product — executing the attacker’s planted code with SYSTEM-level privileges.

Chained together, these four steps take an attacker from a routine domain login to full code execution as SYSTEM on the SCCM primary site server, with no user interaction required at any point.

The Blast Radius: An Entire Managed Fleet

Because SCCM primary site servers are trusted to push executables, scripts, and configuration to every device they manage, compromising one effectively hands an attacker the ability to control an organization’s entire managed Windows environment — deploying malicious software under the guise of routine patching, altering OS images, or reconfiguring devices at scale. For ransomware operators and other financially motivated intruders, an SCCM takeover is close to a best-case outcome: a single foothold that converts into organization-wide deployment capability.

A Familiar Pattern: Low-Severity Bugs, High-Severity Chain

Individually, none of the four component flaws would necessarily be classified as critical — an authorization gap here, a missing certificate check there. It’s the chaining that turns them into a full remote-code-execution path, a pattern that has become increasingly common in enterprise management software as attackers and researchers alike focus less on single silver-bullet bugs and more on stitching together smaller design gaps. It also illustrates why patch management tools, which are granted broad trust and reach across an environment precisely so they can manage it, make especially attractive targets: a flaw in the tool meant to secure the fleet can just as easily become the fastest way to compromise it.

Patch Status and Practical Guidance

Microsoft’s July update addressed the authorization and signature-validation issues, narrowing the exploit chain, but the underlying path-traversal and DLL-loading weaknesses are not expected to be fully resolved until ConfigMgr 2609 ships in October. Until then, security teams are advised to treat this as an active exposure rather than a fully closed issue.

Recommended interim steps include:

• Monitoring AdminService.log for DirectoryNotFoundException errors followed by HTTP 500 responses, which the researchers flag as a possible sign of exploitation attempts
• Auditing for unexpected or unauthorized CAB file upload activity
• Watching for unexpected changes to adsource.dll within the Configuration Manager installation directory
• Restricting network access to the AdminService port to only trusted management hosts
• Reviewing SCCM role-based access assignments to ensure the principle of least privilege is being followed

Given that exploitation requires nothing more than a standard domain account, organizations running on-premises SCCM should treat patching — and interim monitoring — as an urgent priority rather than something to fold into a routine maintenance cycle.