Microsoft has recently addressed a critical local privilege escalation vulnerability within WalletService on Windows systems. This flaw could enable standard users to gain full control over an affected machine, operating with the highest system privileges.
WalletService is a LocalSystem component utilized by the Windows Wallet WinRT API. The identified vulnerability, assigned a CVSS score of 7.8, stems from improper privilege management and unsafe file path resolution. Security researchers Chen Le Qi and Mochi Nishimiya from STAR Labs SG are credited with discovering this issue.
Exploitation Mechanism
The exploitation process begins when a low-privileged user alters the location of their Documents folder. WalletService processes Wallet API requests using the caller’s Documents path but then ceases impersonating that user, continuing to run with LocalSystem privileges. It appends a fixed Wallet directory name and attempts to open a file named wallet.db with elevated privileges.
This behavior creates a significant security risk. Although the service operates under LocalSystem, the database path can be influenced by a standard user through their Documents folder mapping. An attacker can set up a malicious Wallet directory and place a specially crafted Extensible Storage Engine (ESE) database inside it before triggering the service.
Technical Details
The public Wallet API provides a pathway for the attack. A standard user can request a Wallet store and list Wallet items, prompting WalletService to initialize its database. While direct activation of private Wallet components is restricted, the supported public API still leads to the same privileged initialization process.
The core issue lies in ESE persisted callbacks. ESE databases can contain metadata that instructs the database engine to load a DLL and call a specified exported function. Although this feature is intended for trusted databases, WalletService allows persisted callbacks before opening a database supplied via a user-controlled path. An attacker could create a wallet.db file containing the necessary Cards table and a callback reference pointing to a DLL they control.
When WalletService opens this database with LocalSystem privileges, ESE resolves the callback and loads the DLL within the WalletService process, typically an svchost.exe that runs as SYSTEM. This grants code execution at the highest local privilege level.
Security researcher David Carlier demonstrated how a loaded DLL verified its SYSTEM context and injected a SYSTEM token into the active desktop session, spawning an interactive NT AUTHORITY\SYSTEM command prompt. Notably, this exploit does not require memory corruption, a race condition, or administrator privileges. It merely relies on WalletService trusting a database located in a path derived from a standard user’s redirected Documents folder.
Mitigation and Recommendations
To mitigate this vulnerability, identified as CVE-2026-49176, Microsoft’s July 2026 update disables the affected legacy WalletService database path through a servicing feature known as WalletServiceRedirectionGuard. On patched systems, while WalletService may still create an empty Wallet directory, it will not open wallet.db, create ESE support files, change directory permissions, or process persisted callbacks.
Defenders are advised to apply Microsoft’s security updates promptly. Security teams should also monitor for unusual changes to per-user Documents folder mappings, WalletService access to wallet.db outside expected profile locations, and svchost.exe processes hosted by WalletService loading DLLs from user-writable folders. Additionally, the presence of short-lived SYSTEM services or SYSTEM-launched command shells in interactive sessions may indicate attempts to exploit this vulnerability.
This incident underscores the importance of rigorous privilege management and the need for continuous monitoring of system components that handle user data. Organizations should remain vigilant and ensure that all security patches are applied promptly to mitigate potential threats.
