Windows AppResolver LPE: From AppContainer to SYSTEM 17 July 2026 / 11 min read Updated: 17 July 2026 View more blogs with the tag windows , View more blogs with the tag vulnerability-research , View more blogs with the tag local-privilege-escalation , View more blogs with the tag exploit-development , View more blogs with the tag appcontainer , View more blogs with the tag uac-bypass Table of Contents Executive Summary While diffing the July 2026 Windows security update, I found a new authorization check in Windows.UI.Storage.dll . The affected method belongs to the private WinRT class Windows.Internal.AppResolver.AppResolverActivationArgsFactory . Before the update, a process running in an AppContainer with no capabilities could ask this factory to construct an AppResolver object from caller-supplied launch data. That object could then make an attacker-controlled ProgID the protected default handler for ms-settings: . I turned that behavior into an end-to-end proof of concept. It starts from the ordinary filtered token of a local administrator, creates the protected association from a zero-capability AppContainer, and launches the registered handler through the auto-elevated fodhelper.exe . This yields a High-integrity administrator process without a UAC prompt. The PoC then creates a temporary service and uses its SYSTEM token to open an interactive command prompt in the signed-in user’s session. This is not a standard-user-to-SYSTEM exploit. The starting account must already belong to the local Administrators group, and the final High-to-SYSTEM step uses the expected service-control rights of an elevated administrator. The security boundary crossed by the AppResolver primitive is the AppContainer capability check; its practical use in this chain is a UAC bypass. I compared the vulnerable and updated binaries and ran the same trigger on both systems. These are the builds I validated: State OS build Windows.UI.Storage.dll Vulnerable 26200.8737 10.0.26100.8737 Updated 26200.8875 10.0.26100.8875 On build 26200.8737, the factory accepted the zero-capability caller and a protected association was created. On build 26200.8875, the same call returned E_ACCESSDENIED before an AppResolver object was returned. Attribution note: Microsoft’s public record for CVE-2026-50454 describes Windows User Interface Core relative path traversal (CWE-23) leading to arbitrary system-file deletion. The PoC in this article does not use relative path traversal and does not reproduce file deletion. It proves a missing AppResolver capability check in the same component, fixed by the same update, with a clean vulnerable-versus-updated runtime result. Without Microsoft’s private case details, I cannot claim that this is the root cause assigned to CVE-2026-50454. It may be another consequence of the same issue, an adjacent issue closed by the update, or a defense-in-depth change. The public version ranges and CVSS data are available in the Microsoft advisory and NVD record . Credits Microsoft credits the following researchers for CVE-2026-50454: @2st___ of Diffract Zhiniang Peng with HUST Thanatos Tian of Diffract Anonymous Daniel Friedl Background Registration is not selection Windows uses protocol associations to decide which application handles a URI. For example, ms-settings: normally opens Windows Settings. A desktop application can register itself as a candidate protocol handler under the current user’s registry hive, but registration is not supposed to make it the default automatically. The selection is meant to remain a user decision. Microsoft describes that model in its Default Programs documentation . Recent Windows versions store the selected handler in a protected UserChoice or UserChoiceLatest key. Alongside the ProgID, Windows stores a validation hash. Simply writing a ProgID under HKCU does not produce a valid choice; the association machinery rejects a missing or invalid hash. That distinction is the useful part of this bug. The question is not whether a user can write a registry value beneath HKCU. The question is whether an untrusted caller can persuade trusted Windows code to create a valid protected choice for metadata supplied by that caller. The private AppResolver interface Windows.UI.Storage.dll implements the private activation class: Windows.Internal.AppResolver.AppResolverActivationArgsFactory Its CreateAppResolverActivationArgs method accepts an IInspectable representing a pending launch and returns an AppResolver activation-arguments object. The contract is not a public API, but the class and method names are present in public symbols. For the protocol path used by the PoC, the input object exposes the following shape: IPendingLaunch + IPendingProtocolLaunch get_Scheme() -> "ms-settings" get_Uri() -> "ms-settings:" + IPendingLaunch2 get_LaunchProviders() -> vector of IExtensionInfo IExtensionInfo get_AppUserModelId() get_ProgId() -> attacker-controlled ProgID get_DisplayName() get_ApplicationIcon() The ret...