EOL WindowsAppRuntime versions persist silently as unpatched attack surface

Nobody has claimed this yet.

# Windows App SDK Runtime Sprawl: A Hidden Attack Surface

## Summary

A routine cleanup of unused Windows App SDK (WindowsAppRuntime) packages on a Windows 11 system revealed multiple outdated, end-of-life runtime versions persisting silently — installed as framework dependencies by common consumer applications. These orphaned runtimes represent an unpatched attack surface that Windows does not automatically remediate.

## Background

The Windows App SDK (formerly Project Reunion) is Microsoft's modern application framework, distributed as side-by-side runtime packages. Unlike traditional shared libraries, each major.minor version (1.2, 1.5, 1.6, 1.8) installs independently, and applications pin to a specific version at compile time.

The SDK was originally distributed as a Visual Studio extension (VSIX) through version 1.2. Starting with 1.3, Microsoft decoupled it into an independent NuGet package and standalone runtime installer — improving release agility but shifting lifecycle management responsibility to end users and app developers.

## Findings

An audit of a standard Windows 11 workstation revealed **10 WindowsAppRuntime packages** spanning four major.minor versions:

| Runtime Version | Release Date | Support Status | Dependent Applications |
|---|---|---|---|
| **1.2** | Nov 2022 | **End of life** | Spotify (Store) |
| **1.5** | Feb 2024 | **End of life** | None (orphaned) |
| **1.6** | Oct 2024 | Maintenance | Windows Widgets, ChatGPT Desktop |
| **1.8** | Sep 2025 | Active | Paint, Snipping Tool, etc |

Additionally, two system-provisioned CBS (Component Based Servicing) packages were present, marked as non-removable.

### Key Observations

1. **Orphaned runtimes persist indefinitely.** Version 1.5 had no dependent applications but remained installed. Windows does not perform automatic garbage collection of unused framework packages.

2. **End-of-life runtimes remain active.** Spotify's Store version pinned to SDK 1.2 — a runtime over three years old that no longer receives security servicing from Microsoft. Any vulnerability discovered in 1.2 will not be patched.

3. **Applications do not auto-migrate to newer runtimes.** Even with SDK 1.8 installed on the same system, Spotify continued loading 1.2 DLLs. Runtime versions are not backward-compatible across major.minor boundaries; the application developer must recompile and republish.

4. **Framework packages resist standard removal.** `Remove-AppxPackage` silently fails on framework packages while dependent applications exist. No error or warning is surfaced to the user.

5. **Store vs. standalone installers carry different risk profiles.** The Spotify Store app (MSIX) depends on WindowsAppRuntime 1.2. The standalone Win32 installer from spotify.com bundles its own dependencies and introduces no runtime sprawl.

## Security Implications

### Unpatched Runtime as Persistent Attack Surface

Microsoft's support policy covers only the latest two stable releases. As of March 2026, only SDK 1.6 and 1.8 receive security servicing. Any application pinned to 1.2, 1.3, 1.4, or 1.5 loads DLLs from a runtime that will never be patched again.

Since these runtimes reside in `C:\Program Files\WindowsApps\` and are loaded into the process space of user-facing applications, a vulnerability in an EOL runtime could be exploited through any app that depends on it.

### No Visibility Without Manual Audit

Windows provides no built-in mechanism to alert users that an installed runtime has reached end of life, or that an application is loading unserviced framework DLLs. The only discovery method is manual PowerShell interrogation:

```powershell
# List all WindowsAppRuntime packages
Get-AppxPackage *WindowsAppRuntime* | Select-Object Name, Version

# Map which apps depend on which runtime version
Get-AppxPackage -PackageTypeFilter Main | ForEach-Object {
$app = $_.Name
$_.Dependencies | Where-Object { $_.Name -like '*WindowsAppRuntime*' } |
ForEach-Object { [PSCustomObject]@{App=$app; Runtime=$_.Name} }
} | Format-Table -AutoSize
```

### Cross-Platform Parallel

This pattern mirrors known issues in the Linux ecosystem with Flatpak and Snap runtimes, where applications pin to specific platform versions (e.g., `org.gnome.Platform 44`) that accumulate over time. The mitigation there — `flatpak uninstall --unused` — has no Windows equivalent that runs automatically.

## Remediation

The following actions were taken to reduce the attack surface:

1. **Removed orphaned runtime 1.5** — no dependencies, immediate removal.
2. **Removed runtime 1.2** — after uninstalling the sole dependent (Spotify Store), replaced with the standalone Win32 installer which carries no runtime dependency.
3. **Removed runtime 1.6** — after removing Widgets (`MicrosoftWindows.Client.WebExperience`) and ChatGPT Desktop, the sole dependents.
4. **Removed other non-essential components** - dependencies not required for core system functionality.
5. **Retained runtime 1.8** — required by core Windows apps (Paint, Snipping Tool), currently under active security servicing.

**Post-remediation state:** Only SDK 1.8 (actively patched) and two non-removable CBS system packages remain.

## Recommendations

- **Audit WindowsAppRuntime versions periodically** using the PowerShell commands above.
- **Prefer standalone Win32 installers** over Store/MSIX versions when available, to avoid introducing additional runtime dependencies.
- **Remove orphaned runtimes** after uninstalling applications — Windows will not do this automatically.
- **Monitor Microsoft's SDK lifecycle page** to identify when installed runtimes reach end of life.
- **Enterprise administrators** should consider DISM or provisioning policies to prevent EOL runtime re-provisioning via Windows Update.

## Conclusion

The Windows App SDK's side-by-side versioning model prioritizes application stability over security hygiene. While patching occurs within supported major.minor versions, the framework's design guarantees that outdated runtimes accumulate silently on consumer systems — loaded by applications whose developers have not rebuilt against current SDKs. Without proactive auditing, these become long-lived, invisible attack surfaces.

---

*Audit conducted March 25, 2026 on Windows 11. Findings apply to Windows App SDK versions 1.2 through 1.8.*

The issue names no repository files, tests, or entry points. Start by reviewing the PowerShell audit commands and the Windows App SDK lifecycle concerns described here; the work is not ready to start until a specific repository change and completion criteria are defined.

Written by the indexing model from the issue text.