KB5124008: What the September 2026 Windows Update Actually Broke in WSL

Microsoft shipped KB5124008 on 8 September 2026. Three days later a known issue appeared on the Windows 11 release health dashboard, titled "Host folder shares might be unavailable in Hyper-V-based Linux VMs", listing two affected applications: Claude Cowork and Windows Subsystem for Linux.

The coverage wrote itself. Windows update breaks WSL. For the first few days the only suggested remedy was to uninstall a security update containing 611 patches.

If you're here for the fix: install KB5129195. Microsoft released it out-of-band on 14 September. Check winver for build 26200.9457 (25H2) or 26100.9457 (24H2). Don't uninstall the September update to get there.

The rest of this is about what broke, because the bug reports don't really support the headline. Most people running an ordinary Ubuntu distro saw nothing. WSL uses Plan 9 in two directions, and only one of them was affected.

The timeline

ARM64 on 26H1 had the same regression via KB5124012 (build 28000.2954), fixed by KB5129194. Windows 10 21H2/22H2 got KB5129236.

KB5124008 was a large update. It restored the movable taskbar and patched 611 unique vulnerabilities on Windows 11 24H2/25H2, part of 974 across all Microsoft products that month.

What Microsoft said

The known issue reads:

Some applications that use HCS-managed virtual machines might experience issues when sharing host folder with Linux VMs using Plan9. Folders shared from the Windows host using Plan9 do not appear or cannot be accessed in the guest environment.

Three constraints there: HCS-managed VMs, host folders shared into the guest, over Plan 9. Microsoft added that standard Hyper-V VMs not using Plan 9 were unaffected.

Plan 9 in WSL runs in two directions

Plan 9 here means the 9P2000.L protocol. Microsoft chose it for WSL 2 over SMB because they couldn't assume Samba was installed in an arbitrary Linux guest, didn't want to ship GPL code, and already had Plan 9 server code from another container project. It's been in WSL since WSL 2 shipped.

WSL uses it for two separate jobs, and the client and server swap ends between them.

Click to expand

979 × 439px

Linux files out to Windows (\\wsl$). The Plan 9 server runs inside your distro, started by init. On the Windows side, p9rdr.sys registers \\wsl$ and \\wsl.localhost with the Multiple UNC Provider, then calls into wslservice.exe over COM to start the distro and connect to that server over an hvsocket.

Windows drives into Linux (/mnt/c). Here the server is on the Windows side and the Linux kernel is the 9P client. The mount options show the protocol:

findmnt /mnt/c
# TARGET SOURCE FSTYPE OPTIONS
# /mnt/c C:\     9p     rw,noatime,aname=drvfs;...;msize=65536,trans=fd

msize=65536 is the 64 KB message ceiling that makes /mnt/c slow, and the reason virtiofs exists as an opt-in replacement.

There's also a third case that has nothing to do with WSL. An application can drive the Host Compute Service itself, start its own Linux VM, and attach host folders as Plan 9 shares by calling HcsModifyComputeSystem. Those are the same Hyper-V primitives WSL is built on, used directly by something else. Claude Cowork's sandbox works this way, and so do a fair number of in-house developer tools.

The September regression was in that third path.

The failure signature

The awkward part of diagnosing this was that the host reported success. From one of the more thorough bug reports:

[VM] Adding Plan9 share via HcsModifyComputeSystem: name=c path=C:\ port=9902 flags=0x10 hasToken=true
[HCS] HcsModifyComputeSystem returned: hr=0x0, lastErr=The operation completed successfully.
[VM] VM started successfully
[VM] Sent plan9Shares notification (9 shares)

Nine shares attached, hr=0x0 on each, VM booted, RPC connected. Inside the guest:

[hyperv] mounting Plan9 share "c" via vsock port 9902 at /mnt/.virtiofs-root/shared/c
[hyperv] failed to mount Plan9 share "c": Plan9 mount failed: invalid argument
[hyperv] mounted 0/9 Plan9 shares

None of the nine mounted. The mount points existed and were empty, and nothing in the host logs indicated a problem.

Click to expand

1469 × 287px

The KB replaced these binaries:

The host request was byte-identical to ones that had worked the previous day: same name, path, port, flags=0x10, same token. The caller hadn't changed, so what changed was how the server handled it. Both the x64 and ARM64 branches failed the same way, which suggests one shared change rather than something branch-specific.

The timing here can mislead you if you try to bisect it. The new binaries were written to disk at 01:58, and a boot at 02:06 still worked, because the running Hyper-V processes were still the old ones. Failures only started after the reboot that applied the update, 50 minutes later.

Was WSL actually broken?

The evidence points three ways.

Microsoft named WSL as affected, on the release health dashboard, in both the known-issue and resolved-issue entries. That's the official position.

The detailed reproductions are narrower. The most thorough report has host, guest and application logs plus an uninstall and reinstall comparison, and found WSL 2's drvfs mounts still working with the KB installed:

wsl -d docker-desktop ls /mnt/host/c   # worked fine, KB installed

A second reporter hit the same sandbox failure on a machine with WSL not installed at all, and said so to rule out a WSL configuration problem.

Some WSL-based workloads clearly did break, though. Windows Latest, reporting on the fix, wrote that their custom WSL-based apps "work again and no longer run into storage issues" after installing KB5129195.

What fits all three is that the regression sat in host-side Plan 9 share attachment and hit token-bearing shares (flags=0x10, hasToken=true) attached through HCS by applications running their own VMs. Ordinary /mnt/c doesn't go through that path, which is why it mostly kept working. WSL appears on the dashboard partly because Microsoft's servicing team tracks this code under the Hyper-V/WSL integration component, which describes where the code lives rather than who was affected.

That scoping is inferred from logs across a handful of reports, and Microsoft hasn't published it. If you run WSL with unusual share setups, network drives surfaced into a guest, or anything driving HCS directly, you were in scope. If you run Ubuntu and cd /mnt/c, you probably saw nothing at all.

The difference mattered while the fix was still outstanding, because the advice on offer was to uninstall a security update.

Checking your own machine

Build number first:

winver
# or
[System.Environment]::OSVersion.Version

Then check the mounts:

findmnt /mnt/c          # is it mounted, and over what?
ls /mnt/c | head        # does it have contents?

A mount point that exists but is empty is the signature. From Windows, check the other direction too:

ls \\wsl$\Ubuntu

Those are the two separate Plan 9 paths. Check both. One of them working tells you nothing about the other.

Two things not to do

Don't uninstall KB5124008. Between 8 and 14 September that was the only option, and if your tooling was dead it was a reasonable call. Now it isn't. KB5124008 carries 611 security fixes, and KB5129195 is cumulative, so it includes those along with the Plan 9 repair.

Don't set virtiofs=true. I nearly suggested this myself while writing. virtiofs bypasses 9P entirely, so it looks like it should route around a 9P bug.

It doesn't help. Nothing in the reports suggests it mitigates this regression, and virtiofs on distros has open automount bugs of its own, #40773 and #40790, where a single unshareable drive causes WSL to skip automounting every drive, leaving you with no /mnt/c and nothing in dmesg to explain it. virtiofs remains an opt-in performance option.

Several other things were tried across the reports and none of them worked: recreating the VM, re-downloading an 8 GB guest image, changing Linux permissions, re-adding the shared folder, restarting the vmcompute service. The fault was on the host side, so none of them could have. One reporter found that Restart-Service vmcompute -Force crashed the machine outright, once, without reproducing.

The rest of the damage

Plan 9 wasn't KB5124008's only casualty. As of 15 September:

The Explorer crashes are concentrated in enterprise setups using Citrix UPM, FSLogix, Horizon or ProfileUnity ProfileDisks, on both 24H2 and 25H2; restarting explorer.exe from Task Manager is the stopgap. The AMD problems cover RX 6600 through RX 9070 XT and survive driver rollbacks, which points at the OS. HP and Lenovo owners have had additional trouble.

KB5129195 also added hardening for CVE-2026-62721, a privilege-escalation flaw in the Windows User-Mode Power Service, after Microsoft revised its advisory to acknowledge that the original September patch was incomplete.

About the patch volume

Microsoft patched 974 CVEs across its products in September 2026. In September 2025 the figure was 86.

Patch volume has roughly tripled year on year. The common explanation is that AI-assisted code analysis is finding far more real vulnerabilities than human review did, which is good; those bugs were there either way.

But 611 security changes in a single Windows 11 cumulative update is a lot of surface area, and this month it regressed Plan 9 share attachment, RDS, USB audio and Explorer at the same time. A Microsoft engineer asking for memory dumps on the Explorer crashes put it plainly: the September updates "were extensive and need more data to understand and root cause."

If that cadence holds, out-of-band corrections a week later stop being exceptional and become part of the release. Holding non-critical machines back for a few days starts to look defensible on those grounds, which is an uncomfortable position for anyone who cares about patching quickly.

Takeaways

WSL is built on Hyper-V primitives, so Hyper-V regressions surface as WSL bugs. The Plan 9 server, the compute service and the redirector driver all sit underneath WSL rather than inside it. When they break, wsl.exe is where you notice, and reinstalling WSL or your distro can't fix it.

The practical point is that the two Plan 9 directions are separate systems. \\wsl$ failing and /mnt/c failing have different causes and need different diagnostics. (Unrelated but useful: a long-standing cause of \\wsl$ being inaccessible is the P9NP network provider slipping down the provider order, often after an in-place upgrade. Microsoft suggests reordering providers through ncpa.cpl, since editing ProviderOrder in the registry tends to get reset.)

For WSL UI this landed on work already underway. We're going through anything that assumes Plan 9 mounts are present and healthy, because between this regression and the virtiofs transition, "/mnt/c exists and works" has stopped being a safe assumption. A management tool should show which transport a mount is using and whether it's actually working.

One last thing about the public record. Almost every detailed report of this came from someone running an application-managed VM rather than a standard distro. The dashboard entry named WSL, and the reporting followed the dashboard. It took reading the logs to see the gap.

Useful links:

• KB5124008 support page (September 2026 Patch Tuesday)
• KB5129195 support page (out-of-band fix)
• Windows 11 known issues (release health)
• WSL Plan 9 technical documentation
• Detailed bug report with full host/guest logs
• Microsoft Q&A thread on the regression
• virtiofs automount issue #40773
• WSL Containers, virtiofs and a 6.18 Kernel