The PowerShell team released three simultaneous servicing updates on August 14, 2026: v7.4.19, v7.5.10, and v7.6.5. All three versions include a one-line engine patch that resolves inconsistent dot-sourcing behavior for signed advanced-function scripts running under Windows Defender Application Control. Notably, v7.6.5 marks the first time PowerShell targets .NET 10, while the older branches remain on .NET 8 and .NET 9 respectively. There are no new CVEs, as the patch addresses a WDAC enforcement inconsistency rather than a security vulnerability, alongside routine updates to the Microsoft.PowerShell.Archive module.

PowerShell Drops Three Simultaneous Servicing Patches, v7.6.5 Ships on .NET 10

The PowerShell team pushed out three servicing updates on August 14, 2026: v7.4.19, v7.5.10, and v7.6.5. All three landed within roughly three minutes of each other, following a single engine-level patch that fixes inconsistent dot-sourcing under Windows Defender Application Control, plus routine dependency bumps across the board.

If you've been tracking the release calendar, this keeps the monthly patch cycle exactly where it was. July brought v7.4.18, v7.5.9, and v7.6.4. August continues that rhythm. Next up is v7.7.0-preview.3 from July 20, which keeps the development track moving forward while the servicing branches stay locked to stability.

The WDAC Dot-Sourcing Fix

The headline change in every branch targets a specific edge case. When you run a signed advanced-function script with pwsh -file inside a WDAC-enforced environment, PowerShell was incorrectly rejecting it. Simple signed scripts worked fine. Class-based advanced scripts did not.

The discrepancy came down to two separate execution paths inside the engine. Simple scripts route through DlrScriptCommandProcessor, which applies a guard check (&& !this._rethrowExitException). Advanced scripts take a different path, CommandProcessor, which called the same validation but skipped that guard. The exit flag flips to true during non-interactive file execution, meaning the process is about to shut down anyway. Simple scripts got the benefit of the guard. Advanced scripts got rejected anyway.

The patch aligns CommandProcessor with its counterpart by adding the missing guard condition. A one-line change in src/System.Management.Automation/engine/CommandProcessor.cs. That's it.

Keep in mind that this only matters if you're running scripts under WDAC language-mode enforcement. Standard users will notice no behavioral shift. The fix also leaves pwsh -noexit -file alone, which was intentional since the process persists after execution. The original PR (#27727) was identified internally rather than reported by a customer. That usually means the team caught the regression during CI runs before it ever hit production environments. It's classified as medium risk and marked non-regressive. The patch was backported across all three branches between August 5 and August 10 before the final August 14 publish window.

The .NET 10 Shift

The bigger structural story sits under the hood. Each branch updated its underlying SDK dependency, but v7.6.5 crosses a meaningful threshold. It's the first release to target .NET 10, shipping with SDK 10.0.302. v7.6.3 already shipped with 10.0.301, so this just keeps pace with the upstream release cycle.

The older branches stay put on their respective versions. v7.4.19 bumps to .NET 8.0.424, which tracks the extended support window through November 2029. v7.5.10 moves to .NET 9.0.317, though administrators should know that .NET 9 hits end-of-life in May 2026. That means v7.5 is already running against a dependency heading toward retirement.

For admins planning long-term deployments, v7.6.x on .NET 10 gives you the most runway. PowerShell is effectively positioning itself ahead of the SDK ecosystem, which is a deliberate signal to enterprise environments that rely on predictable servicing.

Modules and Build Changes

All three releases bump Microsoft.PowerShell.Archive to 1.2.6. This updates the Compress-Archive and Expand-Archive cmdlets without introducing new attack surface. The archive module does warrant a quick look-back, though. The previous v7.4.18 release included a CAB path validation hardening (#40624) that blocked potential path traversal during expansion. Incremental tightening like that is exactly why the module gets regular updates.

Build pipelines across every branch also got cleaned up. CI workflows now target servicing-* branches directly. NuGet publishing runs as a separate pipeline stage after the git tag. WiX installer builds skip credential provider calls for public feeds. The v7.6.5 line adds a few extras, including localized resource packaging only for MSIX builds and a stripped-down ARM64 package to shave off size.

Security and Next Steps

No new CVEs. The dot-sourcing patch is a correctness fix, not a security vulnerability, and the original PR explicitly notes it isn't a regression. The archive hardening from last month handles the only security-adjacent gap in this window.

You can pull the new builds directly from the GitHub releases page. The next preview on the development track is already out, but the servicing branches are where you'll want to stay if you depend on long-term stability. Head here to grab v7.6.5, here for v7.5.10, and here for v7.4.19.