MySQL Server CVE-2026-47023

Exploitation requires a high-privileged MySQL account (CVSS PR:H) with network access to the target instance - this rules out unauthenticated or low-privilege exploitation entirely. The vulnerability is specific to the Replication component, making it most directly reachable through replication-related protocol interactions or commands such as CHANGE MASTER TO, START SLAVE/REPLICA, or replication stream operations; replication must be in use or configurable by the attacker. No non-default configuration is documented as required beyond the attacker holding sufficient database credentials. Limiting factors: (1) the attacker must hold high database privileges, which is a significant prerequisite barrier; (2) impact is strictly availability - no confidentiality or integrity compromise is possible; (3) MySQL Cluster's affected range begins at 8.0.0, meaning legacy Cluster deployments not yet running 8.4 or 9.7 are also exposed, whereas MySQL Server is only affected from 8.4.0 onward.

The CVSS 3.1 base score of 4.9 (AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H) is proportionate to the constrained threat model. Network reachability (AV:N) and low attack complexity (AC:L) are concerning signals, but the high privilege requirement (PR:H) is the dominant limiting factor - exploitation is restricted to authenticated database administrators or accounts with replication-level grants, ruling out opportunistic scanning or unauthenticated exploitation. The impact is exclusively availability (C:N/I:N/A:H), eliminating any data exfiltration or integrity risk. No EPSS score is available in the provided data; no CISA KEV listing and no public proof-of-concept exist at time of analysis, confirming this as a vendor-disclosed theoretical risk rather than an observed active threat. In practice, an adversary already holding high-privilege MySQL credentials represents a significant post-compromise foothold on its own, making this DoS most relevant where database availability is a high-priority SLA concern - particularly in MySQL Cluster HA deployments. Organizations running replication topologies should treat this as a standard patch-cycle priority; others may defer without significant incremental risk.

An attacker who has obtained high-privileged MySQL credentials - through phishing, credential reuse, or prior compromise of an application server or DBA workstation - connects over the network to a MySQL Server or Cluster instance and sends a specially crafted replication-protocol message or command sequence. The malformed input triggers a hang or repeatable crash in the replication component, causing service unavailability. In a MySQL Cluster HA deployment, repeatedly crashing the primary node could destabilize the cluster and deny service to all dependent applications.