Microsoft has issued a fix for CVE-2026-57973, a Windows Subsystem for Linux 2 vulnerability that could let a locally authorized attacker tamper with data through a race condition in the WSL2 environment. The affected WSL package range is version 5.0.0.0 through versions earlier than 2.7.10, making this a prompt update for developers, administrators, and security teams that permit WSL2 on managed Windows devices.
Microsoft’s Security Response Center published the advisory on July 14, 2026. The National Vulnerability Database lists the issue as a CWE-367 time-of-check, time-of-use (TOCTOU) race condition, carrying a CVSS 3.1 score of 6.3, or Medium severity. The practical message is straightforward: WSL2 installations need to be on version 2.7.10 or newer.
The affected component is specifically Windows Subsystem for Linux 2, not the older translation-based WSL1 architecture. That distinction matters in organizations where WSL remains enabled for a mix of developer workflows, build agents, containers, and local testing environments.
Microsoft characterizes CVE-2026-57973 as requiring an authorized local attacker. There is no indication that an unauthenticated remote attacker can trigger the flaw over a network, and the published CVSS vector assigns high attack complexity. User interaction is not required once the attacker has the necessary local foothold.
The advisory’s impact rating is tampering: confidentiality and integrity are both rated High in the CVSS assessment, while availability is rated None. That does not automatically mean the flaw grants Linux root access, Windows administrator rights, or a virtual-machine escape. Microsoft has not published technical details establishing any of those outcomes, and administrators should resist filling in the blanks with worst-case assumptions.
What is clear is that a synchronization failure can cause a program to act on an object after the conditions checked earlier are no longer true. In a WSL2 context, that kind of defect can be especially relevant where Windows-hosted tooling, Linux processes, mounted file paths, or WSL-managed components cross timing-sensitive boundaries. The public description does not identify the vulnerable code path, affected file operation, or a proof of concept.
That lack of detail lowers immediate exposure to opportunistic attacks, but it does not lower the need to patch. TOCTOU defects are often difficult to exploit reliably, which is reflected in the High attack-complexity score, yet they can become more usable after researchers compare patched and unpatched releases.
On a WSL-enabled PC, check the installed package and component versions with:
Then update WSL with:
If Store delivery is unavailable or restricted, Microsoft documents a
After the update, stop currently running distributions and the WSL2 utility virtual machine so the updated components are used on the next launch:
Run
A device can have WSL installed without actively running any WSL2 distributions. Conversely, a machine that has not been used for Linux development recently may still carry an older WSL package. Inventory should therefore begin with the WSL package version, not only with whether a user currently has an Ubuntu, Debian, Fedora, or other distribution window open.
For organizations that use WSL2 as part of software engineering workflows, the affected population may include more than developer laptops. Self-hosted CI runners, build workstations, test VMs, lab systems, and jump boxes sometimes run WSL2 for automation or Linux-native tools. Those systems can be easy to overlook because WSL is often treated as a developer convenience rather than as a separately patched virtualized platform.
The immediate operational priority is modest but concrete:
The advisory’s High confidentiality and integrity ratings are more important than the absence of an availability impact. A tampering flaw is not a crash-only issue. In the wrong workflow, an attacker who can alter code, configuration, or artifacts may be able to create a longer-lived supply-chain or credential-theft problem without attracting attention through an obvious outage.
At the same time, there is no published basis for claiming that every WSL2 user is exposed to a host compromise. The scope in Microsoft’s CVSS vector remains unchanged, and the current disclosure does not establish a Windows privilege escalation or VM-boundary bypass. The right response is to update the affected WSL package, validate the version, and avoid over-interpreting sparse technical disclosures.
For most Windows users,
Microsoft’s Security Response Center published the advisory on July 14, 2026. The National Vulnerability Database lists the issue as a CWE-367 time-of-check, time-of-use (TOCTOU) race condition, carrying a CVSS 3.1 score of 6.3, or Medium severity. The practical message is straightforward: WSL2 installations need to be on version 2.7.10 or newer.
The affected component is specifically Windows Subsystem for Linux 2, not the older translation-based WSL1 architecture. That distinction matters in organizations where WSL remains enabled for a mix of developer workflows, build agents, containers, and local testing environments.
A Local Attack With High Integrity Consequences
Microsoft characterizes CVE-2026-57973 as requiring an authorized local attacker. There is no indication that an unauthenticated remote attacker can trigger the flaw over a network, and the published CVSS vector assigns high attack complexity. User interaction is not required once the attacker has the necessary local foothold.The advisory’s impact rating is tampering: confidentiality and integrity are both rated High in the CVSS assessment, while availability is rated None. That does not automatically mean the flaw grants Linux root access, Windows administrator rights, or a virtual-machine escape. Microsoft has not published technical details establishing any of those outcomes, and administrators should resist filling in the blanks with worst-case assumptions.
What is clear is that a synchronization failure can cause a program to act on an object after the conditions checked earlier are no longer true. In a WSL2 context, that kind of defect can be especially relevant where Windows-hosted tooling, Linux processes, mounted file paths, or WSL-managed components cross timing-sensitive boundaries. The public description does not identify the vulnerable code path, affected file operation, or a proof of concept.
That lack of detail lowers immediate exposure to opportunistic attacks, but it does not lower the need to patch. TOCTOU defects are often difficult to exploit reliably, which is reflected in the High attack-complexity score, yet they can become more usable after researchers compare patched and unpatched releases.
WSL Updates Are Not Always Windows Update Updates
The remediation is potentially easy to miss because modern WSL is delivered and updated as a separate package, frequently through the Microsoft Store rather than solely through monthly Windows cumulative updates. Microsoft’s WSL documentation recommends the Store-delivered version because it receives WSL feature and security updates as they become available.On a WSL-enabled PC, check the installed package and component versions with:
wsl --versionThen update WSL with:
wsl --updateIf Store delivery is unavailable or restricted, Microsoft documents a
--web-download option:wsl --update --web-downloadAfter the update, stop currently running distributions and the WSL2 utility virtual machine so the updated components are used on the next launch:
wsl --shutdownRun
wsl --version again and verify that the WSL package version is 2.7.10 or later. wsl --status is also useful for confirming the installed configuration and kernel information, while wsl --list --verbose identifies which installed distributions are actually running under version 2.A device can have WSL installed without actively running any WSL2 distributions. Conversely, a machine that has not been used for Linux development recently may still carry an older WSL package. Inventory should therefore begin with the WSL package version, not only with whether a user currently has an Ubuntu, Debian, Fedora, or other distribution window open.
The Enterprise Exposure Is Mostly About Local Footholds
CVE-2026-57973 is not the kind of vulnerability that should trigger emergency network perimeter changes. Its prerequisite is a local, authorized attacker, so the principal concern is post-compromise activity: malware running as a standard user, a malicious developer dependency, an abused local account, or a shared workstation where an attacker already has interactive access.For organizations that use WSL2 as part of software engineering workflows, the affected population may include more than developer laptops. Self-hosted CI runners, build workstations, test VMs, lab systems, and jump boxes sometimes run WSL2 for automation or Linux-native tools. Those systems can be easy to overlook because WSL is often treated as a developer convenience rather than as a separately patched virtualized platform.
The immediate operational priority is modest but concrete:
- Update all WSL2 installations to version 2.7.10 or newer and restart their WSL environments.
- Use endpoint inventory, software deployment tooling, or a PowerShell query to identify devices where
wsl --versionreports an older package. - Review systems that use WSL2 in automated build or deployment workflows, especially where standard-user processes handle sensitive source code, credentials, or release artifacts.
- Treat imported distributions and custom WSL deployments as exceptions requiring direct validation rather than assuming a routine Windows patch cycle has resolved them.
Do Not Confuse the CVSS Score With the Operational Risk
A 6.3 Medium score can look routine in a large Patch Tuesday backlog, but the score captures exploit prerequisites, not the business value of what sits behind a successful local compromise. WSL2 is frequently used where developers keep the very material an attacker wants: unreleased code, build signing processes, deployment tokens, and cloud configuration.The advisory’s High confidentiality and integrity ratings are more important than the absence of an availability impact. A tampering flaw is not a crash-only issue. In the wrong workflow, an attacker who can alter code, configuration, or artifacts may be able to create a longer-lived supply-chain or credential-theft problem without attracting attention through an obvious outage.
At the same time, there is no published basis for claiming that every WSL2 user is exposed to a host compromise. The scope in Microsoft’s CVSS vector remains unchanged, and the current disclosure does not establish a Windows privilege escalation or VM-boundary bypass. The right response is to update the affected WSL package, validate the version, and avoid over-interpreting sparse technical disclosures.
For most Windows users,
wsl --update followed by wsl --shutdown closes the immediate gap. For IT teams, the next milestone is verifying that WSL2 version 2.7.10 or later—not merely the latest Windows cumulative update—is present across the systems where Linux workloads are part of the development stack.References
- Primary source: MSRC
Published: 2026-07-14T07:00:00-07:00
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Official source: support.microsoft.com
April 2026 Windows security updates introduce protections to known vulnerable kernel drivers | Microsoft Support
April 2026 Windows security updates introduce protections to known vulnerable kernel driverssupport.microsoft.com - Official source: microsoft.com
Active attack: Dirty Frag Linux vulnerability expands post-compromise risk | Microsoft Security Blog
Dirty Frag is a newly disclosed Linux local privilege escalation vulnerability affecting kernel networking and memory-fragment handling components including esp4, esp6, and rxrpc. The vulnerability enables reliable escalation from an unprivileged user to root and may be leveraged after initial...www.microsoft.com - Related coverage: vulners.com
Microsoft Windows Subsystem for Linux (WSL2) < 2.7.10 T... - vulnerability database | Vulners.com
The version of Microsoft Windows Subsystem for Linux (WSL2) on the remote Windows host is prior to 2.7.10. It is,therefore, affected by a tampering vulnerability: Time-of-check time-of-use (toctou) race condition in Windows Subsystem for Linux all...vulners.com
