MySQL Server CVE-2026-101612

Exploitation requires the attacker to already have high-privilege access AND local logon to the infrastructure/host where MySQL Server or MySQL Cluster runs (AV:L, PR:H) - this is not remotely reachable over the network. The flaw resides in the InnoDB storage engine component. Successful attack additionally requires human interaction from a person other than the attacker (UI:R) and is rated difficult to exploit (AC:H). These combined factors - local access, pre-existing high privileges, a second human actor, and high complexity - are the key limiting conditions that make real-world exploitation unlikely despite MySQL's ubiquity. Affected: 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, 26.7.0-26.7.1.

This is a genuinely low-priority issue despite affecting ubiquitous software. The CVSS 3.1 base score of 4.0 (MEDIUM) is driven entirely by availability impact (A:H), with no confidentiality or integrity impact. The vector (AV:L/AC:H/PR:H/UI:R) stacks multiple constraints that sharply limit real-world risk: the attacker needs local logon access to the infrastructure (AV:L), already-high privileges (PR:H), high attack complexity (AC:H, described as 'difficult to exploit'), AND human interaction from a separate victim (UI:R). No EPSS score was provided in the input, and the CVE is not listed in CISA KEV, with no public exploit code identified. All available signals align consistently: this is a low-real-risk, high-barrier denial-of-service bug, not a widespread-exploitation threat. The worst outcome is a hang or repeatable crash (complete DOS) of the database - disruptive but not a data breach. The main caveat is missing data: no EPSS, KEV, or POC signals were supplied, so exploitation probability cannot be independently quantified, but the restrictive vector makes mass exploitation implausible regardless.

An attacker who already holds high-privilege credentials and local logon access to the host running MySQL Server or Cluster crafts a malicious condition in the InnoDB component, then relies on a separate privileged user to perform some triggering action, causing the database to hang or repeatedly crash. No public exploit code has been identified, and the 'difficult to exploit' rating plus required human interaction make this a narrow, opportunistic scenario rather than a reliable attack.