A few days ago we saw the release of a CVE article about a elevation of privilege vulnerability in the installer for System Center products using the Untrusted Search Path weakness.
First of all, this is not about already installed and running instances of SCOM, VMM, DPM, SCORCH, SCSM.
This is about the installer that was once downloaded and extracted and is sitting somewhere likely on your System Center server in an “install” or “sources” folder, or on a central share somewhere. You would want and need that in case you need to install a new component, or a new management server or whatever. If you unpack that big file, you finally get a folder with the installation files for a System Center product. In that folder is a setup.exe file that basically is the starting point for most installations of those products. The vulnerability is in that file.
The way I explain it to myself (in simple terms) is that this setup.exe is a wrapper meant for you to be able to select which components to install, and it uses some helper files and it makes connection to the files that will actually install your chosen feature (such as msi files). While doing that the vulnerability causes it to look for helper files in potentially untrusted search paths. For example if you open up a command prompt on your machine and it will list some current folder it is running in, and when you type a command such as “ping” it will go out and find that executable for you in the search path on your Windows machine. And because C:\Windows\System32 is in that path, it simply works. Now imagine an attacker placing some executable code in such a folder which is not part of your install media, but can be searched by it anyway. When you run setup.exe using your elevated credentials it might entice the executable to execute other code from a custom path. Of course the attacker would need to place the files somewhere, would need rights for that, would either want to use the executable which is a valid normal executable (from System Center) to execute their own code and continue onwards, or that they place the payload and wait for you to run the setup at some point.
The solution was of course Microsoft adjusting the code of the setup.exe in the install media a bit to fix this, using best practices and codes that are already available. Also for the big self-extractor executable which is that download. For the versions of 2019, 2022, and 2025 new downloads have been created for all System Center products involved.
Advice:
check where your old downloaded installers are for System Center products (SCOM, SCSM, DPM, VMM, Orchestrator) and their unpacked versions for 2019/2022/2025. Remove them.
Download new versions of those packages and unpack those when needed.
This does not change the version of the product, the installers still install the RTM version of that product for the version indicated. Also, the msi packages are not impacted.
For more information check out the links below.
For the Microsoft CVE article that includes also the download links for the products and versions discussed:
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-27743
The link from CVE org:
https://www.cve.org/CVERecord?id=CVE-2025-27743
For the definition of the untrusted search path vulnerability in general:
https://cwe.mitre.org/data/definitions/426.html
That’s it for now.