CVE-2026-73250

This CVE exposes a collision between NSIS variable syntax and PowerShell subexpression syntax that has been lurking in installer toolchains for over a decade. The root cause is straightforward: NSIS uses `$()` for its own variable expansion, and PowerShell uses the same syntax for command substitution. When a user selects an installation directory containing a string like `$(malicious command)`, and that path gets passed to PowerShell through an NSIS script, the result is arbitrary command execution — not because the developers were negligent, but because two independently reasonable design choices collided in an unvalidated context. The CVSS 5.4 score badly understates the risk. The vulnerable code runs during MSIX registration in the installer's elevated context — typically as SYSTEM on a freshly-provisioned Windows system. The blast radius is not "medium" but "whatever administrative privileges the installer holds." A user need not be sophisticated; they only need to name a directory `$(whoami > C:pwned.txt)` and the installer will execute that command at SYSTEM privilege. The 8.9.7 patch likely sanitizes the `Add-AppxPackage` call path, but the critical question is whether it addresses all PowerShell invocations in the NSIS script. If one code path was vulnerable to `$INSTDIR` injection, the same variable likely appears in other command contexts: registry operations, uninstaller hooks, file operations. Audit the entire installer script for every instance where NSIS variables are interpolated into PowerShell `-Command` strings, not just the MSIX registration path. This is not an isolated flaw. The same NSIS-PowerShell composition pattern has produced CVEs in other projects over the past decade. The escape mechanisms in NSIS — `StrRep`, proper quoting, `!include` guards — have existed for years but are documented as developer conveniences rather than security-critical interfaces. NSIS documentation does not warn that `$()` variable expansion becomes an injection vector when outputs are consumed by other command interpreters. Until installer framework documentation explicitly surfaces cross-context injection risks, this class of vulnerability will continue to propagate across the toolchain.

Reviewed through automated stages and approved by a human before publication.