A newly disclosed local privilege-escalation vulnerability in Windows WalletService, tracked as CVE-2026-49176, allows a standard user to escalate to NT AUTHORITY\SYSTEM by abusing the way the service resolves file paths and processes database callbacks.
Microsoft rates the flaw Important, with a CVSS 3.1 score of 7.8, mapping it to CWE-269 (Improper Privilege Management) and CWE-59 (Improper Link Resolution Before File Access).
WalletService backs the public Windows.ApplicationModel.Wallet WinRT API, reachable by any standard user through WalletManager.RequestStoreAsync().
Windows WalletService Flaw
David Carliez stated that the service impersonates the caller to resolve their FOLDERID_Documents path, then reverts to LocalSystem before opening wallet.db inside a \Wallet\ subfolder with Extensible Storage Engine (ESE) persisted callbacks enabled.
Because a user can freely redirect their own Documents folder via SHSetKnownFolderPath, an attacker can:
- Pre-seed a malicious ESE database containing a
Cardstable with a persisted callback column pointing to an attacker DLL (callback.dll!ExportName) - Redirect their Documents folder to the directory containing that database
- Call the public Wallet API to trigger WalletService activation
- Have WalletService open the attacker’s database as LocalSystem, causing ESE to load the malicious DLL inside the SYSTEM service host
From there, the payload verifies it’s running as WinLocalSystemSid, spins up a short-lived Windows service to obtain a clean SYSTEM token, duplicates that token, retargets it to the active console session via WTSGetActiveConsoleSessionId, and launches cmd.exe with CreateProcessAsUserW producing a visible, interactive SYSTEM shell.
The root cause is a trust boundary violation: WalletService uses caller-controlled identity data (the redirected Documents path) to pick a filesystem location, then crosses back into a privileged context before validating what’s actually stored there.
Microsoft’s fix, tracked internally as Feature_Servicing_WalletServiceRedirectionGuard, gates the vulnerable ESE-opening logic in WalletDatabaseESE::Open along with related legacy folder-restriction and cleanup functions.
Patched builds (26200.8875+) still create an empty Wallet directory but never open the attacker’s database, never resolve the callback, and never load the malicious DLL.
Defenders should watch for non-admin processes altering per-user Documents known-folder mappings shortly before Wallet activity, WalletService-hosted svchost.exe loading DLLs from user-writable profile paths.
SYSTEM processes creating and rapidly deleting short-lived services that point to user-profile binaries, token session changes followed by cmd.exe launches on winsta0\default, and Wallet databases that predate the service’s first legitimate use.
Organizations should prioritize patching systems with WalletService enabled, particularly shared or multi-user Windows 11 endpoints where local access is common.
Cut SOC investigation blind spots and contain threats earlier to reduce response costs and business disruption with ANY.RUN.
