$58 Certificate, Four Flaws: Researchers Show How SCCM Can Hand Attackers the Keys to an Entire Company
A security research team chained together four weaknesses in Microsoft's enterprise device-management software to reach full system control, starting with nothing more than a standard company login.

Key points
- Researchers at XM Cyber found that a normal company account, with no special IT privileges, can be used to take over Microsoft SCCM servers and every device they manage.
- The attack chain combines four separate weaknesses, one of which Microsoft patched in July 2025 (CVE-2026-47301), with the remaining three not expected to be fully fixed until October 2025.
- A commercial code-signing certificate costing roughly $58 was enough to pass SCCM's signature check, because the software does not verify that the certificate belongs to Microsoft or the target organisation.
- Organisations can reduce exposure now by restricting network access to the SCCM AdminService API and auditing which accounts hold the Operations Administrator role.
- No confirmed real-world exploitation has been reported, but full technical details are now public.
What is SCCM, and why does it matter here?
Microsoft SCCM, formally called System Center Configuration Manager (a Microsoft tool that IT teams use to install software, push security updates, and manage thousands of company computers from one place), sits at the heart of most large Windows-based organisations. Whoever controls it, effectively controls every device it manages.
Researchers at security firm XM Cyber found they could start with an ordinary staff account, the kind any employee has, and work up to running any code they chose on the SCCM server itself as "NT AUTHORITY\SYSTEM," which is the highest level of control a Windows machine allows. XM Cyber's Omri Baso, speaking to CSO Online, put it plainly: once the server is taken over, every computer it manages is taken over too.
How did the attack actually work?
The chain has four links, each one building on the last.
First, SCCM's AdminService API (a programming interface that lets administrators manage the system remotely) has an upload function that comes in two forms: a normal upload that checks your permissions, and a "chunked," or split-file, upload that does not. Any authenticated company account could use that second route to send a malicious CAB archive, a compressed package of files, to the server.
Once that package arrived, a path-traversal flaw the researchers nicknamed "CabSlip" let the files escape the folder they were supposed to land in and be written anywhere on the server's hard drive. The attacker used this to replace a file called "adsource.dll," a software library that the SCCM service loads automatically.
Here is where the certificate comes in. SCCM checks that uploaded files carry a valid digital signature, the electronic equivalent of a wax seal. But it does not check whether that seal belongs to Microsoft or to the company being targeted. It only checks that the seal is structurally correct and not expired, and it does not even check whether the certificate has been revoked. Baso used a commercially available Certum Open Source Developer Certificate that cost him about $58 to satisfy that check.
With the replacement library in place and the signature check passed, the SCCM service loaded the attackers' file the next time it ran, handing over full system-level control.
What has Microsoft fixed, and what is still outstanding?
| Issue | Identifier | Status | Expected fix |
|---|---|---|---|
| Broken permission check on chunked upload | CVE-2026-47301 | Patched July 2025 | Done |
| CabSlip path-traversal flaw | Not yet assigned | Unpatched | ConfigMgr 2609, October 2025 |
| Weak code-signing validation | Not yet assigned | Unpatched | ConfigMgr 2609, October 2025 |
| Unsigned DLL-loading in SMS Executive | Not yet assigned | Unpatched | ConfigMgr 2609, October 2025 |
Microsoft's July patch closes the door for standard domain accounts. Accounts holding the built-in Operations Administrator role can still reach the downstream parts of the chain, though XM Cyber notes that role is already highly privileged, so organisations with sensible access controls face lower risk through that route.
What should IT teams do right now?
Three concrete steps are available before October's full patch arrives. Restrict network access to the AdminService API so only authorised management systems can reach it. Review which accounts carry the Operations Administrator role or any custom role with "Create" permission on "SMS_ConsoleExtensionData," and remove any that should not have it. Watch the server's "AdminService.log" file for the error message "System.IO.DirectoryNotFoundException" followed by an HTTP 500 response, a pattern XM Cyber says can signal the path-traversal was attempted. Unexpected changes to "adsource.dll" inside the Configuration Manager installation folder are a second warning sign worth monitoring.
Microsoft had not responded to requests for comment at the time of publication.
Common questions
Does this affect ordinary employees directly?
Could my organisation's computers be taken over without anyone noticing?
Yes, in theory. If an attacker already inside your network used this chain successfully, every computer managed by your SCCM server could be under their control. The detection signals above are the practical first line of defence while patches are pending.
Do I need to do anything as an employee?
Not directly. This is a fix IT and security teams need to apply. If you receive any unusual software prompts or are asked to re-enter your company password unexpectedly, report it to your IT desk.



