CVE-2026-101622 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 of Oracle MySQL Server and MySQL Cluster products, affecting specific release streams including versions 8.4 through 8.4.12, 9.7 through 9.7.3, and 26.7 through 26.7.1 for both server and cluster editions. This flaw represents a significant availability risk because it allows an attacker to induce a complete denial of service by causing the database process to hang or crash repeatedly. The vulnerability is classified with a CVSS version 3.1 base score of 4.9, which indicates a medium severity level primarily driven by its high impact on system availability while having no direct effect on confidentiality or integrity under normal exploitation conditions.
From a technical perspective, the core issue lies in how InnoDB handles certain internal operations that can lead to resource exhaustion or deadlock states when triggered by specific network-based inputs. Although the vulnerability requires a high-privileged attacker with valid authentication credentials and network access via multiple protocols such as TCP/IP, the ease of exploitation means that once an authenticated user gains entry, they can reliably trigger the crash condition without requiring complex social engineering or zero-day chain attacks. This reliability makes it particularly dangerous in environments where database administrators or application service accounts may have elevated privileges but are exposed to potential compromise through other vectors like web applications connected to the database.
The operational impact of this vulnerability is severe for any production environment relying on MySQL Server or Cluster for critical data services. A successful exploit results in a complete denial of service, meaning that all queries submitted by legitimate users will fail until the database process is manually restarted. In high-availability setups utilizing MySQL Cluster, while redundancy might mitigate some downtime, frequent crashes can lead to split-brain scenarios, data inconsistency during recovery, or cascading failures across cluster nodes if not properly monitored and managed. The repetitive nature of the crash means that automated restart scripts may fail to restore service quickly enough to maintain acceptable uptime SLAs, leading to prolonged outages for dependent applications.
This vulnerability aligns with CWE-400, which describes uncontrolled resource consumption, as well as CWE-835 regarding loop issues or infinite loops within software logic that prevent termination under specific conditions. In the context of the MITRE ATT&CK framework, this behavior maps to T1499 Endpoint Denial of Service and potentially T1210 Exploitation of Remote Services if leveraged in conjunction with other vulnerabilities for deeper penetration after initial access is gained through authentication bypasses or credential theft. The requirement for high privileges places it within the scope of post-exploitation activities where an attacker seeks to disrupt operations rather than steal data, often as a distraction tactic or part of a destructive campaign against organizational infrastructure.
Mitigation strategies must focus on both immediate remediation and long-term architectural hardening. Oracle has released patches addressing this flaw in the affected version ranges listed above; therefore, the primary action is to apply these updates immediately to all production instances running vulnerable versions. For environments where patching cannot occur instantly due to maintenance windows or compatibility concerns, implementing strict network segmentation to limit database port access only to trusted application servers can reduce the attack surface significantly. Additionally, enforcing least-privilege principles ensures that even if an attacker compromises a lower-level account, they do not possess the high privileges required to trigger this specific InnoDB vulnerability. Monitoring tools should be configured to detect abnormal spikes in connection attempts or repeated service restarts, which may indicate ongoing exploitation attempts against this flaw.