Microsoft Windows Installer Folder Delete Privilege Escalation

A vulnerability exists within the Windows Installer service's COM interface, specifically through the CMsiConfigurationManager object exposed via msi.dll. This flaw allows a low-privileged user to force the SYSTEM-level MSI service to delete arbitrary folders by manipulating registry entries. The exploit chain involves using methods like MsiBeginTransactionW and SetEEUIDirectoryAndFilter to place folder paths into the TempPackages registry key, followed by invoking CleanupTempPackages(). The vulnerability arises because the service trusts these registry entries without verifying if the paths originated from the installer itself.
The exploitation leverages a sequence where an attacker gains initial write access to a folder with DELETE permissions and uses the COM interface to register this path for deletion during cleanup. While the system attempts to mitigate this through feature flag checks within SetEEUIDirectoryAndFilter(), the core logic flaw in CleanupTempPackages allows for silent deletion of user-specified paths stored in TempPackages.
The remediation involves ensuring that folder operations are validated against a trusted source, rather than solely relying on file system permissions during the cleanup phase, which is where the trust assumption is broken.

* The vulnerability exists in the COM interface exposed from msi.dll.
* A low-privileged user can cause the MSI service to delete an arbitrary folder accessible to the user.
* This is achieved by scheduling a folder path in the TempPackages registry key using COM calls.
* The MSI service blindly trusts paths stored in TempPackages without validating their origin from the installer.
* The exploit uses MsiBeginTransactionW() and SetEEUIDirectoryAndFilter() to register the path.
* CleanupTempPackages() enumerates and deletes folders referenced in TempPackages as SYSTEM.
* The vulnerability is assigned CVE-2025-27727, patched in April 2025.
* The exploit requires the caller to have DELETE permission on the target folder via CreateFileW().
* The cleanup process involves calling FDeleteFolder() which executes as SYSTEM and uses RemoveDirectoryW().

The existence of this vulnerability highlights a critical gap in trusting internal state management within privileged system services. The mechanism relies on a flawed assumption: that data stored in a specific registry location reflects the operational reality managed by the service, rather than being an attacker-controllable input channel. The pattern is one where a privilege escalation vector (the ability to write arbitrary paths) is chained with a trust failure (the cleanup routine trusting the written path).
The complexity of the exploit chain, involving manipulating handles with specific permission flags and tracking file system operations across multiple stages—from preparing the environment to triggering the final deletion—suggests a sophisticated understanding of Windows security mechanisms, specifically NTFS ACL handling during handle operations. The mitigation introduced via a feature flag demonstrates that vulnerabilities can be neutralized by inserting explicit checks into the flow where trust is established, shifting the reliance from implicit privilege validation to explicit authorization in critical code paths.
The implication for cognitive sovereignty lies in recognizing that seemingly benign internal state management components, like COM interfaces and registry cleanup routines, are highly susceptible to exploitation if input validation across process boundaries is incomplete. When system integrity relies on an internal, unverified data source, the security posture degrades significantly. What assumptions about the persistence of file system permissions across privileged operations should be questioned when designing trust relationships between system components?