CVE-2026-31431: Update WSL2 Kernel to Fix Copy Fail

CVE-2026-31431 does not prove that Microsoft’s WSL2 kernel update path is inherently too slow for enterprise use. It does prove that enterprises can no longer treat WSL as an incidental Windows feature: Store-serviced WSL is defensible only when its independent update channel is allowed, monitored, and verified across every developer endpoint, while blocked Store access, manually repeated web downloads, and legacy inbox WSL create predictable patch latency.
Microsoft described CVE-2026-31431, dubbed Copy Fail, on May 1, 2026 as a high-severity Linux kernel privilege-escalation vulnerability. The AF_ALG AEAD handling flaw matters wherever an attacker can execute unprivileged local code, because successful exploitation can elevate that code to root inside the affected Linux environment.
The WSL exposure was not merely theoretical. A Microsoft WSL GitHub issue opened April 30 reported successful exploitation on WSL 2.6.3 running kernel 6.6.87.2-microsoft-standard-WSL2 with Ubuntu 24.04. That report establishes a concrete enterprise question: not whether a general Linux vulnerability might reach WSL someday, but whether organizations can identify and replace an exposed Microsoft-supplied WSL kernel quickly enough.

Audit the Update Path Before Debating Its Speed​

The first enterprise response should be an inventory exercise, not an assumption that Windows Update has handled the problem. Administrators need to determine which WSL servicing model each endpoint is actually using, record the installed WSL and kernel versions, and then test whether the permitted update route can reach the machine.
A practical validation sequence is:

1. Run wsl --version from PowerShell or Command Prompt to record the installed WSL package and component versions. Older inbox installations may not support this command fully, which is itself a useful indicator that the endpoint needs separate classification.
2. Run wsl --status to collect the current WSL configuration and kernel information available on the device.
3. Run wsl -l -v to identify installed distributions and confirm whether they use WSL 1 or WSL 2. CVE-2026-31431 concerns the Linux kernel used by WSL2, so inventories that merely report “WSL enabled” are insufficient.
4. From inside each relevant WSL2 distribution, run uname -r to capture the kernel release actually presented to the Linux environment. The reported vulnerable configuration used 6.6.87.2-microsoft-standard-WSL2.
5. On Store-serviced systems, run wsl --update through the organization’s approved deployment or remediation process, then verify the resulting version and kernel rather than treating a successful command exit as proof of compliance.
6. Where Microsoft Store access is unavailable, run wsl --update --web-download through an authorized administrative workflow. Microsoft warns that this route must be manually repeated for every new release, so it cannot safely remain an undocumented user task.
7. Separately update and assess the Linux distribution’s packages using its native package manager. For Ubuntu and Debian environments, that normally means running sudo apt update followed by the organization’s approved upgrade procedure.

These checks should be collected centrally wherever possible. A security team that cannot answer how many WSL2 devices exist, which kernel each one runs, and when each last received a platform update does not have a patching process; it has a command developers may or may not run.
Microsoft has not supplied a fixed WSL version for CVE-2026-31431 in the facts available here, so administrators should not infer that any arbitrary version newer than WSL 2.6.3 is remediated. The correct acceptance criterion is a Microsoft-confirmed patched release or kernel, followed by endpoint verification.

---

Store-Serviced WSL Breaks Free of Patch Tuesday​

Modern Store-serviced WSL has a major security advantage: Microsoft services it separately from the Windows operating-system image. A WSL platform or kernel release therefore does not necessarily need to wait for the next monthly Windows cumulative update.
That separation can reduce exposure time, but only when the enterprise permits the servicing channel to function. Blocking the Microsoft Store globally without creating an alternative WSL update workflow turns architectural independence into operational isolation.
This is the central distinction in assessing Microsoft’s kernel update path. Release velocity belongs to Microsoft, but deployment latency belongs to the enterprise once an update is available. An organization can have a fast upstream channel and still operate a slow fleet because proxy rules, application controls, change freezes, disconnected networks, or ownership gaps prevent the package from reaching endpoints.
Legacy inbox WSL follows a different path. Microsoft documents that inbox WSL is updated through Windows Update, tying its servicing more closely to the Windows OS lifecycle. A mixed estate containing Store-serviced WSL, inbox WSL, and web-download installations therefore has multiple clocks rather than one universal WSL patch deadline.
Enterprises should classify those populations explicitly:

• Store-serviced WSL endpoints need proof that the Store update route remains reachable and that approved releases are installed.
• Inbox WSL endpoints need Windows Update compliance data and a plan for handling the slower, OS-linked servicing model.
• Web-download endpoints need a recurring deployment mechanism because Microsoft says the command must be repeated for every release.
• Unmanaged or unidentified installations should be treated as patch-status unknown until their WSL and kernel versions are collected.

The web-download option is useful for restricted environments, but it is an alternative transport mechanism, not an enterprise management system. Running wsl --update --web-download once during deployment does not enroll the machine in future updates.

Two Patch Planes Share One Developer Workstation​

CVE-2026-31431 sits in the WSL2 kernel, which makes the WSL platform update route the immediate focus. That does not collapse WSL security into a single Windows-managed patch plane.
Microsoft’s enterprise guidance states that Windows management tools do not currently manage updates and patching for Linux distributions and their packages. Windows Update also does not update the contents of installed WSL distributions. An organization may therefore patch the Microsoft-supplied WSL kernel while leaving Ubuntu, Debian, or another distribution’s userspace packages behind.
The reverse failure is equally plausible. A development team may diligently run its distribution’s package updates while remaining on an old WSL platform and Microsoft kernel because nobody owns wsl --update.
This creates at least two distinct responsibilities:

• The Windows endpoint team must manage the WSL package, virtualization-facing components, and Microsoft-supplied kernel.
• The Linux, platform-engineering, or developer-experience team must manage distribution packages, repositories, approved images, and userspace vulnerability exposure.

Neither team can assume the other has covered both layers. Microsoft recommends Linux configuration-management tools for monitoring and managing Linux userspace, reflecting the current gap in Windows-native distribution patching.
This split also changes incident response. A report that an endpoint’s Ubuntu packages are current does not establish that its WSL2 kernel is safe. Conversely, a current WSL package says nothing conclusive about applications and libraries installed inside the distribution.
WindowsForum’s continuing coverage of CVE-2026-57968, CVE-2026-57973, and Microsoft Linux kernel exposure across Azure and WSL reinforces the larger pattern: WSL is now a recurring security-maintenance surface, not a one-time optional feature deployment. Each new issue makes unmanaged update channels harder to defend as a temporary exception.

---

Trust Requires Evidence From the Endpoint​

Enterprises should measure WSL patch performance with the same discipline used for browsers, developer runtimes, and endpoint-security agents. The meaningful metric is not the date Microsoft publishes a release; it is the interval until the last in-scope WSL2 endpoint is verified on an approved kernel.
That requires a defined owner, an inventory source, a deployment mechanism, an exception process, and a compliance deadline. It also requires testing against realistic enterprise controls: standard-user accounts, Store restrictions, authenticated proxies, application allowlists, remote workers, and devices that miss normal maintenance windows.
Organizations should also decide what happens when the normal channel fails. A defensible policy might temporarily restrict WSL use on an endpoint that cannot obtain a required kernel update, particularly where developers execute untrusted repositories, third-party build scripts, or other locally supplied code.
Copy Fail requires local unprivileged code execution rather than offering a standalone remote entry point. That prerequisite lowers some exposure scenarios, but it does not make the flaw irrelevant on developer systems designed to download and execute code from many sources. Root access inside WSL can still threaten the confidentiality and integrity of the Linux development environment and its accessible data.
The reported WSL 2.6.3 exploitation should therefore be used as a validation case. Security teams can search for that package and kernel combination, but they should avoid reducing the audit to one historical version. The durable control is continuous version visibility and a repeatable update route.

Frequently Asked Questions​

Does Windows Update automatically patch every WSL2 installation?​

No. Microsoft documents separate servicing models: Store-serviced WSL receives updates independently of the Windows OS image, while legacy inbox WSL is updated through Windows Update.

Is wsl --update --web-download equivalent to automatic Store servicing?​

No. It provides an update route when Store access is unavailable, but Microsoft says it must be manually repeated for each new release. Enterprises need automation or a recurring operational procedure around it.

Does updating Ubuntu fix the WSL2 kernel?​

Not necessarily. Distribution package updates and the Microsoft-supplied WSL platform and kernel are separate patch planes, so both must be assessed.

Is WSL 2.6.3 the only version enterprises should investigate?​

It is the specific version in the April 30 exploitation report, paired with kernel 6.6.87.2-microsoft-standard-WSL2 and Ubuntu 24.04. Administrators should still verify Microsoft’s confirmed remediation boundary rather than assuming all other versions are safe.
Microsoft’s WSL servicing architecture can support faster-than-monthly kernel remediation, but enterprises only benefit when that channel survives their own controls. The next milestone is not another promise about update speed; it is a fleet-wide answer showing which WSL model every endpoint uses, which kernel it runs, and how quickly the next security release will actually reach it.

---

References​

1. Primary source: learn.microsoft.com
   
   

   Application Updates | Microsoft Learn

   Learn about how apps can be updated in Windows IoT Enterprise.

   learn.microsoft.com
2. Independent coverage: github.com
   
   

   CVE-2026-31431 (Copy Fail - Linux kernel bug) · Issue #40365 · microsoft/WSL · GitHub

   Windows Version Microsoft Windows [versão 10.0.26200.8246] WSL Version 2.6.3.0 Are you using WSL 1 or WSL 2? WSL 2 WSL 1 Kernel Version 6.6.87.2-1 Distro Version Ubuntu 24.04 Other Software None needed. Repro Steps Fully updated WSL2 is ...

   github.com
3. Independent coverage: microsoft.com
   
   

   CVE-2026-31431: Copy Fail vulnerability enables Linux root privilege escalation across cloud environments | Microsoft Security Blog

   A high-severity Linux vulnerability, “Copy Fail” (CVE-2026-31431), enables root privilege escalation across cloud environments and Kubernetes workloads. With a working exploit already in the wild, organizations should act quickly to detect, mitigate, and reduce risk.

   www.microsoft.com
4. Independent coverage: devblogs.microsoft.com
   
   

   The Windows Subsystem for Linux in the Microsoft Store is now generally available on Windows 10 and 11 - Windows Command Line

   Today the Windows Subsystem for Linux (WSL) in the Microsoft Store is dropping its “Preview” label and becomes generally available with our latest

   devblogs.microsoft.com
5. Primary source: WindowsForum
   
   

   CVE-2026-57968: Update WSL2 to 2.7.8 to Block Privilege Escalation | Windows Forum

   Microsoft has patched CVE-2026-57968, a high-severity local elevation-of-privilege flaw in Windows Subsystem for Linux 2, by shipping WSL version 2.7.8 and...

   windowsforum.com

 

[ChatGPT]

A reported Linux-kernel flaw in WSL should be handled on a separate WSL servicing track: inventory the WSL stack and kernel on developer PCs, run the supported WSL update command, and retain proof of the resulting versions. Do not treat a successful Windows Patch Tuesday cycle—or the alleged Copy Fail/CVE-2026-31431 report—as proof that a WSL2 endpoint is fixed; this guidance applies to Windows 10 and Windows 11 PCs running WSL, particularly developer endpoints using WSL2.

Why the WSL patch question is different​

WSL is both a Windows feature and a separately versioned product stack. Microsoft documents wsl --version, wsl --status, and wsl --update for identifying and updating that stack. Its WSL release material also presents versioned WSL releases separately from Windows OS builds.
That distinction changes the incident-response question. A Windows cumulative update may still matter for the host, but it is not sufficient evidence that the Linux kernel currently reported by WSL has changed. Conversely, a Linux vulnerability claim is not automatically evidence that every WSL installation is affected.
IT needs a repeatable record for each endpoint in scope:

1. Whether WSL is installed and used on the device.
2. The WSL version and kernel information reported before an update attempt.
3. The WSL version and kernel information reported after the update attempt.
4. Whether Microsoft has published an advisory that maps a reported issue to affected and fixed WSL versions.

The alleged Copy Fail/CVE-2026-31431 report illustrates why this evidence standard matters. The cited WSL issue material is a user-submitted report and reproduction claim, not a complete Microsoft security advisory. As provided, the issue excerpt contains no Microsoft identification of an affected WSL version range, a fixed kernel version, or a security-release mapping. Administrators can update WSL and reduce risk where appropriate, but they should not state that a particular release is confirmed fixed unless Microsoft publishes that mapping.
WindowsForum user discussions have repeatedly made the operational point behind this guide: WSL should not be treated as an incidental Windows feature on enterprise developer systems. The forum’s coverage of the alleged Copy Fail/CVE-2026-31431 report argues for tracking WSL2 kernel updates as part of endpoint patch management. Earlier WindowsForum discussions of CVE-2025-38040, CVE-2025-26675, and CVE-2025-24084 likewise reflect concern that Linux-kernel exposure and Windows-integrated development environments require explicit ownership and verification.
For related background on the broader servicing problem, see WindowsForum’s coverage of Microsoft Linux kernel exposure across Azure and WSL.

How to inventory and update WSL developer endpoints now​

Run the following commands from Command Prompt, PowerShell, or Windows Terminal on every endpoint in scope. Record the output in an auditable ticket, asset record, or endpoint-management workflow.

1. Check the installed WSL stack version​

wsl --version
Record the complete output. Microsoft documents this command for viewing WSL version information and component versions.
The output is useful because a Windows build number alone does not describe the installed WSL stack. Keep the original output rather than reducing it to a manually entered summary; full command output is easier to compare later if Microsoft publishes a fixed-version requirement.

2. Check WSL status and reported kernel information​

wsl --status
Record the complete output, including the kernel information it reports. On systems where command behavior differs because of the installed WSL implementation, preserve the actual output and note the device’s Windows version and WSL state rather than guessing at an equivalent result.
These first two commands create the pre-update evidence record. They do not, by themselves, establish whether the alleged Copy Fail/CVE-2026-31431 report applies to the device. They establish what was present when the assessment was performed.

3. Apply the supported WSL update command​

wsl --update
Allow the command to complete and capture its result. Microsoft documents wsl --update as the command to update WSL. That makes it an appropriate update action during a WSL assessment, but the command result alone is not vulnerability-specific proof of remediation.
Do not close a security ticket merely because the command was started, completed without an obvious error, or reported no further action. The remaining verification step is necessary because the organization still needs a before-and-after record of the installed WSL and kernel information.
If the command fails, capture the exact error text, the date and time, and the output from wsl --version and wsl --status. Route the failure through the team responsible for endpoint software servicing rather than substituting unsupported manual procedures.

4. Re-run the version and status checks​

wsl --version
wsl --status

Compare the post-update output with the pre-update record. Record whether the WSL version or reported kernel information changed, whether the update command completed, and whether a follow-up action is required.
This is the practical value of the process: it preserves evidence that an update was attempted and shows the installed state afterward. If Microsoft later identifies affected and fixed WSL versions for the alleged Copy Fail/CVE-2026-31431 report, the organization can compare its stored endpoint evidence against that official mapping without reconstructing the response from memory.
A useful asset record includes:

• Device name and assigned user or team.
• Date and time of the check.
• Pre-update output from wsl --version.
• Pre-update output from wsl --status.
• Result of wsl --update.
• Post-update output from wsl --version.
• Post-update output from wsl --status.
• Whether the endpoint runs development, testing, or automation workloads that merit priority review.
• Ticket number, exception status, and owner for any unresolved update failure.

This record is more defensible than recording only the Windows build number or accepting a user statement that WSL is current.

What should count as a confirmed fix?​

An update result is not the same thing as a vulnerability-specific closure. For the alleged Copy Fail/CVE-2026-31431 report, use the following evidence standard.

• Confirmed affected: Microsoft publishes an advisory or other official identification that places the deployed WSL or kernel version in an affected range.
• Confirmed fixed: Microsoft publishes a fixed WSL or kernel version, and the endpoint’s recorded post-update version evidence meets that requirement.
• Not yet confirmed: A public issue, proof-of-concept claim, forum discussion, blog post, or upstream discussion exists, but no Microsoft mapping identifies affected and fixed WSL releases.

No such Microsoft identification is present in the cited issue excerpt as provided. That absence does not prove the report is harmless, but it does mean administrators should not transform a user-submitted CVE label into a definitive Microsoft vulnerability statement.
This distinction is especially important for enterprise reporting. “Update attempted” is a valid operational status. “WSL version recorded after update” is a valid verification status. “CVE remediated” requires a published vendor mapping between the issue and the installed version.
Microsoft’s versioned WSL release information should be retained alongside any future security advisory. Do not infer a fix from unrelated release-note changes, release timing, a higher Windows OS build, or a general statement that WSL is updated.

When should IT apply interim controls?​

Use interim controls when the organization considers the reported issue relevant to its risk posture but cannot yet prove a fixed version is installed. These measures are risk-reduction decisions, not proof that the underlying issue is patched.

Restrict untrusted code execution in WSL​

Prioritize review of devices where users routinely run unreviewed repositories, downloaded scripts, proof-of-concept code, externally supplied build inputs, or automation from third-party sources.
During the assessment window, tell users not to run vulnerability proof-of-concept material or other untrusted code in WSL unless the activity is specifically approved for a controlled security-testing purpose. This is a practical temporary control that can be applied without claiming that every WSL installation is affected.
Security and developer-platform teams should identify high-value developer endpoints first, including systems used for release engineering, sensitive source work, cloud-administration tasks, or builds that consume externally supplied code. The purpose is prioritization: verify the WSL state on systems where uncertainty has the greatest operational consequence.

Review whether WSL is needed on higher-risk endpoints​

For systems that do not require WSL during the response period, IT can review whether temporarily suspending WSL-dependent work is appropriate under local policy. Any change that affects developer workflows should be coordinated with the endpoint owner and development leadership.
The supplied material does not establish a particular Windows feature-disablement procedure or the security effect of disabling a feature. Organizations should therefore use their own approved endpoint-management procedures rather than treating this guide as instructions for changing Windows features.

Treat the report as an endpoint-management issue​

The immediate task is not to speculate about the full impact of a reported WSL compromise. It is to identify systems using WSL, update the WSL stack through the supported command, preserve the post-update state, and apply proportionate controls while awaiting official version guidance.
That approach avoids two mistakes: dismissing WSL because it is associated with developer tooling, and overstating a user-submitted report before Microsoft provides an advisory or version mapping.

How should patch ownership be divided?​

Assign clear ownership rather than leaving WSL between desktop engineering and Linux operations.

• Windows endpoint engineering should own WSL application servicing, deployment approval, endpoint inventory, update execution, and verification records.
• Developer platform or Linux engineering should advise on WSL usage, workflow impact, development-tool dependencies, and systems that need priority handling.
• Security operations should define risk prioritization, monitor Microsoft for an official affected-and-fixed version mapping, and determine when interim controls are needed.
• Endpoint users should provide workload context but should not be asked to self-attest that WSL is current without captured command output.

WindowsForum’s user reports support this ownership model. The discussion around the alleged Copy Fail/CVE-2026-31431 report emphasizes that enterprises need a visible WSL update process. The forum’s later report concerning a claimed WSL 2.7.8 fix for CVE-2026-57968 also demonstrates why version-specific closure must depend on an actual advisory and version mapping, not on an assumption that every reported issue follows the same servicing pattern.

Frequently Asked Questions​

Does Windows Update prove that a WSL kernel vulnerability is fixed?​

No. Windows patch compliance and WSL version verification are separate checks. Use wsl --version and wsl --status to record the installed WSL state, then compare that evidence with a Microsoft advisory if one is published.

Does wsl --update prove that the alleged Copy Fail/CVE-2026-31431 report is fixed?​

No. It is the supported command for updating WSL, but it does not establish that a specific reported vulnerability is remediated. Closure requires Microsoft to identify affected and fixed versions and the endpoint record to meet the fixed-version requirement.

Should every PC with WSL installed be treated as exposed?​

Not automatically. WSL presence is an inventory fact, not a vulnerability determination. Confirm the installed WSL and reported kernel information, then wait for or apply any official affected-version mapping.

Is an “up to date” message sufficient evidence for a security closure?​

No. Preserve the command result, but use recorded version output and Microsoft’s published advisory information for a vulnerability-specific decision.
Until Microsoft supplies an affected-version range and fixed release for the alleged Copy Fail/CVE-2026-31431 report, the defensible response is to update WSL, retain pre- and post-update version evidence, prioritize higher-risk developer endpoints, and keep WSL on its own patch and verification track.

---

References​

1. Primary source: learn.microsoft.com
   
   

   Troubleshooting Windows Subsystem for Linux | Microsoft Learn

   Provides detailed information about common errors and issues people run into while running Linux on the Windows Subsystem for Linux.

   learn.microsoft.com
2. Independent coverage: github.com
   
   

   CVE-2026-31431 (Copy Fail - Linux kernel bug) · Issue #40365 · microsoft/WSL · GitHub

   Windows Version Microsoft Windows [versão 10.0.26200.8246] WSL Version 2.6.3.0 Are you using WSL 1 or WSL 2? WSL 2 WSL 1 Kernel Version 6.6.87.2-1 Distro Version Ubuntu 24.04 Other Software None needed. Repro Steps Fully updated WSL2 is ...

   github.com
3. Primary source: WindowsForum
   
   

   CVE-2026-31431: Update WSL2 Kernel to Fix Copy Fail | Windows Forum

   CVE-2026-31431 does not prove that Microsoft’s WSL2 kernel update path is inherently too slow for enterprise use. It does prove that enterprises can no...

   windowsforum.com