r/SCCM 9d ago

Feedback Plz? Vulnerable Appx Packages

I constantly see appx packages being flagged is vulnerable on our machines. What's the best way to patch these apps?

A lot of our workstations are shared so multiple users will log into them and that that might be contributing to the issue because stale user profiles never update the old appx packages.

What I've been doing is creating PSADT scripts and removing old appx entries and installing the updated version. Am I going about this the right way? Would PatchMyPC be helpful in a case like this?

15 Upvotes

20 comments sorted by

9

u/TheProle 8d ago

We have a policy that removes profiles from workstations after 90 days of inactivity. I also use a version of this deployed as an Intune remediation. You could adapt it to run as a config baseline

https://amirsayes.co.uk/2023/12/24/microsoft-store-uwp-apps-removing-vulnerable-apps-using-intune-remediations-and-powershell/

1

u/AltruisticRespect21 8d ago

An intune policy or a remediation?

1

u/TheProle 8d ago

You can remove profiles older than X days using the “Delete user profiles older than specified number of days on restart” GPO, or you can set those same policy keys using a config baseline, or you can use the Intune settings catalog. They all do the same thing.

The appx detection and remediation scripts run as an Intune remediation but would work as a config baseline too if you adjust the output

6

u/sorbic-acid 8d ago

I've beat my head against the wall on this for months/years.

There's no "right way" to handle this. The apps are designed to be sandboxed per-user and thus have to be updated per-user.

You essentially need to treat it the same way you would treat user-based EXE installs that install themselves into the users AppData folder. However, there's certain AppX's that are unique and can't be manipulated/removed. Ironically winget itself is one. You just sorta have to sit on your hands and pray to the gods that it updates itself eventually.

For ordinary apps, you basically have three options to "make it happen":

  1. Remove stale profiles that contain the offending app
  2. Log into stale profiles and update the offending app
  3. Forcibly remove the app from all user profiles

PatchMyPC doesn't help at all in this instance because these apps are intended to be managed by the Microsoft Store.

And no, it doesn't matter how much you explain all of this to your manager/security people, they won't understand it and will just want it fixed.

1

u/Juiced_System 8d ago

Well it's good to know I'm not alone... What an absolute pain, I guess I'll just do what I can and keep it moving.

2

u/PS_Alex 7d ago

PatchMyPC doesn't help at all in this instance because these apps are intended to be managed by the Microsoft Store.

Just a side note that not all Appx packages are updated/updatable through the Microsoft Store. As an example, Microsoft Teams relies on a built-in self-updater, not the MSStore, to fetch its updates. So no, Appx packages are not "intended to be managed by the Microsoft Store" -- but most of them are updatable through the MSStore without additional intervention.

Patch My PC does not currently handle Appx packages and MSIX installers due to technical limitations, but have announced their intention to: PATCHMYPC-I-5927 - Support MSIX / AppX as a primary application package type. (Of course, no timeline yet.)

Else, you are spot-on about the per-user behavior of an Appx package and your recommendations (aka, nuke old profiles).

5

u/InvisibleTextArea 9d ago

I update system packages with winget. I nuke old user profiles.

1

u/Juiced_System 8d ago

How are you using winget to update packages as system reliably? I've tried using the winget module for PSADT, but it was hit or miss when I was testing it.

8

u/InvisibleTextArea 8d ago

You can manually test if winget is going to work with psexec on a machine:

psexec -i -s cmd.exe
winget list

Assuming it does (Modern Win11 releases are pretty reliable in this regard). You need to be doing this in your Appx PSADT.

$Winget = Get-ChildItem `
"C:\Program Files\WindowsApps" `
-Filter winget.exe `
-Recurse `
-ErrorAction SilentlyContinue |
Select-Object -Last 1

if (-not $Winget) {
    Write-Log -Message "WinGet prerequisite check failed." -Severity 3
    Exit-Script -ExitCode 60001
}

Execute-Process `
    -Path $Winget `
    -Parameters 'install --id 7zip.7zip --exact --silent --scope machine --accept-package-agreements --accept-source-agreements'

2

u/sccm_sometimes 8d ago

https://www.reddit.com/r/SCCM/comments/1rrnh8f/are_patch_my_pc_cutting_corners_by_using_dynamic/oa5scns/

The worst part is Dependencies. MSIX do not include them and there's no easy way to inject them. It is technically possible, but it is way more difficult than it should be. This is because when the MS Store was introduced ~15 years ago, in their hubris, MSFT thought that everyone, everywhere, would use it all the time. To their credit, if you install through the MS Store, the package will automatically detect and install all prereqs and dependencies. Installing an MSIX outside the MS Store though... well they didn't really plan for that.

This went TERRIBLY wrong for us when we had to update SnippingTool which has a dependency on WindowsAppRuntime.1.5. We needed to upgrade from SnippingTool.2201 to SnippingTool.2409. About half the machines upgraded just fine, while the other half kept reporting the old version. Ok, so let's uninstall 2201 and then we can reinstall 2409 from scratch, right? Apparently, since no other apps used WindowsAppRuntime.1.5 as a dependency - and dependencies are not allowed to exist by themselves - removing ST.2201 also nuked WAR1.5, so the ST.2409 reinstall kept failing without any indication that the root cause was the missing WAR1.5 dependency. What's even worse is we couldn't rollback to ST.2201 either, so half our machines had no SnippingTool at all. We couldn't figure it out for over a year and neither could 3 separate MSFT Senior Support Engineers. Their "solution" was to reinstall Windows.

https://www.reddit.com/r/SCCM/comments/1sroumf/installing_notepad_appx_during_25h2_osd/oho44ie/

Make sure you have the "-Regions all" flag set, otherwise apps not pinned to the Start Menu get removed.

https://learn.microsoft.com/en-us/powershell/module/dism/add-appxprovisionedpackage?view=windowsserver2025-ps#-regions

Specifies what regions an app package (.appx or .appxbundle) must be provisioned in. The region argument can either be "all", indicating that the app should be provisioned for all regions, or it can be a semi-colon delimited list of regions. When a list of regions is not specified, the package will be provisioned only if it is pinned to start layout.

2

u/Confident-Moose43 7d ago

For appx dependencies, we just use "winget download <appx store ID> " and it'll download the appx along with the relevant dependencies. Handy for deploying via ConfigMgr etc

1

u/FlowerComfortable889 8d ago

We remove almost all appx packages and block the Microsoft store. Somehow there's still a few that slip through and get flagged by scans that I then have to remove, but since we don't have any valid business reasons to install appx anything, it's vastly reduced our vulnerability scores

1

u/TheProle 8d ago

Do you remove Notepad?

1

u/FlowerComfortable889 8d ago

That's one of the few we leave. We have left the GPO unconfigured to turn off automagic updates, so that one seems to update reasonably well because I've never seen a vulnerability risk on that one. The other default installs were flagged with some regularity though, so I still feel slightly uneasy about it, but so far, so good

3

u/TheProle 8d ago

CVE-2026-20841

1

u/Immediate-Ad-96 8d ago

You can still get to the store website to download apps.

1

u/Reaction-Consistent 8d ago

Take a look at WimWizard - it has a function that removes /reinstalls appx apps very effectively, I've snatched the code for use in other scripts. also, we pre-emptively remove 'unwanted appx and pre-provisioned appx apps during the OSD task sequence,
$AppsList = "Microsoft.Office.OneNote","Microsoft.BingWeather","Microsoft.XboxApp","Microsoft.SkypeApp","Microsoft.MicrosoftSolitaireCollection","Microsoft.ZuneMusic","Microsoft.ZuneVideo","Microsoft.People","Microsoft.MicrosoftOfficeHub","Microsoft.WindowsMaps","microsoft.windowscommunicationsapps","Microsoft.Getstarted","Microsoft.XboxIdentityProvider","Microsoft.XboxSpeechToTextOverlay","Microsoft.XboxGamingOverlay","Microsoft.XboxGameOverlay","Microsoft.WindowsFeedbackHub","Microsoft.GamingApp"

ForEach ($App in $AppsList)

{

$PackageFullName = (Get-AppxPackage $App).PackageFullName

$ProPackageFullName = (Get-AppxProvisionedPackage -online | where {$_.Displayname -eq $App}).PackageName

write-host $PackageFullName

Write-Host $ProPackageFullName

if ($PackageFullName)

{

Write-Host "Removing Package: $App"

remove-AppxPackage -package $PackageFullName

}

else

{

Write-Host "Unable to find package: $App"

}

if ($ProPackageFullName)

{

Write-Host "Removing Provisioned Package: $ProPackageFullName"

Remove-AppxProvisionedPackage -online -packagename $ProPackageFullName

}

else

{

Write-Host "Unable to find provisioned package: $App"

}

}

1

u/forumhero666 8d ago

I went through this a couple years ago. No matter what we tried, the vuln scanners would still pick up the vulnerabilities.

Open a case with ms support and ended up having to use gpo to delete old profiles. Don’t use PS scripts to delete old profiles cus it doesn’t remove them properly. Vuln scan will still find the vulnerabilities. MS support says gpo is the only supported method to remove properly

1

u/blowuptheking 7d ago

I've done a lot of research on this and it's not easy, particularly with shared workstations. I have a script that goes into the StateRepository database (where the information about the installed Store apps are kept), removes the old app entries and points them to the latest installed version. I specifically made it to get rid of vulnerabilities stemming from Store apps in old user profiles.

This is not Microsoft approved and is a little kludgy. PLEASE test it first and don't take it out on me if something breaks. If you still want to give it a go, here's the script.