Add CVE-2026-50343 (InstallService) check

[KenjiEndo15]

Hi!
I wrote this PR for testing CVE-2026-50343.

In Brief

InstallService is a Windows service that manages Microsoft Store app installations and updates. The service can load plugins and execute them. To perform these actions, it reads registry keys:

• PluginInList: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\InstallService\State\PlugInList
  List of plugins to load

• StaticPluginMap: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\InstallService\State\StaticPluginMap
  Where each plugin's DLL is

When InstallService starts or checks for updates, it:

1. Reads the registry keys (they may not exist by default.)
2. For each plugin listed, loads the DLL from the path specified
3. Runs that DLL code as SYSTEM

PrivescCheck

I found verifying write permissions via ACL analysis complex. Instead, the check attempts to create the required subkeys (PlugInList and StaticPluginMap) under HKLM\...\InstallService\State​ and write test values to them. If successful, the vulnerability exists. Any subkeys or entries created during testing are removed afterward to leave the system unchanged.

Windows Build

Researchers say the CVE affects Windows 11. That said, I was able to write to the relevant subkeys on Windows 10, but the exploit did not succeed. This makes me wonder whether there might be a way to adapt the exploit so that the CVE could also be triggered on Windows 10.

References

• https://blog.calif.io/p/dark-elevator-windows-install-service
• https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2026-50343

[itm4n]

Hello KenjiEndo15,

I have a couple of issues with this kind of check.

CVE Checks

I generally avoid implementing CVE checks. The reason is if I start doing that, then I will have to implement dozens of checks every month. What I do check instead is whether Windows is up-to-date (i.e. security updates have been applied within the last 30 days).

The only exceptions may be when issues persist after a patch has been applied. Think of HiveNightmare for instance. This is not the case here, a normal user will get an access denied error when attempting to create the required registry keys on an up-to-date machine.

System Modification

I also avoid system modifications, even if they're temporary and things are cleaned up afterwards. In the early versions of the script, I did go that route as well occasionally because, like you said, DACL-based checks can be tricky, but I eventually reconsidered this choice.

There are indeed two main issues. First, the execution of the script could be aborted at any moment, for whatever reason, and therefore the keys may never get deleted, thus leaving the machine vulnerable potentially. Second, this kind of registry operation could be monitored by EDR, and interpreted as an exploitation attempt, thus rasing an alert, and also killing the process, which would be a cause for the issue I mentioned previously by the way.

Widows 10

An argument you could oppose to this reasoning is the case of unsupported Windows 10 versions that may not receive this security update, as you alluded to, if I understood your last point correctly. In that case, I would answer that the issue is the fact that the machine is running an unsupported version of Windows, not that it is vulnerable to a particular CVE.

Areas for Improvement

This particular CVE stems from a misconfigured registry key's DACL. Any user with the well-known INTERACTIVE identity ends up with the "Create Subkey" right on a "system" key, which then enables them to manipulate a service running in a privileged context in some way. This is a common pattern I've seen many times.

It would be super interesting to have a more generic check that can report this kind of weaknesses, rather than checking a particular instance. I've already thought about this, but there are several issues. Enumerating the entire registry would take too much time. Also, how to tell the difference between an exploitable key and a non-exploitable key in a fully automated way? That being said, I'm not asking you to solve this problem, to be clear. :) It's just a random thought.

Conclusion

I cannot merge this pull request as it is. I hope you understand my stance. I do want to thank you for your contribution and your writeup, which helped me quickly grasp the issue. Please get back to me if you think I missed something.