Microsoft WSL EUVD-2026-100195

Exploitation requires local access to a Windows host that has the Windows Subsystem for Linux (WSL2) component installed and running a build earlier than 3.0.1, plus an existing authorized/authenticated local session (CVSS PR:L) - it is not remotely reachable and needs no user interaction. The key limiting factors are: WSL2 must be present and enabled (an opt-in Windows feature, not active on default consumer installs), the attacker must already have a foothold as a local authorized user, and only confidentiality is affected (no integrity or availability impact). The disclosure stems from use of an uninitialized resource (CWE-908), so impact depends on whatever residual data happens to occupy that memory, making the leak opportunistic rather than precisely controllable.

This is a moderate, locally-exploitable information disclosure flaw that signals a patch-management priority rather than an emergency. The CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N, base 6.5) is internally consistent: exploitation requires local access and some level of existing authorization (PR:L), has low attack complexity, needs no user interaction, and yields high confidentiality impact with a scope change (S:C) - meaning the leaked uninitialized memory can cross a security boundary (e.g. from the WSL guest/user context into data it should not see). All exploitation signals point the same direction and reinforce a low-urgency reading: CISA SSVC reports Exploitation=none, Automatable=no, and Technical Impact=partial, and there is no CISA KEV listing and no public POC. No EPSS score was supplied in the input, so probabilistic exploitation likelihood cannot be quantified here. There is no conflict between the signals - local vector, partial impact, no automation, and no observed exploitation all agree this is a real-but-low real-world risk, appropriate for routine patching rather than out-of-band response.

A local authenticated user on a Windows host running a vulnerable WSL2 build (prior to 3.0.1) triggers the affected WSL code path that returns uninitialized memory, reading back residual data the operating system failed to clear. Because the scope is changed (S:C), the leaked contents may originate from a more privileged or separate security context, aiding further reconnaissance. No public exploit code has been identified at time of analysis, and exploitation requires low complexity but local access.