Microsoft has disclosed a security vulnerability in the Linux kernel that it says affects its Azure Linux distribution, but the company’s advisory stops short of clearing other Microsoft-supplied kernels—including the one that ships with Windows Subsystem for Linux 2 (WSL2) on millions of Windows PCs. CVE-2025-37877, published through Microsoft’s Security Response Center, marks one of the first high-profile tests of the company’s new transparency mechanism for open-source components, yet it also highlights the uncertainty faced by organizations that run Microsoft’s various Linux kernel flavors.
The vulnerability, details of which remain sparse, stems from a flaw in an open-source library used by the Linux kernel. According to Microsoft’s advisory, Azure Linux—the company’s own lightweight distribution used in Azure cloud and AKS (Azure Kubernetes Service)—includes the vulnerable code and is therefore considered affected. No fix was immediately available at the time of the disclosure, and the full technical description of the bug is still under embargo.
What’s conspicuous is not what the advisory says, but what it doesn’t say. Microsoft’s statement explicitly notes that if the vulnerability is found to impact other products, the CVE record will be updated. This leaves the security status of Microsoft’s other Linux kernel artifacts—most notably the WSL2 kernel that runs natively on Windows 10 and Windows 11, but also CBL‑Mariner images, the linux‑azure kernel, and various Marketplace images—in a state of limbo.
What we know about CVE-2025-37877
Microsoft’s Security Update Guide entry for CVE-2025-37877 is succinct. It explains that Azure Linux “includes this open‑source library and is therefore potentially affected.” The advisory does not provide a Common Vulnerability Scoring System (CVSS) score, nor does it detail the attack vector, complexity, or impact. However, independent researchers familiar with similar kernel‑level vulnerabilities note that such flaws often lead to local privilege escalation or denial‑of‑service attacks, making shared and multi‑tenant environments especially risky.
The heart of the advisory is the introduction of CSAF/VEX (Common Security Advisory Framework / Vulnerability Exploitability eXchange) attestations. Microsoft began publishing these machine‑readable documents in October 2025 as part of a broader transparency push for open‑source components. For CVE‑2025‑37877, the CSAF/VEX record explicitly lists specific Azure Linux (azl3) kernel artifacts as “Known Affected,” while a blanket “no fix available” status applies. This is the only Microsoft product family that has been inventoried and attested so far.
Why Windows WSL2 users should pay attention
If you use Windows Subsystem for Linux 2, you are running a Microsoft‑maintained Linux kernel that gets updated through Windows Update. That kernel is built from the same upstream Linux sources as Azure Linux (both derive from CBL‑Mariner) and can share kernel configuration choices. In other words, the WSL2 kernel may very well include the same vulnerable component.
Microsoft has not yet assessed whether the WSL2 kernel is affected. The company’s phased inventory approach means that Azure Linux was the first product to be mapped because it is the easiest to inventory—it is a single, controlled distribution. WSL2, on the other hand, is shipped in multiple kernel versions across different Windows releases, and its build configuration is not identical to that of Azure Linux. The absence of a “Known Affected” label for WSL2 does not mean it is safe; it means Microsoft hasn’t completed the audit yet.
For the millions of developers, IT professionals, and enthusiasts who use WSL2 daily, the risk is tangible. A local attacker with a low‑privilege WSL shell could potentially trigger the vulnerability to crash the kernel—or worse, escalate privileges. While the exploit would require code execution inside the WSL environment, that’s a bar easily cleared on developer workstations where untrusted code is run, or on shared systems with multiple users.
The bigger picture: how Microsoft is changing vulnerability disclosure
CVE‑2025‑37877 is one of the first examples of Microsoft operationalizing the CSAF/VEX framework. Historically, when a Linux kernel vulnerability was discovered, Microsoft’s response often lagged behind that of dedicated Linux distributors. With Azure Linux and CBL‑Mariner under its wing, the company now has a responsibility to provide clear, machine‑readable vulnerability information for its own kernel artifacts. The rollout of CSAF/VEX in October 2025 was a direct response to that.
The main benefit of CSAF/VEX is that security teams can automatically ingest advisory data into their vulnerability management workflows via JSON feeds. For this CVE, Microsoft’s VEX document encodes which specific product IDs are “known affected.” If Microsoft later determines that, say, the WSL2 kernel version 5.15.x shipped in Windows 11 24H2 is also vulnerable, it can append that product ID to the VEX and mark it “known affected” or “under investigation.” Automation tools that poll the CSAF feed will then alert administrators.
Microsoft explicitly states: “If impact to additional products is identified, we will update the CVE to reflect this.” This means the list of affected Microsoft products is a living document, and WSL2 could be added at any time.
What you should do right now
For Azure Linux users
If you run Azure Linux instances in the cloud or on‑premises, treat this as a high‑priority issue. Microsoft has confirmed the vulnerability exists in your kernel. Follow the official patch schedule as it becomes available. In the meantime, limit local access to those systems, restrict container privileges, and ensure that only trusted users have shell access.
For WSL2 users on Windows
-
Check your WSL kernel version. Open PowerShell or Command Prompt and run:
wsl.exe --status
Look for the kernel version reported. The default Microsoft‑provided kernel version number (e.g., 5.15.x) will help you track advisories. If you’re running a custom kernel that you built yourself, you’ll need to apply the upstream fix when it’s released. -
Understand your exposure. If you’re using the default WSL2 kernel from Microsoft, you are relying on Microsoft to deliver a patched kernel via Windows Update. There is no action you can take until that happens, but you can reduce risk by avoiding running untrusted code inside WSL during this period.
-
Consider a custom kernel (advanced). If the upstream Linux kernel receives a fix and your use case requires immediate protection, you can compile a custom WSL2 kernel with the fix included. Microsoft provides instructions for using a custom kernel. However, this is a stopgap measure and not recommended for most users.
-
Monitor Microsoft’s advisory. Bookmark the MSRC page for CVE‑2025‑37877 and check back for updates. The entry will be revised if WSL2 or other products are added to the affected list.
For IT administrators and security teams
- Inventory all Microsoft‑supplied Linux kernels in your environment. This includes Azure Linux VMs, CBL‑Mariner hosts, AKS node images, and any Windows endpoints where WSL2 is enabled.
- Automate checks using the CSAF/VEX feed. Ingest Microsoft’s VEX JSON into your vulnerability management platform and set alerts for any new product IDs marked “known affected.”
- Verify kernel configurations manually if you suspect a host might be at risk. The general checklist involves identifying the running kernel version, checking if the vulnerable subsystem is compiled in, and seeing if related modules are loaded. Microsoft has not disclosed which kernel subsystem is involved in CVE‑2025‑37877, so such checks are speculative for now. Once details emerge, you can use commands like
grep -E 'CONFIG_XYZ' /boot/config-$(uname -r)to confirm exposure.
Outlook: what comes next
CVE‑2025‑37877 is a litmus test for Microsoft’s new transparency promises. The company’s commitment to update the advisory if other products are found vulnerable means that the next few weeks are critical. Security researchers and the open‑source community are likely digging into the vulnerability’s details, and upstream Linux maintainers may already be working on a patch. Once the embargo lifts and technical specifics are released, Microsoft will be under pressure to quickly assess and report on WSL2, linux‑azure, and other kernels.
For Windows users specifically, the episode underscores that WSL2 is not a sandbox; it is a full Linux kernel running on the same hardware, and its security posture affects the entire system. Keeping an eye on Microsoft’s CSAF/VEX outputs and the CVE page will be essential until the company provides explicit guidance.