Is Microsoft's DesktopAppInstaller (winget) Secure?

What DesktopAppInstaller actually is

Microsoft.DesktopAppInstaller is the package identifier for App Installer, the system component on Windows 10, Windows 11 and Windows Server 2025 that gives you winget, Microsoft's command line package manager. It is delivered and updated through the Microsoft Store, and it is what runs when you type winget install, winget upgrade or winget search in a terminal.

The client is open source. The code lives at github.com/microsoft/winget-cli, and the package manifests that tell winget where to download an installer from and what hash to expect live in a separate, community-maintained repository, winget-pkgs. Anyone can submit a manifest; Microsoft reviews submissions, but the installer itself still comes from the vendor's own server, not Microsoft's.

So 'is DesktopAppInstaller secure' is really two different questions. One is whether the winget client itself has had serious vulnerabilities. The other is whether installing software through winget is inherently safer than downloading it yourself. The honest answer to both is specific, not a yes or no.

• DesktopAppInstaller is the package name for App Installer, which ships the winget CLI.
• The client is open source at github.com/microsoft/winget-cli.
• Package manifests point to the vendor's own installer URL; winget does not host the files itself.

The one real vulnerability, and what it actually was

CVE-2021-43890 is a spoofing vulnerability, rated 7.1 (high) on CVSS 3.1, in the ms-appinstaller URI protocol handler, the mechanism that let a web link open App Installer directly and install an MSIX package without the user first downloading the file. Threat actors used that handler in phishing campaigns to distribute Emotet, Trickbot and BazarLoader, because launching an install through the protocol handler bypassed the warnings a browser download would normally trigger, including Microsoft Defender SmartScreen.

Microsoft's fix was to disable the ms-appinstaller protocol handler by default, which shipped in App Installer build 1.21.3421.0. In December 2023, Microsoft's threat intelligence team reported that the technique resurfaced: four financially motivated clusters it tracks as Storm-0569, Storm-1113, Sangria Tempest and Storm-1674 were still finding ways to trigger the protocol, including fake download pages mimicking Zoom, TeamViewer and AnyDesk, and Teams-based phishing that used JavaScript to invoke the handler directly.

As of today, there are no published GitHub security advisories for the winget-cli repository, and the protocol handler is still disabled by default in current builds. That history is the entire reason the question 'is DesktopAppInstaller secure' is a reasonable one to ask. It is also why the answer is narrower than either 'yes, it's from Microsoft' or 'no, it was hacked': one specific feature was abused, and it has been off by default for years.

• CVE-2021-43890: spoofing via the ms-appinstaller protocol handler, CVSS 7.1 high.
• Abused by Emotet, Trickbot and BazarLoader through phishing links, bypassing SmartScreen's usual download warning.
• Fixed by disabling the protocol handler by default, App Installer build 1.21.3421.0.
• Microsoft reported renewed abuse by four threat actor clusters in December 2023, using fake software pages and Teams phishing.

Forkbench has nothing to do with this

Forkbench is a desktop app for the Mac that runs AI coding agents in real terminals. It does not run on Windows, it does not call winget, and it has no relationship to DesktopAppInstaller, App Installer or the Windows package ecosystem at all. If this page reached you because you searched for something Forkbench-adjacent, the honest answer is that this is a Windows-only topic.

Windows and Linux support for Forkbench is in development, with no release date set. If you need to secure winget-based installs today, that work happens on the Windows machine itself, with the tools below, not with anything Forkbench ships.

• Forkbench runs on macOS only, today.
• Windows and Linux support is in development, with no committed date.
• Nothing in this page is a Forkbench feature; it is Windows's own mechanism.

Hardening winget installs an agent might run

If you are running a coding agent on Windows and letting it execute shell commands, including winget install calls, the risk is less about the vulnerability above, which is already mitigated by default, and more about what an agent can be told to install or configure without you reading every command first.

Keep App Installer updated through the Microsoft Store rather than a pinned older build, so the protocol handler stays disabled and any future fix lands automatically. Do not re-enable the ms-appinstaller protocol through the EnableMsAppInstallerProtocol policy unless you specifically operate a managed, internal MSIX distribution and understand you are reopening that attack surface.

Treat winget source add as a privileged action. winget can add arbitrary package repositories beyond the default Microsoft community one, and an agent that adds an untrusted source, then installs from it, is trusting whoever controls that source's manifests. If an agent needs to sideload a package outside the default source, verify it with winget hash against the hash the vendor publishes, and do not let the agent run with administrator privileges by default just to skip an elevation prompt.

Pin versions for anything your build depends on. An agent told to 'make sure everything is up to date' can trigger winget upgrade --all, which silently pulls whatever the latest manifest points to. That is a reproducibility problem as much as a security one: the package that passed review yesterday is not guaranteed to be the one installed tomorrow.

• Update App Installer through the Microsoft Store so the protocol handler stays disabled.
• Leave EnableMsAppInstallerProtocol off unless you run a managed internal MSIX catalog.
• Treat winget source add as privileged; an agent should not add arbitrary repositories unsupervised.
• Verify sideloaded packages with winget hash, and avoid running an agent's shell with standing admin rights.
• Pin versions rather than letting an agent run winget upgrade --all unsupervised.

Where real deployment control actually lives

For an organization deploying software at scale, winget run ad hoc from a terminal, by a person or an agent, is not the control plane. Microsoft Intune and winget's own DSC v3 (Desired State Configuration) resource commands exist specifically so that installs are declared in a policy and applied by managed infrastructure, not triggered interactively.

That distinction matters for the 'live deployment' half of this topic. A declared, version-pinned configuration that Intune applies is auditable and repeatable. A winget install typed into a terminal, whether by a developer or an agent working on their behalf, is neither, and it should be treated as a development-machine convenience rather than a production deployment method.

• Intune and winget's DSC v3 resources exist for managed, policy-driven deployment.
• An interactive winget command is a developer convenience, not a production deployment mechanism.
• Prefer a declared, version-pinned configuration over ad hoc install commands for anything that needs to be repeatable.

What this does not solve

A verified hash only proves the file was not altered in transit from the vendor's server to yours. It does not prove the vendor's own build process was not compromised, and it does not make a community-submitted manifest in winget-pkgs equivalent to a Microsoft-reviewed app in the Store. Trust still terminates at whoever built the installer.

Disabling the ms-appinstaller protocol handler closes the specific attack vector that CVE-2021-43890 and the 2023 campaigns used. It does not mean every package available through winget is safe to install unreviewed, and an agent with the ability to run arbitrary winget commands should still be treated as having the same reach as the person who launched it.

• A hash check proves integrity in transit, not that the upstream build itself is trustworthy.
• The protocol fix closes one historical attack path, not every risk in installing third-party software.