PowerShell 7.7.0 Warns on SHA-1 File Catalogs: What Admins Need to Know

What the SHA-1 catalog warning does​

The release notes list one cmdlet change: a new warning for SHA-1 file catalogs. The pull request behind it describes the change in more detail. It adds an advisory warning when New-FileCatalog or Test-FileCatalog work with legacy catalog version 1 (SHA-1). It nudges users toward version 2 (SHA-256) without breaking compatibility.

• Trigger: Generating or validating a version 1 catalog.
• Suggested fix: The warning recommends regenerating the catalog with -CatalogVersion 2. That wording appears in the warning's resource text.
• Behavior: The follow-up wording fix has no executable code or validation behavior changes. This is a nudge, not a block.

The 7.7.0 notes also list a fix to the WeakCatalogHashAlgorithm resource string. It corrects the warning so it identifies version 1 catalogs and the weak SHA-1 algorithm, and drops an incorrect reference to SHA0. The early draft wording was muddled, and it was cleaned up before release.

Why admins should care​

Microsoft's own documentation for New-FileCatalog explains the background. Version 1 uses the deprecated SHA1 algorithm for file hashes, while version 2 uses SHA256. Microsoft says SHA1-based catalogs shouldn't be trusted for security-sensitive workflows.

If your build or deployment scripts still create or check version 1 catalogs, expect new warning output after upgrading. That matters for pipelines that treat warnings as noise, and for any that fail on them. A practical migration path:

• Search your scripts for New-FileCatalog calls with no -CatalogVersion, or with a value of 1.
• Regenerate those catalogs with -CatalogVersion 2.
• Re-run Test-FileCatalog against the new catalogs and confirm the warning is gone.

I haven't tested this myself, and the release notes don't spell out these steps. They follow from the warning text and the cmdlet documentation.

The rest of the release​

The remaining items are mostly plumbing. They show how the build is shifting more than they change what you type at a prompt.

• .NET: The build updates to .NET SDK 11.0.100. Microsoft's preview documentation still described a .NET 11.0.0-rc.1 base, so 7.7.0 appears to move to the final SDK. I'd treat that as a reasonable reading, not a documented statement.
• Appx manifest: The notes say the manifest was updated so it doesn't allow updates while PowerShell 7 is running. That should help avoid in-place update problems with the Store/MSIX package. The notes don't give more detail.
• PSResourceGet: The bundled module moves to 1.3.0-rc2. That is still a release candidate shipping in a stable build, so note it if you're pinning module versions.
• Internal feeds: The notes add the ability to consume PowerShell modules from an internal feed. They also fix credentials for the module-only vPack build feed. Both are mainly relevant to Microsoft's own build pipeline.
• CI and tests: Linux CI images are pinned to Ubuntu 24.04. A regex in ConsoleHost.Tests.ps1, used to verify help content, is fixed.
• Dependencies: The CodeQL GitHub Action bumps from 4.38.3 to 4.39.1.
• Localization: A OneLocBuild check-in lands.

None of these items change how you use the shell day to day.

Downloads and verification​

The final 7.7.0 notes cover changes since v7.7.0-rc.1. So much of the headline 7.7 content was already in the previews and release candidates. This tag is the last stretch.

The release ships packages for every major platform:

• Windows: x64, x86 and ARM64 ZIPs, framework-dependent ZIPs (including a WinDesktop variant) and an MSIX bundle.
• Linux: DEB packages for amd64 and arm64, RPMs for Azure Linux, CM and Red Hat-style systems, and tarballs including musl and ARM32 builds.
• macOS: x64 and arm64, as both PKG and tarball.

SHA-256 hashes are published for each artifact. For example, the Windows x64 ZIP is listed as 7C74E03B20A75B59715847439D046A6214B1863EE79B187872980F139BB4A05F, and the x86 ZIP as 1723B1EF5FF7791A77638F05B48168331DF84F51C19FBEC7A1321FE924F3463B. To check a download on Windows, run Get-FileHash on the file and compare the result with the published value. The irony of a release that warns about SHA-1 and ships SHA-256 checksums is a nice touch.

What the preview docs say​

Microsoft's "What's New in PowerShell 7.7" page was still describing preview.5 when I looked at it. It lists changes that may carry into 7.7.0, but they aren't confirmed in the final release notes:

• New-Guid generating Version 7 (time-sortable) UUIDs by default instead of Version 4. This is flagged as a breaking change. Scripts that need fully random GUIDs are told to call [guid]::NewGuid() directly.
• Stricter validation on the -Property parameter of the Format-* cmdlets.
• A new New-TemporaryDirectory cmdlet.
• Tighter handling of explicit -Switch:$false values across many cmdlets.

Those items come from preview documentation, and the final 7.7.0 changelog doesn't restate them, since it only covers changes since the release candidate. Check the full 7.7 changelog and test in a non-production environment before rolling out. The New-Guid change in particular could surprise scripts that assume random GUIDs.

Bottom line​

7.7.0 is a low-drama final release. The security-relevant change is the SHA-1 catalog warning, which is advisory only. If your pipelines still use version 1 catalogs, now is the time to move them to version 2. Everyone else can verify the hashes, upgrade on their normal schedule, and keep an eye on the preview-era breaking changes.

Correction (November 10, 2026): The SHA-256 example hashes were assigned to the wrong files. The Windows x64 ZIP hash is 7C74E03B20A75B59715847439D046A6214B1863EE79B187872980F139BB4A05F and the x86 ZIP hash is 1723B1EF5FF7791A77638F05B48168331DF84F51C19FBEC7A1321FE924F3463B; the hash previously shown for the x64 ZIP belongs to the framework-dependent WinDesktop ZIP.