Cannot override installer hash as admin. Even if EnableLua = 0 (UAC OFF)

Cannot override installer hash when running as admin, even if EnableLua = 0 (UAC OFF)

I want to install the package. Please let me install the package.

Steps to reproduce

Try to install a package with a mismatched hash while running as administrator.

Expected behavior

It allows you to install.

Actual behavior

It does not allow you to install.

Edited:

This feature is to track the work to have an administrator required setting to enable the ability to override a hash mismatch.
It would be something like winget settings --enable ignore-security-hash-argument.
The group policy on "--force" will need to be evaluated and potentially modified or a new one added for this use case.
There should be a separate argument required for "--ignore-security-hash" rather than "--force" which would work in both user and admin modes if the setting is enabled.

Did you run it with --force?

Marco A. Peraza (@MarcoPeraza)

Marco A. Peraza (@MarcoPeraza) were you able to use --force?

Yes, when I use --force I get the following error still: "Installer hash does not match; this cannot be overridden when running as admin"

Note that when using an admin account and running Windows with EnableLua=0, all applications run with full privileges. This turns UAC off. It would be nice if the hash override would remain available to users running with this configuration. Fwiw, I have never encountered a feature in any Microsoft product that did not work with this configuration, except as a bug.

Hi, is there any reason why this feature is disabled at all for users running as admin? This seems to be upside-down. Usually, running as administrator gives you more privileges, not less.

I also just want to reiterate that when you turn UAC off on a machine, it's impossible to not run as admin, so the hash override feature becomes completely unavailable.

If you are running as administrator and the installer on the other end is compromised, it can do whatever it wants to your system once winget runs it. If you aren't running as administrator and do --force, UAC should pop up and say "hey, this application wasn't signed by a vendor. run anyway?"

It should be configurable via winget settings, but by default winget shouldn't be allowing people to easily run unverified binaries (since if there is a hash mismatch, it means that the version that winget downloaded wasn't verified through the community repo and therefore could be a virus or something).

I also just want to reiterate that when you turn UAC off on a machine, it's impossible to not run as admin, so the hash override feature becomes completely unavailable.

This is good default behavior. The only reason hash overrides are really needed right now are because the manifest update time is so long, but once the bots get better and we have other repos to choose from this shouldn't be much of an issue.

We're looking at several options to deal with this scenario. There have been several concerns about having command-line overrides that could potentially result in malicious code getting installed by the Windows Package Manager (eg. copy-paste this command from some "bad actor").

A few options have been suggested:

Have a setting requirement to enable the capability (enables a Group Policy to block behavior by IT administrators).
Change the value to something other than --force (something more akin to --IgnoreSecuritysha256).

Generally, it is preferred not to ignore security checks. Are there any other suggestions here?

Not sure what you mean. The publisher of the app in the Winget repo is responsible for delivering both the software and the manifest, I'm not referring to the hash of Winget itself. It's the responsibility of the software publisher to provide a correct and up to date manifest along with the actual installer. If the installer cannot be verified, it has no business being on a software repository that is used by IT administrators. We might as well go back to manually taking care of installers and ignoring Winget entirely.

I'd fire an admin on the spot if I saw them pushing 'winget upgrade --all --force' on thousands of computers if --force would bypass verification checks.

I don't agree, and I think you are using an extreme case as an example that we are not talking about. No one with a healthy brain would do widget upgrade --all --force, and every example in this thread was about one concrete app installation/upgrade.

The override is useful when some concrete app upgrade fails (during winget upgrade --all for example) because the package contains an invalid hash.

In the world of all packages being updated, this would not be necessary, and I would agree that the package author should provide a proper hash. But the reality of the winget package repository is that many packages are outdated. And because many apps do not use versioned installer file names (i.e. URL stays the same when a new app version is published), the hash gets outdated because the executable stated in the manifest was updated in the remote location by the app developer while the corresponding package was not. Many packages are "maintained" by volunteers, not the app developers directly.

You might NEED to install the new app version, maybe because the new app version contains important security updates, important bug fixes, or whatever.

In that case, you want to tell Winget, "Hey, I know what I'm doing, and I'm ok with the risks involved," because the risk associated with using the old app version may be bigger for you. In that case, winget trying to be "secure" is not actually secure.

In that case, you are screwed. And what will you do in such a situation? You will probably go to the app homepage, download the installer ANYWAY, and install it manually if you evaluate the risks involved. So the result is the same.

chocolatey has a simple solution to this - it lets you provide your own hash via --checksum64 or simply ignore the hash via --ignore-checksums - simple, effective, and useful. I think it's actually more secure because by using --checksum64, you can easily use a valid hash provided by the app homepage, so the installation of the new version is secure. When Winget does not provide that option, the user might ignore the checksum validation completely and install it right away, fingers crossed.

I think this is the classic example of an application trying to protect users from themselves, which, in the case of an application for administrators, does not make sense and is only annoying and can backfire when it does not provide a workaround.

Ooooh I love that chocolatey feature of being able to provide a checksum.

…

On Mon, Jan 15, 2024, 13:07 Pavel Trka ***@***.***> wrote: Not sure what you mean. The publisher of the app in the Winget repo is responsible for delivering both the software and the manifest, I'm not referring to the hash of Winget itself. It's the responsibility of the software publisher to provide a correct and up to date manifest along with the actual installer. If the installer cannot be verified, it has no business being on a software repository that is used by IT administrators. We might as well go back to manually taking care of installers and ignoring Winget entirely. I'd fire an admin on the spot if I saw them pushing 'winget upgrade --all --force' on thousands of computers if --force would bypass verification checks. I don't agree, and I think you are using an extreme case as an example that we are not talking about. No one with a healthy brain would do widget upgrade --all --force, and every example in this thread was about one concrete app installation/upgrade. The override is useful when some concrete app upgrade fails (during winget upgrade --all for example) because the package contains an invalid hash. In the world of all packages being updated, this would not be necessary, and I would agree that the package author should provide a proper hash. But the reality of the winget package repository is that many packages are outdated. And because many apps do not use versioned installer file names (i.e. URL stays the same when a new app version is published), the hash gets outdated because the executable stated in the manifest was updated in the remote location by the app developer while the corresponding package was not. Many packages are "maintained" by volunteers, not the app developers directly. You might NEED to install the new app version, maybe because the new app version contains important security updates, important bug fixes, or whatever. In that case, you want to tell Winget, "Hey, I know what I'm doing, and I'm ok with the risks involved," because the risk associated with using the old app version may be bigger for you. In that case, winget trying to be "secure" is not actually secure. In that case, you are screwed. And what will you do in such a situation? You will probably go to the app homepage, download the installer ANYWAY, and install it manually if you evaluate the risks involved. So the result is the same. chocolatey has a simple solution to this - it lets you provide your own hash via --checksum64 or simply ignore the hash via --ignore-checksums - simple, effective, and useful. I think it's actually more secure because by using --checksum64, you can easily use a valid hash provided by the app homepage, so the installation of the new version is secure. When Winget does not provide that option, the user might ignore the checksum validation completely and install it right away, fingers crossed. I think this is the classic example of an application trying to protect users from themselves, which, in the case of an application for administrators, does not make sense and is only annoying and can backfire when it does not provide a workaround. — Reply to this email directly, view it on GitHub <#715 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AP5N2PZAPMGMYVGZ5OTCHW3YOULYHAVCNFSM4WP7F3A2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBZGIYDINJTGIYQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

Solved on Win11 by two steps on Powershell:
winget settings --enable InstallerHashOverride as admin
winget install NirCmd --ignore-security-hash as normal user

A new attempt to automation without interactive popups. These commands must be run in powershell as an administrator:

$id = "Google.Chrome"
winget settings --enable InstallerHashOverride
$env:SEE_MASK_NOZONECHECKS = 1
runas /trustlevel:0x20000 /machine:amd64 "winget install --id=$id --accept-package-agreements --accept-source-agreements --ignore-security-hash --exact --silent"

If anyone can test it with packages that don't have a matching hash I would appreciate it.

dennish78

Not sure what's up ⬆️ with all those thumbs ⬇️.
Isn't it obvious to everyone that we should be in charge of our own computers?

There are many examples of why one should be able to install non conformant or hashed packages:

A lot of security researchers may need to install malware on purpose.
A lot of people are porting SW from old machines and Win OS's with outdated certs and SW.
ALL of what dennish78 email quote said.
I am testing something during development, and just can't be bothered with fixing hashes for installing my module for something that may be later part of another larger project.
NOBODY should have to resort to Windows OS hacking to be able to run whatever we want on it. Having to edit registry items, and circumvent problematic security mechanisms, should be understood as a much greater threat, than preventing the owner of a machine the liberty to install whatever they like.
And let's be honest here, any security mechanism marketed to prevent user from getting attacked, are and will be easily overcome by black-hat experts.

It seem to me it's more about the MS corporate idea that they have to take control of everything, which is why essential packages for outdated windows versions are being scrubbed from internet. (I.e. Windows-7,8 framework packages and updates.) Causing substantial security issues for users trying to recover, port and update old software, as they have to find very sketchy sources for their MS updates packages. To do that you need to first understand how it works on the old machines, but if MS is preventing everyone... (Is anyone in MS thinking there!?)

Malware wouldn't be allowed in winget in the first place
Winget wouldn't be an option there anyway
Hashes are already part of the standard that all manifests adhere to
You wouldn't be using Winget to install something that is already local, and especially not something you are actively iterating on.
This is the only part I agree with, although I'm not sure where you got the idea that you have to change things in the registry to get anything involving Winget or things it downloads to run. Also, no, that's not how that works, there are plenty of security mechanisms that have been proven so far as to be effective in what they intend.

Sidenote - Nobody is scrubbing old files from the internet, websites are just the definition of lazy in a lot of cases and hotlink to files instead of doing what they are supposed to and hosting it locally, which means as soon as the origin link is dead, anything that hotlinked to it is dead as well. As to the whole "sketchy sources" part, unless you are looking at files for exceedingly old versions of Windows, all files are signed and checked before install.

You're missing the point... (Go ask your local White Hat.)
Sometimes we need to run OLD SW on new machines.
You're not really saying anything there. 🤷‍♂
Sounds more like you're trying to tell me how to do my development, rather than support what people actually do...
That's what you have to do to run on no longer supported machines / Win OS's.
(Clearly You never tried, or you would not have said this.)

Nobody is scrubbing old files from the internet,

LoL! I have an entire Excel full of scrubbed MS links and where to find what was there before. And I'm certainly not gonna share that here! But I can give you cookie crumb.

Try to download this:

https://www.microsoft.com/en-us/download/details.aspx?id=54616
https://www.microsoft.com/en-us/download/confirmation.aspx?id=40855
⬆️ also mangled from WebArchive here

Case Example:
You'd be extremely surprised by the performance of Windows-7 when running powershell, and finding that your powershell script that normally takes 20 seconds to run in Windows-11, only takes 3 seconds in Windows-7!

I'm genuinely not sure if you are just misunderstanding what Winget is or whats going on here, but

A. The oldest version of Windows that it supports is Windows 10 Build 16299
B. It has never accepted malware and will never accept malware.
C. Has nothing to do with dev because its for downloading already built, fully complete installers from other places on the internet.
D. Doesn't require registry muckery because it can't due to the tests that manifests have to pass before they are even accepted into the repo. All manifests are tested to function correctly in a completely unaltered Windows VM before they even make it into the public manifests.

A new attempt to automation without interactive popups. These commands must be run in powershell as an administrator:
$id = "Google.Chrome"
winget settings --enable InstallerHashOverride
$env:SEE_MASK_NOZONECHECKS = 1
runas /trustlevel:0x20000 /machine:amd64 "winget install --id=$id --accept-package-agreements --accept-source-agreements --ignore-security-hash --exact --silent"
If anyone can test it with packages that don't have a matching hash I would appreciate it.

That didn't work for me, but it appears they're now recommending the following method instead which does work for me:

https://blog.intunepckgr.com/2024/06/19/using-the-google-chrome-exe-deployment-from-winget-over-the-standard-google-chrome-msi/

.\winget.exe install --id Google.Chrome.EXE --exact --scope machine --architecture x64 --silent --disable-interactivity --accept-package-agreements --accept-source-agreements

That didn't work for me

Hi! Can you describe what exactly didn't work for you please? Maybe some logs? 🤔

This method works!!

https://blog.intunepckgr.com/2024/06/19/using-the-google-chrome-exe-deployment-from-winget-over-the-standard-google-chrome-msi/

Solved on Win11 by two steps on Powershell: winget settings --enable InstallerHashOverride as admin winget install NirCmd --ignore-security-hash as normal user

@pandadolphin you are the chosen one sent to bring an end to the suffering

This is completely unacceptable situation when you can't override that security settings while being on elevated shell.
It causes the following "dead loop" situation:
If you're installing something to machine scope you need to be elevated (in order to have write access to Program Files). But if the package you're trying to install has hash issues and you have to use --ignore-security-hash winget tells you you must be non-elevated. Dead end! So you end up not being able to install that package at all!
Even if you decide to move your portablePackageMachineRoot out of Program Files dir to some location where non-elevated user has access - it sill fails, because winget still trying to create a symlink in %ProgramFiles%\WinGet\Links folder and naturally fails again. And as you may know, winget doesn't allow you to configure Links custom directory location.
That's a total dead end!

P.S.: When user intentionally chooses to ignore hash mismatch - it's completely their responsibility. They can still go manually download that invalid hash installer, run it elevated, and still get themselves in trouble. So I don't understand why such stupid winget restriction even exists.

P.P.S.: Also, unelevated winget can't access HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\ registry key. So currently there is no way to normally install package with a hash mismatch to machine scope.

It's unbelievable how blatantly Microsoft is trying to prevent “side loading” outside of its Store!

It's obvious what's going on here. This has absolutely nothing to do with security. It's pure harassment of administrators—and, not least, of users.

Thank you all for the sustained, detailed discussion here — the feedback has been genuinely useful in shaping how we think about this. Sharing where we've landed and the direction we're leaning.

What happens today

The hash-mismatch override already exists, but it's gated:

Enable the admin setting (winget settings --enable InstallerHashOverride), which is also controllable via Group Policy for IT, then pass --ignore-security-hash on a non-elevated command.
When running elevated/as admin, the override is hard-blocked — no flag or setting bypasses it. That's the behavior most of this thread is running into.

How we're thinking about it

The original "no override when elevated" rule was about blast radius: a mismatched binary run with admin rights can do the most damage, so we disabled the override where the risk is highest. We still take installer integrity seriously and want safe-by-default behavior. That said, we recognize a few real problems with it as an absolute rule:

It blocks a legitimate, supported path. Machine-scope installs require elevation, so a hash mismatch there currently can't be overridden at all — even deliberately, one package at a time. That's a dead-end we don't want.
It pushes people toward less-safe workarounds (runas tricks, SEE_MASK_NOZONECHECKS, registry edits, third-party wrappers) that are harder to audit than a first-class, warned, policy-gated override.
Most of the pain isn't really about security — it's manifest staleness, usually from unversioned/"latest" installer URLs whose hash drifts when the publisher updates the binary before the manifest catches up. We're continuing to reduce that lag on the winget-pkgs side, but it will never be zero, so a deliberate escape hatch is warranted.

Direction we're leaning

Keep hash validation on by default; --force will not silently bypass integrity (especially for bulk operations like upgrade --all).
Allow a deliberate, single-package override via --ignore-security-hash that works whether or not you're elevated, still gated behind the InstallerHashOverride admin setting and Group Policy (so enterprises can hard-disable it), with a clear warning and telemetry.
Explore a supply-your-own-hash option (similar to Chocolatey's --checksum) so a newer version can be verified against a vendor-published hash rather than skipping verification entirely — preserving integrity for the "the package is just stale" case.

Sequencing

Changing the elevated hard-block is a behavioral (breaking) change, so we're weighing it carefully — but we're open to bringing it in rather than indefinitely deferring it. It's part of the broader breaking-changes discussion in #2128.

Keeping this open to track that work.

Drafted with the help of GitHub Copilot.

Navigation Menu

Repository navigation

Cannot override installer hash as admin. Even if EnableLua = 0 (UAC OFF) #715

Cannot override installer hash when running as admin, even if EnableLua = 0 (UAC OFF)

Steps to reproduce

Expected behavior

Actual behavior

47 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Cannot override installer hash as admin. Even if EnableLua = 0 (UAC OFF) #715

Description

Cannot override installer hash when running as admin, even if EnableLua = 0 (UAC OFF)

Steps to reproduce

Expected behavior

Actual behavior

Activity

jedieaston commented on Jan 25, 2021

denelon commented on Jan 25, 2021

MarcoPeraza commented on Feb 5, 2021

MarcoPeraza commented on Feb 17, 2021

jedieaston commented on Feb 17, 2021

denelon commented on Feb 22, 2021

47 remaining items

brkerez commented on Jan 15, 2024

dennish78 commented on Jan 15, 2024

feibuilds commented on Jun 19, 2024

uffemcev commented on Dec 8, 2024

eabase commented on Dec 10, 2024

Masamune3210 commented on Dec 12, 2024

eabase commented on Dec 13, 2024

Masamune3210 commented on Dec 14, 2024

trivail-mike-davis commented on Feb 4, 2025

uffemcev commented on Feb 5, 2025

crazivik commented on May 8, 2025

Dontoronto commented on Feb 7, 2026

intruder777 commented on Mar 25, 2026

n-ice-ch commented on Mar 31, 2026

denelon commented on Jul 27, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions