Microsoft has released KB5066360, a hotpatch that corrects a critical handshake regression in PowerShell Direct without requiring a system restart. The update, which lands on eligible Windows Server 2025 Datacenter: Azure Edition and Windows 11 Enterprise LTSC 2024 systems, raises the OS build to 26100.6569 and closes a brief authentication window that could allow unauthorized, non‑administrator access between Hyper‑V hosts and guest virtual machines.

Administrators who rely on PSDirect to manage VMs without network connectivity are the primary audience for this fix. The patch is delivered through Windows Update to hotpatch‑enrolled devices and is designed to patch the running code in memory, eliminating the downtime normally associated with security updates.

A regression born from September’s update cycle

The problem first appeared after Microsoft shipped its September 2025 cumulative and hotpatch updates. Those updates inadvertently broke the legacy fallback mechanism that PowerShell Direct uses when a patched guest tries to talk to an unpatched host (or vice‑versa). The handshake, which should seamlessly revert to a compatible protocol and cleanly tear down sockets, instead left sockets uncleared and caused intermittent authentication failures logged as Event ID 4625 in the Security event log.

PowerShell Direct is a cornerstone of Hyper‑V administration. It lets an automation service on the host establish a remote PowerShell session directly into a guest through integration channels, bypassing network‑based remoting. When both sides are at different patch levels, the fallback is essential for reliability. The regression not only caused operational headaches—dropped sessions, failed management tasks—but also introduced a narrow security exposure. During the broken handshake, a brief window existed where unauthorized, non‑administrator access could theoretically be obtained.

KB5066360 is Microsoft’s targeted answer to that exposure.

What the hotpatch delivers

Released on September 9, 2025, KB5066360 updates key PowerShell binaries—System.Management.Automation.dll, Microsoft.PowerShell.ConsoleHost.dll, and related resource DLLs—to version 10.0.26100.6569. The official KB article lists the fix succinctly: “Fix for PSDirect connections failing in Hotpatch devices” and explains it resolves a vulnerability between host OS and guest VMs, while improving reliability so older sessions no longer shut down unexpectedly.

One important caveat: Microsoft’s KB text does not enumerate a CVE identifier. The Security Update Guide or MSRC should be consulted for explicit CVE mapping if your compliance workflows demand it. The absence of a CVE in the KB article appears to be a documentation gap rather than an indication of missing accreditation.

Who is affected and who should move first

The hotpatch applies to a narrow set of SKUs built on the Windows 11 2024 update codebase (build 26100), notably Windows 11 Enterprise LTSC 2024 and Windows Server 2025 Datacenter: Azure Edition. However, any Hyper‑V environment where PSDirect is in daily use—especially mixed estates with uneven patching—should treat this as a high‑priority fix.

Microsoft’s guidance is explicit: if a guest VM has received the September 2025 security updates, the host should receive KB5066360. Host‑first deployment is the safest path, with guest parity to follow quickly. Staged rollouts are recommended: start with a pilot ring that mirrors your production hardware and software stack, then expand after 48–72 hours of regression‑free monitoring.

Hotpatching’s promise—and its prerequisites

Hotpatching is a relatively new servicing model for Windows, aimed at enterprise customers who need to patch fast without draining availability. Fixes are applied to in‑memory code, so a reboot is not required immediately. The program operates on a scheduled cadence of baseline months and hotpatch months, with strict eligibility criteria documented by Microsoft.

To receive KB5066360 through Windows Update, a device must be enrolled in the hotpatch program, licensed appropriately, and running a compatible baseline build. The servicing stack update (SSU) is often bundled to improve installation reliability. WSUS and offline catalog distribution may vary; for most organizations, automatic delivery via Windows Update is the simplest path.

The upsides are clear: reduced downtime, faster mitigation of threats, and narrowly scoped payloads that limit the chance of broad regressions. But trade‑offs remain. Mixed estates that can’t enroll in hotpatching will need baseline cumulative updates, which still require restarts, breaking parity. In‑memory patching can conflict with hooking mechanisms in EDR, backup, or virtualization tools, so vendor compatibility testing is essential before broad deployment. Rollbacks, while possible, typically force a restart and may leave a device in an unexpected servicing state.

Deployment checklist

A structured rollout is the difference between a smooth patch cycle and operational chaos. Start with inventory.

  • Map every host/guest pair where PSDirect is used. Flag pairs where either side is already on the September updates.
  • Confirm hotpatch eligibility with winver or (Get‑ComputerInfo).OsBuildNumber; after KB5066360, expect 26100.6569.
  • Coordinate with vendors of EDR, backup, and monitoring agents that hook into PowerShell or virtualization subsystems.

Pilot and validation:

  • In a small, representative pilot ring, apply KB5066360 to hosts first. Ensure guests are then patched promptly.
  • Validate PSDirect connectivity in all directions—host‑to‑guest and guest‑to‑host where supported.
  • Monitor Security event logs for Event ID 4625 and virtualization subsystem logs for socket cleanup errors.

Production rollout:

  • Expand to an early‑adopter ring only after 48–72 hours of clean telemetry.
  • Correlate process creation (Event ID 4688) and firewall changes (Events 4946/4947) with hotpatch install times to catch unexpected side‑effects.
  • Update CMDB and compliance scanners to recognize hotpatched build numbers, or you’ll get false “unpatched” reports.

Monitoring and forensic indicators

Event ID 4625 is the canary. Before the fix, failed PSDirect handshakes would light up the Security log with this authentication failure event. Post‑deployment, its absence is the best validation.

Security teams should also tune EDR baselines to avoid noise: hotpatching changes in‑memory code in ways that some agents interpret as anomalous. Pre‑deployment baselines reduce false positives during the rollout.

For deeper forensic work, track PowerShell process creation (Event ID 4688), firewall rule modifications (Events 4946/4947), and service state transitions. If you see these spiking around hotpatch install times without a planned change, investigate.

A timely reminder on Secure Boot

Tucked inside KB5066360 is a separate but urgent notice: Secure Boot certificates used by many Windows devices begin expiring in June 2026. This is not part of the PSDirect fix, but it demands cross‑team planning now. Start inventorying firmware readiness, test DB/KEK updates, and coordinate with OEMs so you aren’t caught off guard when the certificates expire.

Practical commands for quick checks

  • List installed hotfixes: wmic qfe get HotFixID,Description,InstalledOn
  • Verify build number: (Get‑ComputerInfo).OsBuildNumber (should return 26100.6569 on patched systems)
  • Hunt for handshake failures: In PowerShell, Get‑WinEvent -FilterHashtable @{LogName='Security'; Id=4625} | Where‑Object { $_.TimeCreated -gt (Get‑Date).AddDays(-1) }

Final assessment

KB5066360 is a narrowly scoped, operationally vital patch that restores trust in PowerShell Direct while closing a brief security window. It highlights both the maturity of Microsoft’s hotpatch model and the real‑world friction of keeping hosts and guests in lockstep. For teams running Hyper‑V with PSDirect‑dependent workflows, delaying is not an option. Deploy with a staged approach, validate aggressively, and treat the Secure Boot reminder as a separate but equally urgent initiative. The faster you achieve host/guest parity, the sooner your hypervisor management returns to a predictable, secure state.