← All posts · November 8, 2026 · By Brian Vitko

Windows Store app CVEs: one PC can hold several versions of Paint. Check, update and remove every copy

Last week’s Paint post was about one Store app whose fix wasn’t in the Store yet. The fix is there now, Paint 11.2609.401.0, and since November 7 the CVE record lists Paint as affected below it. NVD was still “Undergoing Analysis” when I checked on November 8, with no version data of its own, so a scanner that goes by NVD has nothing to compare Paint against.

Paint isn’t the only one. Microsoft’s security data lists fixes that ship as Store app updates for 16 packages, from Notepad and Terminal to the codec extensions. None of those fixes come through Windows Update or WSUS. They come when the Store updates the app, and every account on a PC has its own copy of each one.

On two Windows 11 Enterprise 25H2 lab VMs I checked, updated, removed and reinstalled Store apps, and three things didn’t go the way I expected. With the Store turned off by policy, the update scan reported success after 11 minutes, and not one app had updated. Removing an app for every account also removed the copy new profiles start from. And winget couldn’t reinstall Solitaire.

Store app fixes Microsoft has published

From Microsoft’s security update data. Several apps have one fixed version per Windows version, so check the row for the machine you’re looking at.

The same data has Store fixes for PC Manager, Xbox Gaming Services, Power Apps and the Windows App client.

Why one PC has several versions

A Store app is installed per account. Each account’s copy updates when that account’s Store client syncs, so an account that hasn’t signed in for a while keeps the version it had. New profiles start from the provisioned copy in the Windows image, which can be older again.

Across our own lab machines Paint showed up in four versions on eight computers, and one laptop had two versions of Paint installed at the same time. A test machine that last checked in on September 18 still had Paint 11.2412.295.0, HEVC Video Extensions 2.2.33.0 and HEIF 1.2.3.0.

Check one machine

From an elevated PowerShell, every Store app for every account plus the provisioned copy:

$a = 'x64'; if ($env:PROCESSOR_ARCHITECTURE -eq 'ARM64') { $a = 'arm64' }
Get-AppxPackage -AllUsers | Where-Object { -not $_.IsFramework } | ForEach-Object {
    $p = $_; $p.PackageUserInformation | ForEach-Object {
        [pscustomobject]@{ App = $p.Name; Version = [string]$p.Version; Account = [string]$_.UserSecurityId.Username; State = [string]$_.InstallState } } }
Get-AppxProvisionedPackage -Online | ForEach-Object {
    $v = @([string]$_.Version); $m = [Environment]::ExpandEnvironmentVariables([string]$_.InstallLocation)
    if ($m -match 'AppxBundleManifest\.xml$' -and (Test-Path -LiteralPath $m)) {
        $b = @(([xml](Get-Content -LiteralPath $m -Raw)).Bundle.Packages.Package |
            Where-Object { $_.Type -eq 'application' -and ($_.Architecture -eq $a -or $_.Architecture -eq 'neutral') } | ForEach-Object { [string]$_.Version })
        if ($b.Count) { $v = $b } }
    $n = [string]$_.DisplayName; $v | ForEach-Object { [pscustomobject]@{ App = $n; Version = $_; Account = '(provisioned)'; State = 'Provisioned' } } }

Don’t trust Get-AppxProvisionedPackage’s version on its own. It’s the version of the bundle, not the app inside it. For Paint they’re the same number. For Terminal the bundle says 3001.24.12741.0 and the app is 1.24.12741.0, which is why the command reads the bundle manifest. My first version of RFF’s inventory read that number and reported that new profiles on one lab VM would start on Microsoft News 4.7.6002.0, the bundle’s version.

A “Staged” row is a copy that registers at that account’s next sign-in. After an update scan you may also see rows for NT AUTHORITY\SYSTEM. The scan registers some apps for SYSTEM itself, so skip those. WetPaint compares the output against the fixed versions above in your browser, if you’d rather not do it by eye.

Update every copy

Intune and other MDMs update Store apps through the UpdateScanMethod on MDM_EnterpriseModernAppManagement_AppManagement01. On one machine it’s two lines:

$am = Get-CimInstance -Namespace 'root\cimv2\mdm\dmmap' -ClassName 'MDM_EnterpriseModernAppManagement_AppManagement01'
Invoke-CimMethod -InputObject $am -MethodName UpdateScanMethod

Run it as SYSTEM. Microsoft’s WMI Bridge documentation says methods on these classes have to run under the local system account, and gives psexec.exe -i -s as the way to get one.

I tested it on a Windows 11 25H2 lab VM that had been off since late October. Paint was 11.2605.81.0 for three accounts (the one signed in, the local Administrator, and one whose name no longer resolves) and for the provisioned copy. I ran the scan three times with different Store policies:

The scan reports success with the Store turned off. Don’t treat the return code as “updated”. Check the versions afterwards, and wait a while before you do. In the third run apps kept arriving for several minutes after the call returned, so RFF’s update job watches for up to 12 minutes. The Store policies are worth a look before you start:

Get-ItemProperty 'HKLM:\SOFTWARE\Policies\Microsoft\WindowsStore' -ErrorAction SilentlyContinue |
    Select-Object RemoveWindowsStore, AutoDownload

When an app did update, the signed-in account got it installed. Every other account got it staged, and Windows registers it at their next sign-in. The provisioned copy updated too, and the old version was gone from the machine. I didn’t test RemoveWindowsStore = 1 on its own, so I can’t say which of the two stops it. Check for both.

I also tried winget. winget upgrade --source msstore --all run as SYSTEM finished with exit code 0 and “No installed package found matching input criteria”, because SYSTEM has no Store apps of its own.

Remove an app for every account

Removing an app only for the signed-in user leaves every other account’s copy, and the next new profile gets it again from the provisioned copy. As an admin, for one app:

$name = 'Microsoft.MicrosoftSolitaireCollection'
Get-AppxPackage -AllUsers -Name $name | ForEach-Object { Remove-AppxPackage -Package $_.PackageFullName -AllUsers }
Get-AppxProvisionedPackage -Online | Where-Object DisplayName -eq $name | Remove-AppxProvisionedPackage -Online
# Both of these should now return nothing
Get-AppxPackage -AllUsers -Name $name
Get-AppxProvisionedPackage -Online | Where-Object DisplayName -eq $name

On the second lab VM, also Windows 11 25H2, that removed Solitaire for two accounts and the local Administrator’s staged copy in one call. On 25H2, Remove-AppxPackage -AllUsers took the provisioned copy with it. My first script read the provisioned list before removing anything, then tried to deprovision the copy that was already gone and failed with “The system cannot find the path specified”. The removal had worked. Read the provisioned list after the per-account removal, as above, and check both lists at the end.

Windows also recorded the removal in the registry: the app’s family name under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Appx\AppxAllUserStore\Deprovisioned, and an EndOfLife entry for each account that had it.

Some packages shouldn’t be removed at all. Get-AppxPackage marks the frameworks other apps depend on (IsFramework) and the ones Windows won’t let go (NonRemovable). Leave the Store and App Installer too, since the update scan gets its updates from the Store.

On Windows 11 Enterprise and Education 25H2 there’s also a policy for this, “Remove default Microsoft Store packages from the system” (Computer Configuration\Administrative Templates\Windows Components\App Package Deployment, or the RemoveDefaultMicrosoftStorePackages CSP). It covers a fixed list of 24 built-in apps and isn’t available on Pro. I didn’t test it.

Put one back

Store apps install per account and SYSTEM has none, so a reinstall has to run as the user. First, get the Store ID from the app’s family name:

$pfn = 'Microsoft.Windows.Photos_8wekyb3d8bbwe'
$u = "https://displaycatalog.mp.microsoft.com/v7.0/products/lookup?alternateId=PackageFamilyName&value=$pfn&market=US&languages=en-us&fieldsTemplate=details"
(Invoke-RestMethod $u -UseBasicParsing).Products[0].ProductId

That prints 9WZDNCRFJBH4. Then, in the user’s session:

winget install --id 9WZDNCRFJBH4 --source msstore --accept-source-agreements --accept-package-agreements

Photos came back for the signed-in account, 2608.1401.18.0. It comes back for that account only. The other accounts and the provisioned copy stay removed.

Right after a removal, a reinstalled copy reads “Installed(pending removal)”. I restarted the VM, the account signed back in, and Photos read “Installed” and stayed, so the flag was left over from the removal. My own reinstall script first compared the state to exactly “Installed” and reported a failure on a reinstall that had worked.

winget’s Store source didn’t have Solitaire. winget show --id 9WZDNCRFHWD2 --source msstore and winget search Solitaire --source msstore both returned “No package found matching input criteria” on winget 1.29.380, while winget show found Photos (9WZDNCRFJBH4) and Paint (9PCFS5B6T72H). Solitaire is the only game I tried, so I can’t say whether that goes for every game. The Store app still lists it, so for now that’s how a user gets it back.

What to do

1. Find every copy below the fixed version, per account and the provisioned copy.
2. Check the Store policies on those machines (RemoveWindowsStore, AutoDownload) before you count on the update scan.
3. Run the update scan as SYSTEM and check the versions about 10 minutes later. Accounts that are signed out stay staged until they sign in, so a shared PC can show the old version for a while after the update.
4. Remove apps nobody needs for every account and from the provisioned copy, and check that both lists come back empty.
5. Know the way back before you remove anything. winget from the Store source, run in the user’s session, worked for Photos; Solitaire needed the Store app.

Doing it with RFF

RFF reads Store apps for every account and the provisioned copy (from the bundle manifest) and matches them against Microsoft’s fixed versions rather than NVD’s, so the Paint CVE shows up as a finding with the package and the accounts that still have the old copy. The Software Sprawl page has a Microsoft Store apps section with each app’s versions per account across the fleet. From it, “Update Store apps” runs the update scan as SYSTEM on the computers that are behind and reports per app who got the update and who gets it at their next sign-in, refusing with a reason when the Store is turned off by policy. “Remove” takes an app off every computer that has it, for every account and the provisioned copy, with a dry run first if you want one, and a “must not be present” check can do the removal on its own. Reinstall a Microsoft Store App in the Script Library puts one back for the signed-in user. We ran all of it on the two lab VMs above through the console.

RFF is free for your first 100 endpoints: getrff.com.

Sources

• Microsoft Security Update Guide, CVE-2026-83844: Paint, fixed build 11.2609.401.0, Store delivery
• MSRC security update data (CVRF API): the Store app fixed versions in the table, month by month
• CVE record, CVE-2026-83844: affected below 11.2609.401.0 since November 7
• NVD, CVE-2026-83844: Undergoing Analysis, no CPE configuration (checked November 8)
• EnterpriseModernAppManagement CSP: the update scan MDMs use
• Using PowerShell scripting with the WMI Bridge Provider: methods run under the local system account
• Policy-based removal of pre-installed Microsoft Store apps: the 25H2 policy, Enterprise and Education only, 24 apps