SysManager 1.52.98

What's new for you

This is a security hardening release. SysManager uses Windows' built-in winget to install, update and list apps. This update makes sure the app always runs the real, trusted winget that ships with Windows — never a look-alike that someone could try to slip into the folder you launched SysManager from. It matters most if you keep the portable app in a shared or easily-writable place (like Downloads) and run it as administrator. Nothing changes in how the app looks or works — the install, update and uninstall buttons behave exactly as before, just on a safer footing.

---

[1.52.98] - 2026-07-11

Fixed

• winget was launched by its bare name, which — despite the System32 path-pinning added for other tools — could still let an attacker-planted winget.exe run with the app's privileges (local privilege escalation). Every winget operation (Bulk Installer install/list/search, App Updates upgrade, Uninstaller list) routes through PowerShellRunner.RunProcessAsync("winget", …), which hardens the target via SystemPaths.ResolveSystemTool. But winget is not a System32 tool — it is an MSIX app whose real binary lives under %ProgramFiles%\WindowsApps\Microsoft.DesktopAppInstaller_*__8wekyb3d8bbwe\winget.exe, and whose only PATH entry is a per-user execution alias in the user-writable %LOCALAPPDATA%\Microsoft\WindowsApps. ResolveSystemTool probes only System32, so both probes missed and it returned the unrooted bare string "winget". Launched with UseShellExecute=false, Win32 CreateProcess searches the calling process's own load directory first — so a winget.exe planted next to SysManager's portable .exe (commonly run from a user-writable Downloads folder, sometimes elevated via the prominent "Run as administrator" buttons on the winget tabs) would execute with the app's rights. The previously-relied-on WorkingDirectory=System32 pin does not cover this (working dir is search item #2, the app-load dir is #1). Added SystemPaths.ResolveWinget, which resolves winget to the highest-versioned App Installer package under the admin-only-writable WindowsApps folder (verified by publisher hash and by actually containing winget.exe) and fails closed — if no trusted install is found it returns a rooted System32\winget.exe path (which normally doesn't exist, surfacing the same Win32Exception the callers already handle) rather than the plantable bare name. ResolveSystemTool now delegates winget/winget.exe to it. The per-user %LOCALAPPDATA% alias is deliberately never used for the (potentially elevated) launch. This closes the last winget binary-planting vector left open after the v1.52.91 (powershell) and v1.52.92 (Bulk Installer CWD) hardening.

---

Verify the download

Get-FileHash .\SysManager-v1.52.98.exe -Algorithm SHA256

Expected SHA256: 35AF5B9BAAB72EAA835F0F6F1F741CCE0537AF8BAEEAD4E1DEAF2080C237728D