Microsoft has publicly confirmed that its Azure Linux distribution is impacted by CVE-2025-50104, a denial-of-service vulnerability in the MySQL database server. While the flaw is rated low severity with a CVSS score of 2.7, Microsoft’s use of new machine-readable VEX (Vulnerability Exploitability eXchange) attestations has introduced uncertainty: the company has only attested Azure Linux as affected, leaving the status of other in-house Linux products—such as the Windows Subsystem for Linux 2 (WSL2) kernel and various Azure VM images—as unverified, despite the fact they may also include MySQL components.

The Flaw: What CVE-2025-50104 Actually Is

Oracle’s July 2025 Critical Patch Update (CPU) disclosed CVE-2025-50104, a vulnerability in the DDL (Data Definition Language) component of the MySQL Server. An attacker with high privileges can trigger a denial-of-service condition, causing partial service disruption. The vulnerability does not compromise data confidentiality or integrity; it only affects availability.

Key characteristics:

  • CVSS 3.1 Base Score: 2.7 (Low)
  • Attack Vector: Network (AV:N)
  • Privileges Required: High (PR:H)
  • User Interaction: None (UI:N)
  • Impact: Availability only (partial denial of service)

Oracle’s advisory listed affected MySQL versions up to 8.0.42, and corresponding 8.4.x and 9.x series. The fix was included in MySQL 8.0.43 and later releases. Major Linux distributions—including Ubuntu and Red Hat—quickly incorporated the patch into their package repositories.

Microsoft’s Response and the VEX Attestation Model

In its Security Update Guide, Microsoft acknowledged the vulnerability and stated that its Azure Linux distribution includes the affected open-source MySQL library and is therefore “potentially affected.” This advisory came alongside Microsoft’s broader rollout of CSAF (Common Security Advisory Framework) and VEX documents, which began in October 2025.

The MSRC FAQ for this CVE reads:

Azure Linux includes the implicated open-source library and is therefore potentially affected. Microsoft is committed to transparency in this work which is why we began publishing CSAF/VEX in October 2025. If impact to additional products is identified, we will update the CVE to reflect this.

This statement is deliberate: it confirms Azure Linux as a carrier, but it doesn’t claim that no other Microsoft product could be affected. The VEX program is being rolled out in phases, starting with Azure Linux, and Microsoft has promised to add more products over time.

The Attestation Gap: Why Other Microsoft Linux Artifacts Remain a Question Mark

Microsoft distributes many Linux-based artifacts beyond the Azure Linux distribution:

  • WSL2 kernels and user-space utilities
  • Azure VM images and kernel packages (including the linux-azure kernel family for AKS nodes)
  • Marketplace images and container images that may bundle MySQL or derived libraries

While these artifacts do not necessarily include a full MySQL Server, some may package MySQL client libraries or other components that share the vulnerable code. For example, an Azure Marketplace image pre-configured with a LAMP stack would contain the MySQL server. Similarly, a container image hosted in Microsoft Container Registry might be affected.

Microsoft has not yet published VEX attestations for these products. The absence of an entry does not mean the product is safe—it only means the vendor has not completed its attestation for that product. This leaves administrators of WSL2, custom Azure VMs, and other Microsoft-provided Linux environments in a position where they must perform their own verification.

Practical Impact: What This Means for Different Users

Azure Linux Customers

If you run Azure Linux on VMs or as an AKS node OS, you are directly affected. Microsoft’s VEX attestation is your authoritative signal to patch.

  • Action: Update to MySQL 8.0.43 (or the patched version in your Azure Linux repository) via your package manager. Use Azure Update Manager for at-scale rollouts.

WSL2 Users

The WSL2 kernel itself does not include the MySQL server, and most WSL2 desktops do not run MySQL by default. However, if you have manually installed MySQL from the Microsoft repositories (or any repository) inside your WSL2 instance, you are responsible for patching it.

  • Action: Run apt list --installed | grep mysql or dpkg -l | grep mysql to check your MySQL version. If it’s older than 8.0.43, upgrade with sudo apt update && sudo apt upgrade mysql-server.

Azure Marketplace and Custom Image Users

Images that bundle MySQL—such as “LAMP on Ubuntu” or “MySQL on Red Hat”—may carry the vulnerable version. If you deploy such images, verify the included MySQL package.

  • Action: Inspect the image manifest or run a compliance scan. Rebuild your images with the patched MySQL version if necessary.

General MySQL Administrators

Regardless of whether you run MySQL on Windows, Linux, or in containers, if you use versions up to 8.0.42, you should upgrade promptly.

  • Action: Follow your distribution’s advisory (e.g., Ubuntu USN, Red Hat RHSA) or Oracle’s official upgrade path.

How We Got Here: A Timeline

  • July 2025: Oracle releases Critical Patch Update, disclosing CVE-2025-50104.
  • July–August 2025: Ubuntu, Red Hat, and other distributions publish their own advisories and patched MySQL packages (8.0.43).
  • October 2025: Microsoft announces its CSAF/VEX program, starting with Azure Linux.
  • Late 2025/early 2026: Microsoft’s MSRC advisory for this CVE goes live, confirming Azure Linux impact and providing the FAQ about VEX coverage.
  • Now: Customers are integrating VEX data into their vulnerability management workflows, but the phased rollout means many Microsoft products lack attestations.

What to Do Now: A Practical Patching Checklist

  1. Identify affected MySQL instances across your environment—cloud VMs, on-prem servers, containers, and development WSL2 instances.
  2. Check the MySQL version:
    - On Debian/Ubuntu: apt policy mysql-server
    - On Red Hat/CentOS: rpm -qa | grep mysql
    - On Windows: Check with mysql --version and download the patched MSI from Oracle.
  3. Upgrade to MySQL 8.0.43 or later (or your distribution’s equivalent patched version). For Azure Linux specifically, rely on the official Azure Linux package updates.
  4. For WSL2 users who have installed MySQL: Update inside the WSL2 instance using your package manager. Also, run wsl --update on the Windows host to keep the WSL2 kernel current, though this is unrelated to the MySQL vulnerability.
  5. Check Microsoft’s VEX feeds for your products. If you manage Azure VM images or AKS node images, look for updates to the VEX document that may later include your SKU.
  6. If you cannot patch immediately: Limit administrative access to the MySQL server. Since the vulnerability requires high privileges, strong access controls, network restrictions, and monitoring for anomalous DDL activity can reduce the risk.
  7. Automate ongoing verification: Integrate VEX feeds into your vulnerability scanners and set up alerts for when Microsoft adds attestations for your other Microsoft Linux products.

Outlook: Will Microsoft Expand VEX Coverage?

Microsoft has stated it will update the CVE if additional products are identified as affected. The company’s VEX program is still young; its commitment to transparency suggests that over time, more Microsoft-managed Linux SKUs will receive explicit attestations. In the meantime, administrators should treat any Microsoft-provided Linux product that bundles MySQL as unverified and perform their own artifact checks.

Community-driven security research and automated scanning of Microsoft’s public container registries and image repositories may fill the gap before official attestations arrive. Watch for updates to the MSRC advisory and announcements from Microsoft’s Linux security team.

CVE-2025-50104 may be a low‑severity bug, but it highlights a critical shift in how vendors communicate vulnerability impact. VEX attestations bring clarity—but only for the products they cover. For everything else, the old rule still applies: trust, but verify.