The cumulative updates KB5079391 and KB5094125 finally resolve ERROR BAD PATHNAME when WUSA installs .msu files from network shares, ending a workaround era that started with Microsoft's August 2025 acknowledgment.
Enterprise Windows admins who spent most of the past year staging .msu files locally before running WUSA finally have a real fix in the June 2026 Patch Tuesday cumulative updates. The specific failure, ERROR_BAD_PATHNAME, surfaces when the Windows Update Standalone Installer processes a network share that contains multiple .msu files, and it has been breaking patch deployment scripts on Windows 11 24H2, Windows 11 25H2, and Windows Server 2025 since updates started shipping in May 2025.
The failure is narrow but operationally loud. A single .msu file installs cleanly. A local copy of the same payload installs cleanly. The moment WUSA is pointed at a UNC path holding several .msu files, either from the command line or by double-clicking one of the files in Explorer, the path resolution mishandles the multi-file enumeration and the install aborts. Because WUSA is the standard tool enterprise admins use to push Microsoft Standalone Update packages from a deployment share, the bug propagated straight into the patch pipelines that manage fleets of Windows 11 and Windows Server 2025 hosts.
Microsoft first acknowledged the issue in August 2025, roughly ten months before the fix. A partial mitigation followed in September 2025 through a Known Issue Rollback, the mechanism Microsoft uses to revert a change on devices that have already installed the offending update. That rollback is automatic on consumer and unmanaged devices, which is why home PCs were largely untouched, and it is also why enterprise admins got little relief: KIR reaches managed hosts only when admins opt in via a specific group policy, and the underlying code path that produced the failure on UNC shares was still live on machines that had not received the rollback. The published workaround, save the .msu files to a local path on the device and run WUSA from there, has been the de facto standard for a year.
The June 2026 cumulative updates close that gap. KB5079391 covers Windows 11 24H2 and 25H2, and KB5094125 covers Windows Server 2025. Microsoft has not yet published the full release notes describing the underlying code change, but the fix is positioned as a complete resolution rather than another rollback, which means enterprise admins who install the June cumulative should be able to return to deploying .msu files directly from a network share. The operational question for most IT teams is timing: patch cycles that already land the June cumulative this week will pick up the fix as part of the normal cadence, and the only meaningful change is that the local-staging step can be retired. Teams that defer the June cumulative or that run custom ring deployments will need to keep the staging workaround in place until their wave catches up.
A few caveats bound the story. The reported behavior is consistent and reproducible in the configurations Microsoft has documented, but the company has not published a deep technical root-cause analysis, so the specific component that mishandles multi-.msu enumeration on UNC paths remains a useful follow-up for anyone modeling deployment risk. The KIR from September 2025 is still in effect on devices that have not yet received the cumulative, which means admins who reboot a managed host and immediately check Update History may still see stale error states for about 15 minutes after restart, the same wait Microsoft has been recommending since the mitigation shipped. And the fix applies only to the WUSA and multi-.msu-from-network-share path; other WUSA failure modes, including ones that surface on different Windows editions, are not in scope here.
For the next two patch cycles, the practical playbook is short. Install the June 2026 cumulative (KB5079391 for Windows 11, KB5094125 for Windows Server 2025) on the standard cadence, validate that WUSA can install a multi-.msu payload from a UNC path on a test host, and then remove the local-staging script from the deployment runbook. Until that test passes on a representative image, the local-stage workaround is the right bridge, and it costs almost nothing to keep for one more cycle. The bigger lesson is the one Microsoft itself surfaced in the timeline: a Known Issue Rollback is a real mitigation, but on enterprise-managed fleets it is a partial one, and the gap between automatic consumer coverage and admin-controlled rollout is exactly the surface this bug lived on for thirteen months.