PowerShell 7.6.5 Deep Dive: WDAC Fix, Security Hardening, Smaller Packages, and ARM64 Support

For most administrators, the recommendation is straightforward: PowerShell 7.6.5 is preferable to 7.6.4. Windows estates using Windows Defender Application Control, applications embedding Microsoft.PowerShell.SDK, ARM64 Linux deployments, and organizations redistributing PowerShell ZIP packages have the clearest reasons to prioritize or carefully validate the update.

The main runtime fix: signed advanced scripts under WDAC​

The headline engine change is pull request #27762. Before 7.6.5, PowerShell followed different internal paths for simple scripts and scripts containing advanced functions. In a WDAC-enforced environment, a signed advanced-function script launched with pwsh -File could reach ValidateCompatibleLanguageMode and fail even though an equivalent signed simple script succeeded.

The correction changes the advanced-script CommandProcessor path so it honors the same rethrow-exit condition already used by the simple-script path. For an ordinary pwsh -File script.ps1 launch, the process exits when the script finishes, so PowerShell can safely align the two paths without leaving imported Full Language Mode functions available in a continuing constrained session.

There is an important boundary: pwsh -NoExit -File intentionally retains its previous behavior. Because that process remains alive, the language-mode boundary has different consequences. Administrators should test both forms instead of treating 7.6.5 as a universal change to every WDAC file-launch scenario.

The affected population is narrower than every PowerShell user, but it includes consequential enterprise workflows:

• Scheduled tasks and deployment agents launching signed scripts with pwsh.exe -File.
• Scripts that define advanced functions or dot-source signed function libraries.
• Endpoints where WDAC and Constrained Language Mode enforce application-control boundaries.

Test using the same service account, command line, working directory, executable path, and policy state used in production. Success in an elevated interactive console does not prove a scheduled task or software-distribution agent follows the corrected path.

Security work hidden beneath the short changelog​

The public release note foregrounds one engine fix, but the signed tag contains more security-relevant work than that summary suggests.

The most explicit dependency change is in Microsoft.PowerShell.SDK. Pull request #27787 moves System.Security.Cryptography.Xml and System.Security.Cryptography.Pkcs from 10.0.6 to 10.0.10. The repository classifies the XML dependency update as high-severity security servicing and records five CVEs: CVE-2026-47302, CVE-2026-47304, CVE-2026-50525, CVE-2026-50527, and CVE-2026-50648.

Two advisories deserve particular attention. CVE-2026-47304 covers a security-feature bypass in .NET XML Encryption, while CVE-2026-50527 covers denial of service in the same XML cryptography package. Version 10.0.10 is the patched dependency line recorded by PowerShell. The Pkcs package moves with it to satisfy the updated dependency constraint.

This does not prove that every ordinary pwsh process exposed every listed vulnerability. The clearest directly affected surface is the dependency graph consumed by applications built with Microsoft.PowerShell.SDK; exploitability still depends on whether an application exercises the vulnerable XML cryptography path. SDK consumers should restore or rebuild against 7.6.5 and verify the resolved dependency graph instead of closing findings solely from the PowerShell version string.

A source-level audit also found tag changes that are not individually named in the ten-entry public changelog:

• Invoke-WebRequest and Invoke-RestMethod strip Authorization headers on redirects unless PreserveAuthorizationOnRedirect is explicitly supplied, including redirect paths involving FollowRelLink or PreserveHttpMethodOnRedirect.
• Invoke-WebRequest -OutFile sanitizes a URL-decoded redirected filename with Path.GetFileName before combining it with a destination directory, preventing encoded path components from escaping the intended output directory.
• The PowerShell Remoting Protocol checks a declared object size as soon as the frame header is available, rather than buffering the complete oversized object before enforcing the configured maximum.
• SSH remoting constructs individually escaped argument-list entries, with tests rejecting malformed username, port, and subsystem values that attempt to append SSH options.
• Windows-compatibility location synchronization escapes single quotes in paths and module-qualifies Microsoft.PowerShell.Management\Set-Location.
• PowerShell 7 CIM cmdletization restores embedded XSD validation; its regression test attempts command injection through a CDXML verb and expects Import-Module to reject the file.

These changes make “one engine fix” an incomplete description of the shipped code, even though it accurately describes the curated Engine section of Microsoft’s release note.

The .NET version record needs three separate numbers​

PowerShell’s release page and curated changelog say the build update is .NET SDK 10.0.302. That is also the SDK named by 7.6.4, so the release-note line is not a new documented SDK baseline between the two releases.

The signed source tag tells a more complicated story. Its global.json pins SDK 10.0.303, reflecting late early-access build-pipeline work. Meanwhile, pwsh.runtimeconfig.json inside Microsoft’s official Windows x64 ZIP declares Microsoft.NETCore.App 10.0.11 and Microsoft.WindowsDesktop.App 10.0.11. SDK and runtime versions are different things: the SDK builds the product, while the bundled runtime executes it.

The accurate conclusion is therefore:

• Microsoft’s public 7.6.5 release note says SDK 10.0.302.
• The signed 7.6.5 source tag pins SDK 10.0.303.
• The official self-contained Windows x64 package carries .NET runtime 10.0.11.

Administrators should not infer the state of every system-wide .NET installation or every framework-dependent PowerShell package from the PowerShell version alone. Track the local .NET runtime and SDK separately, especially for applications that use a framework-dependent distribution or embed the SDK.

Smaller packages, not a faster shell​

PowerShell 7.6.5 contains a meaningful distribution-footprint improvement, but Microsoft publishes no CPU, memory, startup, or throughput benchmark demonstrating that commands run faster.

Pull request #27799 limits localized satellite resources to MSIX-oriented builds, removes XML documentation files from packaging inputs, and makes the min-size configuration self-contained while disabling ReadyToRun for that configuration. The 7.6.5 backport estimates approximately 35 MB of package reduction.

The original change provides useful context: localized resources accounted for roughly 27 MB at the time, with another 8 MB anticipated as more resources became localized; removing unnecessary XML documentation accounted for approximately 10.2 MB of packaging input. Those figures describe overlapping stages and projections and should not be added into one guaranteed saving.

This is a download, storage, scanning, and deployment-efficiency improvement. It is not evidence of faster execution. ZIP-based deployments should regression-test exact file manifests, localization expectations, endpoint-security allowlists based on hashes or paths, and any repackaging pipeline that expected satellite-resource directories or XML documentation files. MSIX is the package path intentionally retaining localized resources.

ARM64 and bundled-module improvements​

Pull request #27798 replaces the internal generic min-size package type with min-size-x64 and min-size-arm64, adding the corresponding ARM64 build, signing, staging, and upload flow. It also fixes publication of the Linux Debian ARM64 package, which had previously been built but not downloaded into the release-upload stage.

The result is visible in the artifacts. The 7.6.5 release adds both powershell_7.6.5-1.deb_arm64.deb and powershell-lts_7.6.5-1.deb_arm64.deb. GitHub’s release page displays 35 downloads compared with 33 for 7.6.4; excluding GitHub’s two automatically generated source archives, that is 33 uploaded assets versus 31. The two-item increase is the regular and LTS Debian ARM64 pair.

The bundled Microsoft.PowerShell.Archive reference also moves from 1.2.5 to 1.2.6. The PowerShell release PR does not claim a new Compress-Archive or Expand-Archive feature, so this should be treated as module servicing. Organizations pinning module versions or validating exact hashes should update their expectations and regression-test archive workflows.

What the ten curated release-note entries actually cover​

At the PR level, Microsoft’s public 7.6.5 note contains:

• One engine fix: #27762, the WDAC pwsh -File advanced-function correction.
• One CI change: #27654, extending Windows, macOS, and Linux CI triggers to servicing branches.
• Three build correctness fixes: #27845 for OneBranch output variables, #27827 for Windows EXE-signing conditions, and #27820 for min-size conflict-resolution errors.
• Two pipeline capabilities: #27806 for controlled early-access .NET SDK and NuGet feeds, and #27798 for architecture-specific min-size and ARM64 publication.
• Three dependency or package-content changes: #27800 for Archive 1.2.6, #27799 for localization/package trimming, and #27787 for the release branch and cryptography dependency servicing.

There are no new PowerShell language constructs, cmdlets, or advertised public APIs in this set. Most of the work makes servicing, signing, packaging, dependency management, and artifact production more reliable.

Compatibility and breaking-change nuance​

The ten public release-note PRs do not declare a PowerShell language, cmdlet-contract, or public-API breaking change. The WDAC correction intentionally turns a previously failing invocation into a successful one, while preserving -NoExit -File behavior.

There are nevertheless observable compatibility changes:

• Redirected web requests no longer retain Authorization by default on the affected manual redirect paths. Scripts that deliberately require cross-origin credential forwarding must opt in explicitly and should assess that choice carefully.
• Windows ZIP package contents change because localized resource folders and XML documentation are trimmed.
• Downstream source-build automation that calls internal packaging helpers must replace the generic min-size identifier with architecture-specific values.
• Pinned bundled-module inventories must account for Microsoft.PowerShell.Archive 1.2.6.

One branch-integrity issue remains unresolved. The 7.6.4 and 7.6.5 tags are parallel release branches rather than a simple linear history. A ValidateExtractionPath helper added to 7.6.4 for help-CAB extraction is absent from the 7.6.5 source tag. Inspection of Microsoft’s official Windows x64 binaries confirms the method is present in System.Management.Automation.dll 7.6.4 and absent in 7.6.5. That establishes a code and binary regression or omission, not demonstrated exploitability. Microsoft should clarify whether the validation was intentionally replaced, omitted during backporting, or scheduled for a later servicing release.

Upgrade priorities​

• High priority — WDAC estates: upgrade and test signed advanced-function scripts through the production pwsh -File launch path. Test -NoExit -File separately because it remains unchanged.
• High priority — Microsoft.PowerShell.SDK consumers: restore or rebuild with 7.6.5, confirm System.Security.Cryptography.Xml resolves to 10.0.10 or later, and keep broader .NET servicing as a separate control.
• Recommended — general 7.6.4 fleets: move to 7.6.5 after normal canary testing; feature churn is low and the servicing gains are meaningful.
• Recommended — ARM64 Debian deployments: use the newly published regular or LTS ARM64 package and review any workaround previously used to obtain it.
• Validate first — ZIP and repackaged installations: check localization, exact file manifests, allowlists, scanners, and packaging automation before broad rollout.
• Sync carefully — source-build and release-pipeline forks: account for architecture-specific min-size identifiers, signing conditions, early-access feeds, credentials, and OneBranch variables.

Bottom line​

PowerShell 7.6.5 is not a flashy release, but it is more consequential than its short changelog appears. It corrects a real WDAC execution inconsistency, services a high-severity XML cryptography dependency, adds several source-level security hardenings, cuts package footprint, repairs ARM64 Debian publication, and strengthens Microsoft’s release machinery.

For most organizations already on 7.6.4, upgrading is the sensible choice. The urgency is highest for WDAC environments and PowerShell SDK consumers. The two cautions are equally concrete: validate changed ZIP/package contents, and watch for Microsoft’s response to the missing 7.6.4 help-CAB validation in the 7.6.5 branch.