WSL is updated separately from Windows, and between 4 September and 9 October 2026 it moved fast: 2.9.10, 2.7.13, 2.9.11, 2.7.14, 2.9.12, 2.9.13, then 3.0.1, 3.0.2 and 3.0.3. The GitHub release notes do not carry CVE IDs or call anything a security advisory. Read line by line, though, a handful of entries are plainly about permissions, input validation and process hardening.
This post lists those entries and shows how to check what your developers and CI machines are actually running. Treat the list as what the release notes say, not as a vulnerability disclosure, because Microsoft did not describe impact.
What's affected
Every machine with WSL installed from the Microsoft Store or GitHub package, which in practice means most Windows developer laptops and many Windows CI runners. WSL on those machines updates on its own schedule, so versions drift.
Here is what changed, by release, from the notes on the microsoft/WSL releases page:
| Release | Date | Pre-release | Security-relevant entries |
|---|---|---|---|
| 2.7.14 | 11 Sep | No | Backport to the 2.7 branch: message structures zero-initialized, guest capability strings validated, host Plan9 shares run as the session user. |
| 2.9.12 | 14 Sep | Yes | Validates variable-length message strings. Plan9 host plugin shares run as the session user. Fixes virtiofs bind mounts that showed files as root-owned. |
| 2.9.13 | 25 Sep | Yes | Enables the RedirectionGuard process mitigation. Fixes several protocol parsing issues and a possible out-of-bounds access when pretty-printing string fields in init messages. |
| 3.0.1 | 29 Sep | No | The caller is impersonated before various filesystem operations. |
| 3.0.2 | 5 Oct | Yes | Restricts virtual disk creation access to the current user. Fixes a race condition and a potential use-after-free. Reverts the RedirectionGuard mitigation. |
| 3.0.3 | 9 Oct | No (Latest) | Commands with extra arguments are rejected. Pushing to the store is disabled by default. Kernel updated to Microsoft.WSL.Kernel 6.18.54.1. |
Two patterns stand out. First, the Plan9 host plugin and filesystem operations changed to run with the identity of the user in the session instead of a broader context. That is a classic privilege boundary fix: a service acting on behalf of a user should act as that user. Second, the 2.7.14 backport shows Microsoft carrying input validation fixes to an older branch, which matters if you pinned 2.7.x.
Also note the RedirectionGuard change. It was turned on in 2.9.13 and reverted in 3.0.2. The notes do not say why, so do not assume a reverted mitigation means the issue is gone or that it was a problem.
How to check if you're exposed
On any Windows machine:
wsl --version
wsl --status
wsl --version prints the WSL package version, the kernel version and the Windows build. Collect it across a fleet with your endpoint management tool, or from a script run by CI:
wsl --version | Select-String "WSL version"
Compare against the table. If a machine reports 2.7.13 or below on the 2.7 branch, or any 2.9.x before 2.9.12, it is missing at least some of the validation fixes above.
Inside a distribution, review what your WSL configuration exposes to Windows:
cat /etc/wsl.conf
Look for [interop], [automount] and appendWindowsPath settings. Interop lets Linux processes launch Windows executables, and Windows drives are mounted into the distro by default. A repository cloned in a Linux distribution is reachable from Windows through the wsl.localhost network path, so malware on either side can read the other.
What to do now
- Run
wsl --updateon developer machines and CI hosts. Move off any 2.7.x pin unless you have a reason, and confirm withwsl --version. - Keep pre-release builds off production CI. 2.9.12, 2.9.13 and 3.0.2 are flagged as pre-releases on GitHub. Take stable releases, which today means 3.0.3.
- In shared build environments, set
interopandappendWindowsPathto false in/etc/wsl.confunless a job needs them:
[interop]
enabled=false
appendWindowsPath=false
- Treat the WSL VM like a server in your inventory. List which developers run it, with which distributions and kernel, in whatever system tracks endpoints.
- Do not store long-lived cloud credentials inside a distribution that also mounts Windows drives. Use short-lived tokens, and rotate anything that lived in a shared
$HOME. - Read the notes yourself on each release. Microsoft did not label these entries as security fixes, so only reading them tells you.
Why it matters
WSL is a Linux VM with a Windows-aware service sitting between your files and your laptop. Every change that makes that service act "as the session user" or validate guest-provided strings is a fix at the boundary where a compromised distribution could otherwise reach the host. Developers install packages in those distributions all day, which makes them more exposed than most servers.
The release process is the other lesson. Nine releases in five weeks, two parallel branches and pre-releases mixed in means "we updated WSL" is not one fact. Version drift across a developer fleet is normal, and it is the kind of drift an inventory can answer in minutes.
Quick check
Do the WSL release notes for these versions list CVE IDs?
No. The notes describe changes, such as validating strings and restricting access, but they do not reference CVE IDs or describe impact.
Which releases between 4 September and 9 October were stable, not pre-release?
Among those listed here, 2.7.14, 3.0.1 and 3.0.3 were not flagged as pre-releases. 2.9.12, 2.9.13 and 3.0.2 were.
What does the WSL version command report?
The WSL package version, kernel version and Windows build, which you can compare with the release table above.
