CVE-2025-50104: MySQL DDL DoS Patch Guidance and Azure Linux Attestation

Oracle’s July 2025 MySQL server advisory (CVE‑2025‑50104) identified a low‑severity denial‑of‑service weakness in the MySQL Server Server: DDL component that affects upstream MySQL releases up to and including 8.0.42 (and corresponding 8.4.x and 9.x series), and vendors and distributors responded quickly with patches and distribution‑specific updates.

Background / Overview​

MySQL is a ubiquitous open‑source relational database engine. In mid‑July 2025 Oracle published a group of MySQL security fixes in its July CPU, including CVE‑2025‑50104, which is described as an easily exploitable issue for a high‑privileged attacker that can lead to a partial denial of service (availability impact only). Upstream references and the NVD show a CVSS 3.1 score of 2.7 for CVE‑2025‑50104 and list affected upstream MySQL versions up to 8.0.42.
Linux distributions and downstream vendors incorporated those upstream advisories into their own advisories or updates: Ubuntu, Red Hat / RHEL packaging trackers and other vulnerability databases flagged the issue and recommended upgrading to the patched upstream package (for example, many distributions moved to MySQL 8.0.43 or later as the fix release).
Microsoft’s Security Response Center (MSRC) published its product mapping and an FAQ for many third‑party CVEs; for a number of Linux‑component CVEs MSRC’s published advisory language explains that Azure Linux (Microsoft’s cloud‑tuned Linux distribution) is a confirmed carrier of the implicated open‑source library and is therefore potentially affected, and that Microsoft has begun publishing machine‑readable CSAF/VEX attestations (October 2025) to make this inventory transparent. MSRC also states that it will update VEX/CVE mappings if additional Microsoft products are later identified as carriers.

---

What CVE‑2025‑50104 actually is (technical summary)​

The vulnerability in plain terms​

• The issue lives in the MySQL Server’s DDL handling; the upstream description classifies the problem as a resource consumption / partial DoS style bug rather than an information leak or code‑execution flaw.
• Exploitation requires high privileges on the MySQL server (PR:H) but can be triggered over the network (AV:N) and does not require user interaction. The resulting impact is confined to availability (partial DOS) rather than confidentiality or integrity.

Severity and practical impact​

• The CVSS 3.1 base score of 2.7 reflects a low severity ranking driven by the high privilege requirement and limited impact to availability.
• In operational terms: attackers with administrative access to MySQL (or equivalent elevated access) can provoke resource exhaustion or a stoppage of some MySQL operations, causing partial service disruption. For many environments (multi‑tenant DBaaS, managed instances, containerized apps), partial DOS can still have meaningful business impact.

Fix status upstream and downstream​

• Oracle’s July 2025 CPU and subsequent vendor updates remedied the defect in the next upstream patch release series; many distributions and downstream packages were updated to MySQL 8.0.43 (or equivalent patched builds). Distribution security trackers (Ubuntu/Tenable/Snyk) recommend moving to the patched incremental release.

---

Microsoft’s public statement: “Is Azure Linux the only Microsoft product that includes this open‑source library?”​

The literal MSRC message​

Microsoft’s product‑level FAQ text that appears on MSRC advisory pages answers a common customer question this way: Azure Linux includes the implicated open‑source library and is therefore potentially affected; Microsoft has started publishing CSAF/VEX attestations (October 2025) and will update the CVE if impact to additional products is identified. That phrasing is deliberate and appears across numerous MSRC Linux‑component advisories.

How to read Microsoft’s wording (the plain, actionable meaning)​

• Authoritative attestation for Azure Linux: Microsoft has verified that its Azure Linux distribution includes the upstream component in question and therefore Azure Linux is an actionable item for patching and mitigation. For customers running Azure Linux images, that attestation is the direct, vendor‑provided inventory statement you should rely on.
• Not an exclusivity guarantee: The MSRC sentence does not logically mean “no other Microsoft product could possibly include the same component.” MSRC explicitly frames this as a phased, product‑scoped rollout of VEX attestations: they started with Azure Linux and will expand to additional product families over time. Absence of a VEX/CSAF attestation for another Microsoft product is therefore absence of attestation, not definitive proof of absence.

---

Is Azure Linux the only Microsoft product that could be affected?​

Short answer: No — Azure Linux is the only Microsoft product that Microsoft has publicly attested to include the implicated MySQL component for this CVE at the time of publication, but other Microsoft‑supplied artifacts may also contain the same upstream code and therefore could be affected depending on build/version/configuration.

Why that “No” matters in practice​

Microsoft distributes a range of Linux artifacts and kernel builds beyond the Azure Linux SKU:

• WSL2 kernels: Microsoft builds and distributes the WSL2 Linux kernel (source and binary artifacts are maintained in the WSL/WSL2 repositories and build pipeline). Those kernels can include upstream drivers and subsystems such as AMDGPU or other kernel subsystems — presence depends on kernel configuration and commit range. Issues rooted in upstream Linux code can therefore appear in WSL kernel builds if the vulnerable commits are present. GitHub issues and WSL kernel build tags show Microsoft’s kernel filenames include the “microsoft‑standard‑WSL2” identifier and specific kernel versions; WSL users have experienced device/driver interactions tied to kernel config choices.
• Azure VM images and kernel packages: Azure offers multiple tuned kernel packages (the linux‑azure family, Azure Linux images, Marketplace images, and AKS node images). Those artifacts are built from Linux sources and selectively include drivers and modules depending on the distribution variant and kernel config. If a particular Azure kernel build includes a vulnerable upstream component, an Azure VM or AKS node could, in practice, be affected until patched.
• Other Microsoft‑owned Linux artifacts: Microsoft maintains containers, appliance images, and various cloud‑hosted images that may bundle the vulnerable component — whether those artifacts are vulnerable is an artifact‑level question that requires verification.

In short: the MSRC attestation identifies a confirmed Microsoft carrier (Azure Linux); it does not constitute an exhaustive inventory of every Microsoft artifact that might contain the upstream code.

---

Evidence and independent cross‑checks​

To be confident about the scope of exposure, cross‑reference multiple independent sources:

• NVD and distribution advisories document the CVE and the upstream affected versions (NVD lists affected MySQL upstream versions; Ubuntu and Snyk list the same versions and provide distribution‑specific remediation guidance). These independent public trackers corroborate the defect description and the remedial upstream version numbers.
• MSRC’s own blog and advisory pages explicitly describe the October 2025 CSAF/VEX rollout and the product‑scoped attestation process; that blog confirms Microsoft’s transparency commitment and the phased approach starting with Azure Linux.
• Public evidence that Microsoft builds and publishes Linux kernel artifacts (the WSL2 kernel code and kernel binary versions) confirms there are other Microsoft‑controlled Linux kernels that can — depending on configuration and version — include the same upstream code paths that gave rise to some Linux kernel CVEs in 2025. GitHub issues and WSL project pages show kernel version identifiers and driver discussion around AMD GPU and DRM subsystems. This proves the technical possibility that a Microsoft product other than Azure Linux could carry upstream kernel code.

Where independent sources disagree or where Microsoft has not yet attested, treat the absence of a formal Microsoft VEX statement about a particular product as an open verification item: you must either rely on Microsoft publishing a VEX/CSAF attestation for that product, or perform your own artifact verification (details below).

---

Practical risk assessment for different customer types​

If you run Azure Linux images (VMs, AKS nodepools using Azure Linux)​

• Treat MSRC’s attestation as the primary vendor input: Azure Linux was enumerated as a carrier and therefore should be included in your patching plan. Confirm your image/kernel/package versions and apply the Microsoft/Ubuntu/RPM updates or vendor recommended patches as published in the advisory and distributor updates.

If you run WSL2 on Windows desktops or servers​

• Verify your WSL2 kernel version (wsl --status and uname -r inside the WSL instance). WSL’s kernel is updated independently of Windows releases; if your WSL kernel version predates the fix or includes the vulnerable upstream commit range, you should update the WSL kernel via Microsoft’s recommended update flow (wsl --update) or apply the patched kernel binary. Public WSL issue threads show that WSL2 kernels include AMD/DRM pieces and are built by Microsoft, so check the exact kernel build and patch level.

If you run Azure Marketplace images, custom Azure kernels, or other Microsoft‑distributed Linux artifacts​

• Do not assume non‑attested products are unaffected. Instead, treat them as unknown until verified: query inventory (image manifests, package lists, kernel configs), validate package versions, and consult Microsoft’s VEX/CSAF feed for updates. If you manage fleets, automate checks to detect vulnerable package versions or kernel commits.

---

How to validate whether your Microsoft product or image contains the vulnerable component​

Follow these steps to determine exposure in Microsoft artifacts and images:

• Check Microsoft’s VEX/CSAF outputs for the CVE (MSRC publishes machine‑readable attestations that state product impact). If the product is listed as Known Affected or Under Investigation, follow the vendor guidance.
• For Azure Linux or distro images, query the package manager and check the MySQL package version:
• Debian/Ubuntu: apt policy mysql-server‑8.0 (or dpkg -l | grep mysql)
• RHEL/CentOS: rpm -qa | grep mysql
• If the installed package is older than the patched release (for many vendors this is 8.0.43 or vendor‑specific equivalent), schedule the upgrade.
• For WSL2 kernels: inside the WSL instance run uname -r and compare to Microsoft’s WSL kernel build/version. If in doubt, run wsl --update on the Windows host to pull the latest kernel package from Microsoft.
• For Azure VM images and AKS nodes: inspect the node image SKU (osSku), kernel package version, and installed packages. Where possible, use Azure‑provided inventory telemetry (Update Management, Azure Policy, guest‑inventory) to detect vulnerable versions at scale.
• If you maintain custom images (Marketplace images, DSC artifacts, VM images), rebuild and redeploy images with the patched packages or upgraded upstream commits.
• For proof‑of‑concept confirmation of non‑vulnerability, check upstream commit IDs: if your binary includes vendor backports that incorporate the upstream fix commit, your artifact may already be protected even if its version number is older. Always validate by checking the vendor’s changelog or binary diff/patch notes.

---

Remediation and mitigation recommendations​

• Apply vendor patches promptly. For standard MySQL deployments, upgrade to the fixed upstream release (commonly 8.0.43 in July 2025 downstream packaging) or to your distro’s patched package as recommended in the vendor advisory. Distribution trackers such as Snyk and Ubuntu list the exact package versions to install.
• For Azure Linux customers: apply the Azure Linux package updates or image refreshes Microsoft publishes. Follow your normal Azure maintenance windows and use the Azure update management tooling to orchestrate cluster or VM rollouts. MSRC’s VEX attestation for Azure Linux should inform prioritization and scheduling.
• For WSL2 users: run wsl --update to pull the latest WSL kernel, then restart WSL instances. Verify kernel versions with uname -r and update if necessary.
• If you can’t patch immediately: reduce the attack surface — restrict network access to administrative MySQL endpoints, enforce strong admin authentication, and monitor for suspicious high‑privilege operations. Because exploitation requires high privileges, strict host and DB access control will materially reduce risk.
• Instrument detection: deploy monitoring to detect anomalous MySQL resource consumption or frequent crashes. Configure alerting for repeated MySQL restarts, process hangs, or new crash signatures that map to the vulnerability’s symptom profile.
• Document per‑artifact validations: maintain an internal inventory mapping images and SKUs to VEX/CSAF attestations and to your test‑validated patch levels. That will simplify later audits and make the October 2025 VEX documents easier to operationalize.

---

Why vendor‑scoped VEX/CSAF attestation matters — and its limitations​

Microsoft’s newly published CSAF/VEX attestations (announced October 2025) mark an important shift toward machine‑readable transparency: they let customers and tooling quickly determine whether a vendor‑maintained product includes a vulnerable upstream component. For Azure Linux, that means customers can automate whether they need to patch or not.
But VEX has limits you must understand:

• VEX is a declarative attestation about specific vendor artifacts — it is only as comprehensive as the vendor’s artifact inventory and the product families the vendor has completed scanning.
• Absence of a VEX entry for a product does not equal “not affected”; it often means the vendor has not yet completed scanning or publishing attestations for that product. Treat “not listed” as unverified rather than conclusively safe.

That practical nuance is the heart of the user’s original question: Microsoft’s MSRC page correctly declares Azure Linux as a confirmed carrier, and Microsoft will expand VEX attestations to additional products over time — but until Microsoft publishes attestations for additional SKUs, customers must either rely on Microsoft to publish or perform local artifact verification.

---

Executive summary and final guidance​

• Microsoft’s MSRC advisory language for CVE‑2025‑50104 is a product‑scoped attestation: Azure Linux is a confirmed carrier of the implicated component and therefore is potentially affected. Microsoft has started publishing machine‑readable CSAF/VEX attestations (October 2025) to make these mappings explicit.
• That attestation is not a universal exclusivity statement. Other Microsoft artifacts — notably WSL2 kernel builds, Azure VM/kernel packages, AKS node images, and Marketplace images — can include the same upstream MySQL or kernel code depending on build choices and versions. Customers should not assume non‑attested products are unaffected.
• Practical actions for administrators and developers:
• Check MSRC’s VEX/CSAF feeds for the CVE and the list of Microsoft products attested.
• Verify your installed MySQL package kernel/proc/package versions and upgrade to the patched downstream packages (many vendors recommend MySQL 8.0.43 or later).
• For WSL2 and other Microsoft kernel artifacts, verify the kernel build and update via wsl --update or the vendor’s recommended method.
• If you cannot patch immediately, limit administrative access to MySQL instances and monitor for abnormal availability impacts.
• Finally, treat Microsoft’s Azure Linux attestation as authoritative for Azure Linux customers, and treat other Microsoft artifacts as needing independent verification until Microsoft’s VEX/CSAF program explicitly covers them. The combination of vendor VEX data and local artifact checks is the most defensible approach to ensure you are neither over‑ nor under‑reacting.

CVE‑2025‑50104 is a reminder that upstream open‑source vulnerabilities ripple through diverse distribution and vendor ecosystems. The vendor‑attested VEX model narrows ambiguity for customers — so use VEX where available, but also maintain artifact‑level checks as part of your baseline security hygiene.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center