InstallService StaticPluginMap, From Standard User to SYSTEM

The bug

I found that a standard Windows user could write two machine-wide InstallService registry paths. The service later reads those paths as NT AUTHORITY\SYSTEM and uses them to choose a plugin DLL. Point the mapping at a user-controlled DLL, invoke the Store update search, and that DLL loads inside the privileged service process.

InstallService is part of the Microsoft Store installation and update stack.

Microsoft classifies CVE-2026-50343 as CWE-269: Improper Privilege Management. I think the underlying mistake is better described by CWE-732: Incorrect Permission Assignment for Critical Resource: the permissions allow a low-privileged user to decide which code a SYSTEM service loads.

Microsoft assigned a CVSS 3.1 score of 7.8 High (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) and released security updates on July 14, 2026.

MSRC tracked my report as case 120271 / VULN-192719. They later told me it duplicated an earlier submission from another researcher. The analysis and reproduction below come from my own testing; I am not claiming first-report credit.

Impact

The exploit starts from an ordinary Windows user session. It needs no administrator token and no second user action. The user writes the plugin mapping, triggers the Store update workflow, and gets arbitrary code execution inside a SYSTEM service process.

The result is a direct jump from standard-user code execution to NT AUTHORITY\SYSTEM.

From registry write to SYSTEM

I found the writable plugin state beneath these two registry paths:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\InstallService\State\PlugInList
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\InstallService\State\StaticPluginMap

On the vulnerable builds I tested, a standard user could create the missing subkeys or write values below them. PlugInList enables a named plugin; StaticPluginMap maps that same name to a DLL path.

For the proof of concept I registered a fresh plugin name and pointed it at a DLL in a user-writable location. The service only needs permission to read and load the file. I then reached the plugin loader through this public Windows Runtime API:

Windows.ApplicationModel.Store.Preview.InstallControl
  .AppInstallManager
  .SearchForAllUpdatesAsync()

SearchForAllUpdatesAsync() is an ordinary Store update call. The permissions mistake sits behind it: InstallService trusts plugin configuration written by the same user who can invoke the update workflow.

Standard user
    |
    | writes a fresh plugin name and DLL mapping
    v
HKLM InstallService state
    |
    | SearchForAllUpdatesAsync()
    v
InstallService running as SYSTEM
    |
    | loads mapped DLL inside svchost.exe
    v
Attacker-controlled code executes as NT AUTHORITY\SYSTEM

Reproducing it

My first proof used a small DLL that wrote marker files from the privileged process. I later recorded a fresh-VM reproduction that opens an interactive SYSTEM command prompt and writes a timestamped evidence trail.

I recorded that run on:

• Windows 11 25H2 build 26200.8037
• Fresh local standard user desktop-ud6iv88\user1
• Non-admin, medium-integrity starting token
• PowerShell launched without administrative elevation

I launched the runner from a non-elevated PowerShell window. It creates a unique plugin mapping, invokes the Store trigger, records the result, and removes the values it added. The command prompt opened by the DLL reports:

whoami /user
nt authority\system S-1-5-18

The run writes its evidence under:

C:\Users\Public\InstallServiceEopProof\<timestamp>

That directory contains the trigger and cleanup results together with process, token, session, and shell details collected by the DLL. The visible shell makes the privilege change easy to verify, but the underlying primitive is code execution inside the SYSTEM service process.

The public repository contains both versions of the proof:

Artifact	Purpose
exploit.ps1	Original marker-file proof, including setup, trigger, verification, and cleanup
canary.c	Source for the marker-writing DLL
interactive-system-shell-repro/	Fresh-VM interactive SYSTEM-shell proof
Run-InstallServiceInteractiveShell.ps1	Runner for the interactive proof
Cleanup-InstallServiceInteractiveShell.ps1	Removes values left by an interrupted run

Detection notes

The useful sequence is a low-privileged registry write followed by the privileged service loading the mapped DLL:

standard-user process writes InstallService plugin state
    -> InstallService reads the mapping
    -> the service host loads the mapped DLL as SYSTEM

The WinRT trigger is normal Windows behavior. A registry write or DLL load viewed on its own also misses the privilege-boundary change. Plugin names, DLL filenames, paths, and any child process are attacker-controlled and can all change. The files from my reproduction prove my test run; their names and hashes are not general indicators of exploitation.

Affected Windows releases

Microsoft's July 2026 CVE data lists the following affected version ranges. Install the applicable July 14, 2026 security update or a later cumulative update.

Product	Affected builds below
Windows 10 Version 1809	17763.9020
Windows 10 Version 21H2	19044.7548
Windows 10 Version 22H2	19045.7548
Windows 11 Version 24H2	26100.8875
Windows 11 Version 25H2	26200.8875
Windows 11 Version 26H1	28000.2269
Windows Server 2019, including Server Core	17763.9020
Windows Server 2022	20348.5386
Windows Server 2025, including Server Core	26100.33158

Build numbers and update packages vary by edition and architecture. Microsoft's advisory is the source I used for this table.

Disclosure timeline

Date	Event
June 3, 2026	Original InstallService report submitted to MSRC as VULN-192719
June 4, 2026	MSRC case 120271 opened
June 13, 2026	Fresh Windows 11 25H2 standard-user-to-SYSTEM reproduction recorded and supplied to MSRC
June 27, 2026	MSRC confirmed the submission was a duplicate of an earlier researcher report
July 14, 2026	Microsoft published CVE-2026-50343 and released security updates

Resources

• Microsoft Security Response Center advisory
• NadSec research repository and reproduction
• Interactive SYSTEM shell reproduction
• National Vulnerability Database record

Reproduction safety

The repository contains working elevation-of-privilege code. I tested it on isolated virtual machines. Use it only on a system you own or are authorized to test; production systems should receive Microsoft's July 2026 update or a later cumulative update.

---

Daniel Wade / NadSec - independently reported to MSRC as case 120271 / VULN-192719 and confirmed as a duplicate of an earlier researcher submission.

Daniel Wade - GitHub · Twitter/X · Bluesky · Mastodon · Medium