Microsoft released WSL 2.7.10 on June 26, 2026, a narrow but important Windows Subsystem for Linux servicing update that hardens how persisted VHD mounts are restored after the WSL utility VM is recreated. The public changelog lists only one item — passing the mounting user’s token on VHD restore — but the underlying fix addresses a real security boundary issue: WSL should not re-resolve a user-controlled VHD path as SYSTEM during restore when the original mount was performed by an ordinary user.
The change belongs to the part of WSL most users never think about: the Windows-side service logic that remembers mounted disks, tears down and recreates the lightweight utility VM, and reconnects storage when WSL starts again. For everyday Ubuntu, Debian, Fedora, or Kali users who simply launch a shell, this update may pass unnoticed. For anyone using
Microsoft’s own GitHub comparison for
For a live
The restore path was the weaker side.
When the WSL utility VM is torn down because it has gone idle, WSL can later recreate that VM and restore disk mounts that were persisted for the current boot. According to the PR, that restore path re-attached persisted VHDs as SYSTEM without the mounting user’s token. In practical terms, WSL could re-resolve a user-controllable VHD path under a more privileged identity than the user who originally mounted it.
That is the problem 2.7.10 fixes.
The new behavior passes the mounting user’s token into the VHD restore path so that access grants and path resolution run under the same user identity that performed the original mount. That brings restore behavior back in line with the live
A TOCTOU issue appears when software checks one thing at one moment and then uses something that may have changed by the time the privileged operation happens. Filesystem paths are a classic place for this kind of bug because paths can involve symlinks, junctions, reparse points, and other redirection mechanisms.
In this case, the concern was not that a normal live VHD mount was unsafe. Microsoft’s PR explicitly explains that the live path already impersonated the mounting user. The concern was the restore path after the utility VM had been recreated.
That distinction matters. The problematic window was not “all VHD mounts are broken.” It was narrower: persisted VHD restore could re-resolve a user-controlled path as SYSTEM when the VM came back.
The fix is also narrower and cleaner than a broad “reject all symlinks” approach. Earlier discussion around the original fix notes that a handle-pinning or reparse-rejection strategy would have regressed legitimate symlinked VHD scenarios. The final approach preserves valid symlinked VHD workflows while making restore use the mounting user’s identity.
That is a better result for users: close the privilege window without unnecessarily breaking advanced but legitimate setups.
That sounds inconsistent until the threat model is separated. VHD paths are ordinary filesystem paths and can be affected by user-controlled path tricks. Raw physical disk paths, such as
So WSL 2.7.10 does not simply change every disk restore path to impersonate the user. It changes the VHD restore case where user-controllable filesystem paths are the concern and leaves raw block-device restore on the existing privileged path.
That is a sign this was not a cosmetic patch. Microsoft targeted the identity change at the part of the disk-restore model where it actually matters.
The users and administrators who should pay attention are the ones closer to custom storage workflows:
Use:
For the running Linux kernel,
Microsoft’s WSL command documentation also lists:
to check installed WSL component versions.
If the Store path is not the desired update source, Microsoft documents the
After updating, verify the installed version:
If WSL has been running for a while and you want to force a clean restart of the WSL utility VM after updating, shut it down:
Then start your distribution again.
For organizations, the important step is not just updating one machine. It is knowing how WSL is updated across the fleet. Store delivery, Microsoft Update behavior, web downloads, preview channels, and developer-managed machines can all leave systems at different WSL versions. A fix like this is a reminder that WSL is now infrastructure, not just a convenience shell.
But it should be treated as meaningful hardening.
The bug class matters because it touches identity, path resolution, persisted state, and privileged restore behavior. Those are exactly the places where small mistakes can become important. WSL’s job is to make Linux feel natural on Windows, but that convenience depends on careful engineering at the seams: Windows tokens, Hyper-V utility VMs, filesystem paths, Linux block devices, and user-controlled configuration all meeting in the same workflow.
WSL 2.7.10 tightens one of those seams.
The practical lesson is simple: not every important WSL release comes with a new kernel version or a feature users can see. Some of the most important releases are the ones that make an old path safer, more consistent, and less surprising.
WSL 2.7.10 Is Small, but Not Trivial
WSL 2.7.10 is not a feature release in the usual sense. There is no new command-line option, no visible WSLg change, no new settings panel behavior, and no public kernel bump called out in the 2.7.10 release note. Microsoft’s release entry is deliberately short:- Pass the mounting user’s token on VHD restore
- Backported to the 2.7 release branch
- Contributor: Ben Hillis
The change belongs to the part of WSL most users never think about: the Windows-side service logic that remembers mounted disks, tears down and recreates the lightweight utility VM, and reconnects storage when WSL starts again. For everyday Ubuntu, Debian, Fedora, or Kali users who simply launch a shell, this update may pass unnoticed. For anyone using
wsl --mount --vhd, custom disk workflows, or managed developer machines where VHD paths and permissions matter, 2.7.10 is worth understanding.Microsoft’s own GitHub comparison for
2.7.9...2.7.10 shows just one commit and two files changed. That makes the release easy to summarize but also easier to misread. A one-commit WSL release can still matter when the commit sits on a Windows/Linux trust boundary.The Real Fix: VHD Restore Now Uses the Mounting User’s Token
The issue sits in the difference between a live VHD mount and a restored VHD mount.For a live
wsl --mount --vhd, WSL already performed the sensitive access-grant work while impersonating the user who requested the mount. That meant a standard user could not trick the privileged side of WSL into opening something the user could not legitimately access. If a path was swapped through a junction or symlink trick, the operation would fail with access denied rather than exposing another file.The restore path was the weaker side.
When the WSL utility VM is torn down because it has gone idle, WSL can later recreate that VM and restore disk mounts that were persisted for the current boot. According to the PR, that restore path re-attached persisted VHDs as SYSTEM without the mounting user’s token. In practical terms, WSL could re-resolve a user-controllable VHD path under a more privileged identity than the user who originally mounted it.
That is the problem 2.7.10 fixes.
The new behavior passes the mounting user’s token into the VHD restore path so that access grants and path resolution run under the same user identity that performed the original mount. That brings restore behavior back in line with the live
wsl --mount --vhd path.Why SYSTEM Re-Resolution Matters
The keyword in the original PR is TOCTOU: time-of-check/time-of-use.A TOCTOU issue appears when software checks one thing at one moment and then uses something that may have changed by the time the privileged operation happens. Filesystem paths are a classic place for this kind of bug because paths can involve symlinks, junctions, reparse points, and other redirection mechanisms.
In this case, the concern was not that a normal live VHD mount was unsafe. Microsoft’s PR explicitly explains that the live path already impersonated the mounting user. The concern was the restore path after the utility VM had been recreated.
That distinction matters. The problematic window was not “all VHD mounts are broken.” It was narrower: persisted VHD restore could re-resolve a user-controlled path as SYSTEM when the VM came back.
The fix is also narrower and cleaner than a broad “reject all symlinks” approach. Earlier discussion around the original fix notes that a handle-pinning or reparse-rejection strategy would have regressed legitimate symlinked VHD scenarios. The final approach preserves valid symlinked VHD workflows while making restore use the mounting user’s identity.
That is a better result for users: close the privilege window without unnecessarily breaking advanced but legitimate setups.
Pass-Through Disks Stay Different
One useful detail in the PR is that pass-through raw block device restore remains SYSTEM.That sounds inconsistent until the threat model is separated. VHD paths are ordinary filesystem paths and can be affected by user-controlled path tricks. Raw physical disk paths, such as
\\.\PhysicalDriveN, are different. The PR describes pass-through restore as elevation-gated and not having the same reparse-point surface.So WSL 2.7.10 does not simply change every disk restore path to impersonate the user. It changes the VHD restore case where user-controllable filesystem paths are the concern and leaves raw block-device restore on the existing privileged path.
That is a sign this was not a cosmetic patch. Microsoft targeted the identity change at the part of the disk-restore model where it actually matters.
Who Should Care About WSL 2.7.10
Most casual WSL users will not notice WSL 2.7.10 in daily work. A normal shell session, package install, Linux editor, or command-line workflow is unlikely to look different after this update.The users and administrators who should pay attention are the ones closer to custom storage workflows:
- Developers who use
wsl --mount --vhd - Teams that attach project, test, or lab VHDs to WSL
- Security-sensitive environments where local privilege boundaries matter
- Administrators managing shared or scripted WSL setups
- Users who keep VHDs under profile paths, redirected folders, symlinked paths, or other non-default locations
- Anyone troubleshooting WSL behavior after the utility VM idles out and later recreates itself
uname -r inside Linux is not enough to prove this fix is present. The relevant version check is the WSL package version from Windows.Use:
wsl --versionFor the running Linux kernel,
uname -r is still useful, but it answers a different question. It tells you which kernel your WSL2 distro is running. It does not, by itself, confirm that the Windows-side VHD restore hardening from WSL 2.7.10 is installed.How to Update and Verify
For most users, the normal update path is:wsl --updateMicrosoft’s WSL command documentation also lists:
wsl --versionto check installed WSL component versions.
If the Store path is not the desired update source, Microsoft documents the
--web-download option as a way to download the latest WSL update from GitHub rather than the Microsoft Store:wsl --update --web-downloadAfter updating, verify the installed version:
wsl --versionIf WSL has been running for a while and you want to force a clean restart of the WSL utility VM after updating, shut it down:
wsl --shutdownThen start your distribution again.
For organizations, the important step is not just updating one machine. It is knowing how WSL is updated across the fleet. Store delivery, Microsoft Update behavior, web downloads, preview channels, and developer-managed machines can all leave systems at different WSL versions. A fix like this is a reminder that WSL is now infrastructure, not just a convenience shell.
The Security Takeaway Without the Hype
Microsoft did not publish a CVE in the 2.7.10 release note, and the GitHub release does not describe this as an emergency. It should not be inflated into a panic-button event.But it should be treated as meaningful hardening.
The bug class matters because it touches identity, path resolution, persisted state, and privileged restore behavior. Those are exactly the places where small mistakes can become important. WSL’s job is to make Linux feel natural on Windows, but that convenience depends on careful engineering at the seams: Windows tokens, Hyper-V utility VMs, filesystem paths, Linux block devices, and user-controlled configuration all meeting in the same workflow.
WSL 2.7.10 tightens one of those seams.
The practical lesson is simple: not every important WSL release comes with a new kernel version or a feature users can see. Some of the most important releases are the ones that make an old path safer, more consistent, and less surprising.
Key Takeaways
- WSL 2.7.10 was released on June 26, 2026.
- The release contains one public changelog item: passing the mounting user’s token on VHD restore.
- The fix is a backport to the WSL 2.7 branch.
- The issue involved persisted VHD restore after the WSL utility VM was recreated.
- The old restore path could re-resolve a user-controllable VHD path as SYSTEM.
- The new behavior makes VHD restore use the mounting user’s identity, matching the safer live
wsl --mount --vhdbehavior. - Raw pass-through disk restore remains SYSTEM because it has a different security model.
- Most everyday WSL users will not notice a behavior change, but VHD-heavy and security-sensitive environments should update.
- Check the WSL package version with
wsl --version;uname -ralone does not confirm this Windows-side service fix. - Update with
wsl --update, or usewsl --update --web-downloadwhen the GitHub download path is preferred.
References
- Official release: Microsoft/WSL 2.7.10
Release 2.7.10 · microsoft/WSL · GitHub - Official comparison: Microsoft/WSL 2.7.9...2.7.10
Comparing 2.7.9...2.7.10 · microsoft/WSL · GitHub - Official PR: Pass the mounting user's token on VHD restore, 2.7 backport
Pass the mounting user's token on VHD restore (2.7 backport) by benhillis · Pull Request #40907 · microsoft/WSL · GitHub - Original PR: Fix disk-attach restore TOCTOU by impersonating the mounting user on VHD restore
Fix disk-attach restore TOCTOU by impersonating the mounting user on VHD restore by benhillis · Pull Request #40782 · microsoft/WSL · GitHub - Microsoft Learn: Basic commands for WSL
Basic commands for WSL | Microsoft Learn - Microsoft Learn: Release notes for WSL in the Microsoft Store
Release Notes for WSL in the Microsoft Store | Microsoft Learn
Last edited by a moderator:
