KB5061096: Microsoft’s PowerShell Hotpatch Brings Urgent Fix, But Restart Risk Lingers

Microsoft dropped an out-of-band security update for Windows PowerShell on May 13, 2025, delivering KB5061096 as a rebootless hotpatch for devices enrolled in its Hotpatch program. The catch? If a PowerShell session is active during installation, the system might still start flipping bits on its own—forcing a restart despite the hotpatch design.

This update targets the 26100 build family, including Windows 11 Enterprise LTSC 2024, Windows Server 2025, and Azure Edition variants, pushing the OS build to 26100.3981. It’s a narrowly scoped fix that modifies in-memory code paths for PowerShell, closing off vulnerabilities without the usual cumulative update heft. No CVE identifiers appear in Microsoft’s public KB notes, a deliberate omission to keep the exploit details under wraps while defenders get the bits deployed.

For admins managing high-uptime estates like financial trading floors or healthcare systems, the hotpatch model is a double-edged sword: it slashes exposure windows without demanding an immediate reboot, but only if the stars align on prerequisites—and if no PowerShell console, script, or automation runbook is left humming during install. The following breaks down what changed, who’s affected, and how to wield KB5061096 without crashing a critical session mid-flight.

What Changed: A Cloaked Fix for PowerShell Internals

KB5061096 lands as a discrete hotpatch package—not a full cumulative update. It contains:

• A security improvement for PowerShell that alters its runtime behavior in memory, closing off an unnamed attack vector. The KB summary offers only “This security update includes quality improvements.”
• A bundled Servicing Stack Update (SSU), KB5058523 (version 26100.4060), to improve servicing reliability. This SSU cannot be removed once installed.
• File-level changes visible in the update’s manifest (available from Microsoft), but no user-visible feature tweaks or hotfixes beyond the security hardener.

Crucially, the official KB page warns: “if a PowerShell session is active, then your computer might require a restart after installing the package.” That’s a significant operational asterisk, because hotpatches are marketed as reboot-optional. Microsoft draws a line here: the in-memory patching technique can’t safely overwrite running PowerShell host processes with active runspaces, so the update either forces a restart or leaves those sessions unpatched until the next reboot.

For anyone tracking build numbers, after applying KB5061096 your system will report 26100.3981. Use winver or query HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion for CurrentBuild and UBR to confirm.

Hotpatch Eligibility: Don’t Assume It Works Everywhere

Hotpatch delivery hinges on a tight set of prerequisites:

• SKU: Windows 11 Enterprise LTSC 2024, Windows Server 2025 (Standard/Datacenter/Azure Edition).
• Enrollment: Devices must be registered via Microsoft Intune, Windows Autopatch, or Azure Update Manager and flagged as hotpatch-ready.
• Virtualization backbone: Virtualization-Based Security (VBS) must be enabled. On Arm64 devices, Compiled Hybrid Port Executable (CHPE) must typically be disabled.
• Baseline build: The 26100 series (24H2/LTSC).

If any of these pieces are missing, KB5061096 either won’t be offered or will install as a traditional update requiring a reboot. The hotpatch program remains an enterprise-grade affair, not a consumer safeguard.

What It Means for You: Impact by Role

For Enterprise Server Admins

The good news: you can patch PowerShell flaws almost instantly during business hours without juggling change-control windows for reboots—if you’ve squared away hotpatch enrollment. The bad news: that long-running automation script or interactive maintenance session can torpedo the “no reboot” promise. Before deploying, scan for active PowerShell processes (Get-Process powershell* or pwsh). Schedule a brief pause in automation runbooks if you can’t tolerate a surprise restart.

Virtualized environments add another layer. While KB5061096’s notes don’t call out PowerShell Direct (PSDirect) specifically, subsequent hotpatch cycles (September 2025) revealed that uneven host-guest patch states can break PSDirect remoting and cause handshake failures. So if your Hyper-V hosts use Enter-PSSession -VMName to manage guests, plan to update hosts and guests in lockstep—even though this KB doesn’t explicitly demand it yet.

For Security Operations Teams

A hotpatch is a golden opportunity to shrink the attack surface fast, but it’s also a moving target for detection rules. In-memory code changes can trigger heuristic alerts in endpoint detection and response (EDR) tools, especially those that hook PowerShell’s System.Management.Automation runtime. Immediately after rollout, expect a spike in false positives; tune your SIEM or EDR baselines accordingly. If you rely on script-block logging (Event ID 4104), verify that the hotpatch hasn’t altered the logging fidelity—early adopters reported no changes, but your mileage may vary.

Compliance officers face a headache: KB5061096 lists no CVE numbers. If your regulatory framework demands CVE-to-remediation mapping, open a case with Microsoft Support or consult the official Security Update Guide. Document the hotpatch build number (26100.3981) and the installed file versions as your audit trail until CVE data emerges.

For Desktop IT (Windows 11 Enterprise LTSC)

LTSC editions are often deployed in kiosks, medical devices, or industrial control systems where uptime is king. KB5061096 fits well here—as long as those machines don’t have a persistent PowerShell session lurking (unlikely but possible with custom admin scripts). The update will flow via standard Windows Update for Business channels if hotpatch-eligible, so check Intune reports to ensure compliance numbers don’t dip after deployment.

How We Got Here: The Hotpatch Journey

Microsoft’s hotpatch mechanism debuted in Windows Server 2022 Azure Edition, promising to reduce the mean time to remediation (MTTR) for critical vulnerabilities. The premise: rather than shipping a full cumulative update with a restart, hotpatches swap out buggy in-memory functions with fixed versions on the fly. The technique leans heavily on VBS to isolate and verify patch integrity.

PowerShell has long been a darling of both admins and attackers. Its deep system access and scripting power make it a prime target for fileless malware, lateral movement, and credential dumping. Consequently, any in-memory fix to PowerShell carries outsized urgency. Microsoft has gradually expanded hotpatch support to select on-premises SKUs, and KB5061096 in the 26100 family is a direct result of that strategy.

The “active session” caveat isn’t new, but it’s rarely triggered. Most hotpatches (for kernel, networking, or Hyper-V) don’t care about user-mode state. PowerShell, however, runs in user space and hosts long-lived runspaces that the hotpatch engine can’t safely touch. This limitation has existed since the program’s inception but only now surfaces in documentation—likely because a PowerShell-specific hotpatch finally forced Microsoft to spell it out.

What to Do Now: A Staged Rollout Playbook

1. Inventory and Eligibility
   Run a quick eligibility audit on your fleet. Use this PowerShell snippet:
   powershell Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion' | Select-Object CurrentBuild, ProductName, EditionID
   If the output shows “Enterprise” or “Server” editions on build 26100.x, you may be eligible. Then check Intune enrollment status and VBS configuration.

2. Pilot with Real Sessions
   Pick a small set of non-production machines that run representative workloads: scheduled PowerShell tasks, active remote management sessions, and any third-party automation tools. Deploy KB5061096 via your normal hotpatch ring. Monitor for at least 72 hours.

3. Coordinate with Vendors
   Before broad rollout, notify your EDR, backup, and virtualization Software vendors. Provide them the KB article link and the build number. Ask if their agents are tested against in-memory PowerShell patching.

4. Handle Active Sessions
   A day before pushing to production, send a notification to admin teams to gracefully close any long-running PowerShell consoles or background jobs. For critical automation that can’t be stopped, schedule the update during a maintenance window when a reboot is acceptable. Consider using Group Policy or Intune to block the update temporarily on machines with critical sessions.

5. Deploy in Waves
   Roll out to early adopters (5-10% of targets), then expand every 7-14 days if telemetry is clean. Watch System and Security event logs for unusual authentication errors (Event ID 4625) or PSDirect-related failures if you use PowerShell Direct.

6. Update Compliance Dashboards
   Hotpatches report different KB numbers and build strings than standard LCUs. Add 26100.3981 as a compliant build for your May 2025 patch baseline to avoid false “unpatched” alerts from tools like SCCM, Qualys, or Tenable.

7. Verify Post-Deployment
   After installation, restart any machines that had active PowerShell sessions (or were force-rebooted). Then run a smoke test: establish a remote PowerShell session, execute a few commands, and verify script-block logging is still flowing.

Quick Reference: Verification Commands

Outlook: What’s Next for Hotpatching

KB5061096 underscores a trend: Microsoft is weaponizing hotpatches for more user-mode components, not just kernel or hypervisor fixes. Expect future hotpatches for other high-risk services like Remote Desktop, Print Spooler, or even Windows Defender. The trade-off will always be the same: less downtime, but tighter dependency on VBS and a more complex eligibility matrix.

For admins, the takeaway is clear: hotpatch readiness isn’t a one-time setup. It’s a continuous posture that requires automated checks, vendor partner programs, and a cultural shift away from “Patch Tuesday = reboot Sunday.” Start building those muscle memories now, because the next zero-day PowerShell patch probably won’t wait for a convenient change window.