Microsoft has addressed a local privilege escalation vulnerability in WalletService on Windows. This flaw could allow a standard user to gain full control over an affected machine, operating as \text{NT AUTHORITY\SYSTEM}.
The vulnerability specifically affects WalletService, a LocalSystem component used by the public Windows Wallet WinRT API. Microsoft has rated this issue as Important, assigning it a CVSS score of 7.8.
It has categorized it under improper privilege management and unsafe file path resolution. Credit for discovering the vulnerability goes to Chen Le Qi and Mochi Nishimiya from STAR Labs SG. The attack begins when a low-privileged user changes the location of their Documents known folder.
WalletService processes Wallet API requests using the caller’s Documents path but then stops impersonating that user and continues running with LocalSystem privileges. It appends a fixed Wallet directory name and attempts to open a file named wallet.db with elevated privileges.
This creates a significant trust boundary. Even though 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.
WalletService Privilege Escalation Flaw
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 researchers found that direct activation of private Wallet components is restricted, the supported public API still leads to the same privileged initialization process.
The main 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.
GitHub 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.
To mitigate this vulnerability, CVE-2026-49176, Microsoft’s July 2026 update turns off 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.
