PowerShell 7.5.12 Released: Config Fixes and Urgent Upgrade Path to 7.6 LTS

The official GitHub release page shows the build tagged v7.5.12 at commit 3ad4702, published October 13 at 20:05 UTC by maintainer jshigetomi. Here's what changed and what it means for Windows admins.

What's actually new in PowerShell 7.5.12​

The release notes list one engine fix and one cmdlet change.

• Engine fix (#28070): PowerShell now tolerates I/O and JSON errors when it reads the per-user powershell.config.json file. This file holds user-level settings such as experimental feature toggles and execution policy for PowerShell 7. The notes don't say which errors are now handled or how PowerShell failed before. Going by the title, the fix is about resilience: a damaged or unreadable per-user config file should cause less trouble than it used to.
• Cmdlet change (#28073): Show-Command gets a new GetImportModuleCommand method and a session-restriction check. Show-Command is the graphical helper that builds a command line from a form. The notes don't describe the exact restricted-session scenario. Admins who use constrained or restricted sessions, such as JEA-style endpoints, should still test any workflow that depends on Show-Command.

That's the full list of user-facing changes. This isn't a feature release. The notes mention no CVE, no severity rating, and no breaking change. Treat it as routine maintenance, not an emergency patch.

Section summary: a config-file robustness fix and a Show-Command restriction check. Both are useful, neither is dramatic.

The build, CI and packaging changes​

Most of the changelog covers build and release infrastructure:

• The build moves to .NET SDK 9.0.319. This is the SDK used to build the release. The notes don't say the branch's runtime changed in any meaningful way, and PowerShell 7.5 stays on .NET 9.
• The Microsoft.PowerShell.Native package moves to its latest version, and a test was added for it (#28175, #28170).
• CodeQL init and analyze actions move to 4.38.2 (#28150).
• The Microsoft Store listing metadata has been simplified (#28063).
• The MSIX VPack pipeline gets variable groups that force it to use the production Azure DevOps feed (#28065).
• Windows CI no longer uses PowerShell 5.1 (#28064).
• macOS signatures are now supported in nonofficial pipelines (#28062).
• GitHub Actions dependencies were bumped: actions/setup-dotnet 5.2.0 → 6.0.0, actions/github-script 8.0.0 → 9.0.0, actions/checkout 6.0.2 → 7.0.1, actions/upload-artifact 7.0.0 → 7.0.1, github/codeql-action 4.35.4 → 4.36.0, codeql-action/upload-sarif 4.36.0 → 4.38.2, ossf/scorecard-action 2.4.3 → 2.4.4, and the compliance ready-to-merge workflow 1.0.0 → 1.0.1.

The CI change will draw attention, so to be clear: #28064 only affects the PowerShell project's own build pipeline. It doesn't remove Windows PowerShell 5.1 from Windows or change its support. Microsoft's lifecycle page notes that Windows PowerShell is a Windows component covered by the Windows lifecycle, not PowerShell 7's. In practice, as one community blogger puts it, when you run powershell.exe, you start Windows PowerShell version 5. When you run pwsh.exe, you start PowerShell version 7. Both remain installed side by side.

The dependency bumps are routine supply-chain upkeep. None of them is presented as a vulnerability fix.

Section summary: most of this work sits in the release pipeline, and you won't notice it at the prompt.

The lifecycle clock is the real story​

The changes themselves are minor. The timing is what makes this release worth noting.

Microsoft describes stable releases this way: a stable release occurs between LTS releases, can contain critical fixes, innovations, and new features, and is supported for about six months after the next LTS release. PowerShell 7.6 LTS shipped in March 2026, so 7.5 is now in its final stretch. Microsoft's product lifecycle listing shows the PowerShell 7.5 end date as 11/11/2026 6:59:59 AM UTC, which is November 10 Pacific time.

Two lifecycle rules matter here:

1. Both LTS and Stable releases of PowerShell receive security updates and bug fixes. Microsoft only supports the latest update version of a release. If you're staying on 7.5 until the deadline, 7.5.12 is the build to run.
2. After a version of PowerShell reaches end-of-life, no further updates, including security updates, are provided.

PowerShell 7.4 LTS has the same end date. Microsoft's support page lists 7.4.20 as the previous LTS and says it is supported until 10-Nov-2026. Shops still on either 7.4 or 7.5 face the same November deadline, and the supported destination is PowerShell 7.6 LTS, which runs on .NET 10 with support through November 2028.

The documentation hasn't caught up yet. Microsoft's support page, last updated in August, still says the current Stable release is PowerShell 7.5.11. The endoflife.date tracker likewise shows 7.5.11 (08 Sep 2026) as the latest 7.5 build. Expect both to be updated. For now, the GitHub release page is the authoritative record that 7.5.12 exists. Nothing published so far says whether 7.5.12 will be the last 7.5 build before support ends.

Section summary: update to 7.5.12 if you're on 7.5, but start migrating to 7.6 LTS now.

How to update and verify​

PowerShell 7.5.12 ships as 26 release assets across Windows, Linux and macOS:

A practical update checklist:

1. Check what you're running. Run $PSVersionTable.PSVersion in pwsh. Microsoft's lifecycle page also gives [System.Runtime.InteropServices.RuntimeInformation]::FrameworkDescription for confirming the underlying .NET version.
2. Let Microsoft Update handle it if possible. For MSI installs where it's enabled, Microsoft will automatically update PowerShell 7 in the same release channel if you enable it in the setup wizard, for example 7.2.x to 7.2.y. Servicing releases can show up quietly this way, so confirm the version after updating.
3. Verify manual downloads. The release publishes a hashes.sha256 file and per-asset SHA-256 checksums. On Windows, compare Get-FileHash .\PowerShell-7.5.12-win-x64.msi -Algorithm SHA256 with the published value. For the x64 MSI that value is A22BFB3F96F555A3B99313C7A492E5C3B99C756EB293E603CFDF2E8ED70282C9. The ARM64 MSI should hash to EF7E7CE8767BE3778D1B171A5B19C1F95F4BA6D5E8A1D43A78C8AF7D043A6C3D, and the MSIX bundle to E73984E1945AE5BD23883D906AB6640A4F9CB0C181EFB39E3998A16E78B53554.
4. Test the two changed areas. If users have had startup trouble tied to a damaged per-user powershell.config.json, check that behavior after the update. If your restricted or constrained sessions use Show-Command, run through those workflows before rolling out widely.

Section summary: check your version, update, verify the hash, and test the two areas that changed.

The bottom line​

PowerShell 7.5.12 is a modest release: a config-file resilience fix, a session-restriction check in Show-Command, and a lot of pipeline maintenance. Install it if you're on 7.5, since Microsoft only supports the latest build of a branch. The bigger task is moving off 7.5 and 7.4 before November 10, when both stop receiving updates, including security fixes. Fleets that haven't started testing scripts and modules against PowerShell 7.6 LTS should begin now.