Windows Installer supports a repair operation that restores missing or modified files for an installed product. Repair is driven by the installation database, and the repair process has to find the source files it needs. That resolution step is where this class of issue lives.
The mechanism, stated carefully
During a repair, msiexec reads the product database and attempts to source the components it must restore. When the original source media is unavailable, Windows Installer can fall back to locations it considers valid, including cached package data and directories resolved from the installation context.
The security-relevant question is which directory is used to resolve a path, and whether a non-administrative user can write to it. Where an installer recorded a per-user or user-writable location as the source for a component, a repair may reconstruct that component from a directory the current user controls.
This is documented installer behaviour. It becomes a security issue through the combination of three conditions: the product runs as SYSTEM or elevated, the component is restored from a user-writable location, and an unprivileged user can trigger or wait for a repair.
Why this pattern keeps appearing
Per-user installations and per-machine installations behave differently. Per-machine installation puts files and registration in a shared context, which usually means the resolution paths are administrative. Per-user installation writes into the user's profile, and the profile is user-writable by definition.
When a product supports both and the installer is not careful about the distinction, a per-machine service can end up with a component registered to a per-user path.
The second contributor is the source list. Installers record source locations at install time, including any mapped or local directory used during deployment. If that directory remains writable by non-administrators, it stays a valid resolution candidate for the life of the product.
The conditions to test
Check whether the affected product installs a service or a scheduled task running as SYSTEM.
Check the registered component paths. An install directory under a user profile for a machine-scope product is a finding worth explaining.
Check whether repair can be triggered without elevation. Users can typically initiate a repair for a product installed in their own context.
Check whether the recorded source directory still exists and who can write to it.
These four checks are ordinary configuration review and require no exploit.
Reducing the surface
Prefer per-machine installation for anything that installs a service, and verify the resulting paths after deployment rather than assuming the flag was honoured.
Audit the source directory after installation. A deployment share that stays writable by the team that built the package is a persistent source for any repair operation.
Watch for the invocation pattern. Repair operations are logged, and an unexpected repair of a service-bearing product outside a maintenance window is a signal.
Apply vendor updates that change the resolution behaviour, and confirm the fix by re-testing the four conditions rather than by reading the advisory title.
Limits
Windows Installer repair is a legitimate function and the mechanism described here is documented. Whether a specific product is exploitable depends on its component registration, its installation scope, and the permissions of the recorded source directory. This is not a claim about any particular vendor's installer.
References
Microsoft documentation, Windows Installer and the repair process: https://learn.microsoft.com/en-us/windows/win32/msi/repair
Microsoft documentation, msiexec command-line options: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/msiexec
Microsoft documentation, Windows Installer source resolution: https://learn.microsoft.com/en-us/windows/win32/msi/source-resiliency