CVE-2026-101624 in MySQL Cluster
Summary
by MITRE • 10/21/2026
Vulnerability in the MySQL Server, MySQL Cluster product of Oracle MySQL (component: InnoDB). Supported versions that are affected are MySQL Server: 8.4.0-8.4.12, 9.7.0-9.7.3, 26.7.0-26.7.1; MySQL Cluster: 8.0.0-8.0.49, 8.4.0-8.4.12, 9.7.0-9.7.3 and 26.7.0-26.7.1. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server, MySQL Cluster. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server, MySQL Cluster. CVSS 3.1 Base Score 4.9 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/21/2026
The identified vulnerability resides within the InnoDB storage engine, a core component of Oracle MySQL Server and MySQL Cluster products. This flaw affects specific version ranges including MySQL Server versions 8.4.0 through 8.4.12, as well as 9.7.0 through 9.7.3 and 26.7.0 through 26.7.1. Similarly affected are MySQL Cluster deployments running versions 8.0.0 to 8.0.49, along with the same newer version ranges listed for the server component. The presence of this vulnerability in such a wide array of supported releases indicates a systemic issue within the underlying codebase that requires immediate attention from database administrators and security operations teams responsible for maintaining these environments.
The technical nature of this flaw allows an attacker to trigger a complete denial of service condition against the MySQL infrastructure. Specifically, successful exploitation leads to either a hang or a frequently repeatable crash of the MySQL Server process. This outcome effectively renders the database unavailable to legitimate users and applications relying on it for data persistence and retrieval operations. The vulnerability is characterized by its ease of exploitability, meaning that an attacker does not require complex conditions or rare edge cases to trigger the failure state. Instead, a straightforward sequence of actions can lead to system instability, making this a high-risk issue despite the requirement for specific privileges.
From a threat actor perspective, exploitation requires a high-privileged user account with network access via multiple protocols. This constraint implies that while an external attacker cannot directly exploit this vulnerability without first compromising valid credentials or gaining elevated access within the database environment, internal threats or compromised application accounts pose a significant risk. The availability of network access means that once authenticated at a privileged level, the attacker can initiate requests over various communication channels supported by MySQL to trigger the crash condition. This highlights the importance of strict access control policies and least-privilege principles in database administration practices.
The operational impact centers entirely on service availability rather than data confidentiality or integrity. The CVSS 3.1 base score is rated at 4.9, which classifies it as a medium severity issue primarily due to its high impact on the Availability metric while having no effect on Confidentiality or Integrity metrics. In production environments where database uptime is critical for business continuity, even temporary outages can lead to significant financial and reputational damage. The ability to cause repeatable crashes means that an attacker could sustainably disrupt services by repeatedly triggering the flaw, leading to prolonged downtime until manual intervention or service restarts are performed.
This vulnerability aligns with Common Weakness Enumeration categories related to resource management errors or improper handling of exceptional conditions within database engines. It also maps to MITRE ATT&CK techniques involving Denial of Service attacks against infrastructure components. Organizations should prioritize patching affected versions as soon as stable updates become available from Oracle. In the interim, implementing strict network segmentation and enforcing rigorous authentication controls can mitigate the risk by limiting who has both high-level privileges and network connectivity to the database servers. Regular auditing of privileged account usage and monitoring for unusual patterns in connection attempts or resource consumption may also help detect potential exploitation activities before they result in service disruption.