CVE-2026-101747 in MySQL Serverinfo

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 low 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 6.5 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).

Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Analysis

by VulDB Data Team • 10/21/2026

The identified vulnerability resides within the InnoDB storage engine component of Oracle MySQL Server and MySQL Cluster products, affecting specific version ranges including MySQL Server 8.4 through 8.4.12, 9.7 through 9.7.3, and 26.7 versions up to 26.7.1, as well as corresponding releases of MySQL Cluster from 8.0.0 through 8.0.49 and the same newer version ranges. This flaw represents a significant availability risk for organizations relying on these database systems for critical data operations. The vulnerability is characterized by its ease of exploitation, allowing an attacker with low privileges to trigger severe system instability over network-accessible protocols such as TCP/IP or MySQL protocol connections. Because the attack vector requires only low-level authentication and no user interaction, it poses a substantial threat in environments where untrusted users have access to database services or where privilege separation is not strictly enforced at the application layer.

From a technical perspective, this vulnerability enables an attacker to induce a hang or cause frequent, repeatable crashes of the MySQL Server process, effectively resulting in a complete denial of service condition. The root cause typically involves improper handling of specific SQL statements or data structures within InnoDB that lead to resource exhaustion, infinite loops, or memory corruption when processed under certain conditions. Unlike vulnerabilities that compromise confidentiality or integrity by allowing unauthorized data access or modification, this flaw is strictly focused on availability impacts. The system becomes unresponsive or crashes repeatedly, preventing legitimate users from accessing the database and disrupting any dependent applications or services that rely on continuous uptime. This aligns with CWE-400, which describes conditions where resources are not properly controlled, leading to resource exhaustion, as well as CWE-787, if memory corruption is involved in triggering the crash states.

The operational impact of this vulnerability extends beyond simple downtime; it can lead to significant business disruption, data inconsistency during abrupt shutdowns, and increased administrative overhead for recovery efforts. In clustered environments such as MySQL Cluster, a node failure triggered by this exploit could potentially cascade or require complex failover procedures depending on the cluster configuration and quorum settings. The CVSS 3.1 base score of 6.5 reflects the medium severity due to its network accessibility and low privilege requirement, but the high availability impact (A:H) underscores the critical nature of maintaining service continuity. Attackers can leverage this flaw in automated denial-of-service campaigns or as a distraction technique while attempting other malicious activities against less protected systems within the same network segment.

To mitigate this risk, organizations must prioritize patching to the latest stable versions that address these specific flaws within InnoDB and MySQL Cluster components. Oracle typically releases updates through regular maintenance packs or security advisories; therefore, administrators should consult official Oracle documentation for the most current version recommendations applicable to their deployment architecture. Additionally, implementing network-level controls such as firewalls can restrict access to database ports from untrusted networks, reducing the attack surface available to low-privileged external actors. Application-layer defenses and strict input validation in client applications may also help prevent triggering the specific conditions that lead to this vulnerability, although patching remains the primary remediation strategy. Monitoring tools should be configured to detect unusual spikes in connection attempts or system resource usage indicative of a denial-of-service attempt, allowing for rapid incident response before prolonged outages occur. This aligns with MITRE ATT&CK techniques related to Resource Hijacking and Denial of Service, emphasizing the need for robust monitoring and timely patch management practices.

Responsible

Oracle

Reservation

09/28/2026

Disclosure

10/21/2026

Moderation

accepted

EPSS

0.00393

KEV

no

Activities

very low

Sources

Do you know our Splunk app?

Download it now for free!