Loading story…
Microsoft has made WSL Containers generally available, enabling organizations to build, run, and deploy Linux containers directly through Windows Subsystem for Linux. The release adds the wslc.exe command-line utility, a container.exe alias, and APIs allowing native Windows applications to manage Linux containers. Operational capabilities include restart support, file copying, health checks, mounts, network-connection management, configurable storage, and event monitoring; it also integrates with VS Code Dev Containers and Aspire.
For enterprise governance, Microsoft Intune can enable or disable WSL Containers and limit image downloads to approved registries. Microsoft Defender for Endpoint's WSL plugin provides visibility into container processes, files, and network activity and correlates telemetry with the Windows host. Docker Compose compatibility is not yet available, but Microsoft is developing a planned wsl compose up capability, while also reporting up to twice-faster Windows-file access from Linux environments.
See real exploitation activity before you spend the cycle.
1 event from the most recent confirmed update back to the earliest known activity.
Microsoft announced WSL Containers' general availability, enabling Linux containers to be built, run, and deployed directly on Windows through WSL. The release includes the wslc.exe tool and native application APIs, operational container capabilities, Intune policy controls, and Defender for Endpoint visibility for container activity.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
See real exploitation activity behind this advisory so you can triage it against everything else in the queue.
3 references tracked. Mallory keeps watching after this page renders.
helpnetsecurity.com
Open sourcebleepingcomputer.com
Open sourceblogs.windows.com
Open sourceMap indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
SpecterOps research highlighted that **Windows Subsystem for Linux 2 (WSL2)** can be abused as a stealthy execution and persistence layer on Windows endpoints because each WSL2 distribution runs as its own **Hyper-V VM** with a separate Linux filesystem and processes. Attackers can inject a beacon object file into an installed WSL2 distro to execute arbitrary commands, read files, and pivot into a Linux environment while many endpoint tools primarily observe only a short-lived `wsl.exe` process on the Windows side. The research also noted that the `$WSL` share and in-guest activity may not be scanned or instrumented by multiple security products, degrading common alerting rules and enabling longer dwell time and harder incident investigations. Operationally, this tradecraft allows intruders to run Linux utilities “out of sight” of traditional Windows-focused telemetry, potentially supporting internal reconnaissance, lateral movement, credential access, and data staging from within the WSL2 guest while maintaining access to corporate resources. The reporting recommends expanding defensive coverage to include **WSL2 activity monitoring and logging** (beyond `wsl.exe` process starts) to reduce blind spots created by the Windows/Linux boundary and to improve detection of malicious tooling and persistence inside WSL2 distributions.
Jun 29, 2026
Researchers reported that **Windows Subsystem for Linux 2 (WSL2)** can be abused to stage malware payloads while evading much of the visibility provided by Windows-native telemetry. Unlike WSL1, which maps Linux activity into the Windows process model, WSL2 runs a full Linux kernel inside a lightweight Hyper-V VM with its own process space, filesystem, and network stack. As a result, network activity initiated inside WSL2 may not appear in Windows tools such as Sysmon, creating a gap for defenders trying to reconstruct attacker behavior. The reporting shows that when a process inside WSL2 writes files into the Windows filesystem through `/mnt/c/`, the resulting activity is attributed on the Windows side to **`DllHost.exe`** via the Plan 9 (`9P`) proxy layer and `vp9fs.dll`, rather than to the originating Linux process. That split obscures the attack chain and turns payload staging into an indirect execution problem, although launching Windows binaries from WSL remains visible because normal Windows processes are created with **`wsl.exe`** as the parent. Defenders were advised to use outcome-based detections, including monitoring for unexpected **`wsl.exe`** execution and suspicious **`DllHost.exe`** creation of executable or script files in user-writable paths such as `Users\Public`, `ProgramData`, and `Windows\Temp`.
Jun 29, 2026
Zero Day Initiative disclosed two **Docker Desktop for Windows** privilege-escalation flaws after Docker rejected the reports as outside its threat model. The first issue, tracked as **ZDI-26-258** / `ZDI-CAN-27229`, affects the `extension-manager` component and is caused by an exposed dangerous function in Docker Extensions. ZDI said an attacker who can already execute high-privileged code inside a container could exploit the flaw to run arbitrary code on the Windows host as **SYSTEM**. The advisory lists no assigned CVE and a **CVSS 8.2** score, and credits **Nitesh Surana of TrendAI Research** with the discovery. A second advisory, **ZDI-26-260** / `ZDI-CAN-27571`, describes an uncontrolled search path issue in the Docker Desktop `system/editor` endpoint caused by execution of a program from an unsecured location. ZDI said exploitation requires an attacker to first escape the container and execute high-privileged code inside the Docker **Hyper-V VM**, after which arbitrary code can be run on the host in the context of the current user; the flaw carries a **CVSS 7.5** score. The issue was reported to Docker in July 2025 by **Nitesh Surana and Nelson William Gamazo Sanchez of TrendAI Research**, but was later published as a 0-day after the vendor declined to address it because it depended on prior privileged access.
Jun 29, 2026