MySQL Server EUVD-2026-106027

Exploitation requires the attacker to already hold HIGH MySQL privileges (PR:H) on the target MySQL Server or MySQL Cluster instance and network reachability to the database over one of its supported protocols; no user interaction is needed (UI:N). The flaw resides in the InnoDB storage engine component. Limiting factors: this is restricted to trusted/authenticated high-privilege accounts, so it is realistically an insider or compromised-privileged-credential threat rather than remote unauthenticated attack; impact is confined to availability (DoS) with no data disclosure or modification. Affected deployments are MySQL Server 8.4.0-8.4.12, 9.7.0-9.7.3, 26.7.0-26.7.1 and 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; other versions are not listed as affected.

This is a genuinely low-to-moderate priority issue despite being network-reachable. The CVSS 3.1 base score is 4.9 (MEDIUM), and every signal points to limited real-world risk: the vector (AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H) shows network access with low complexity but requires HIGH privileges (PR:H), and the only impact is availability (A:H) - a hang or repeatable crash (complete DoS) of the database. There is no confidentiality or integrity impact (C:N/I:N). No EPSS score, KEV listing, or POC was provided in the input, so there is no public exploit identified at time of analysis, and exploitation is not confirmed as active. The PR:H requirement is the dominant mitigating factor: an attacker must already hold high database privileges, meaning a trusted/authenticated insider or a compromised privileged account is needed - this is effectively a privileged user crashing the server they can already administer, which sharply limits the threat population. Net assessment: this is a high-CVSS-component (easily exploitable, network vector) but low-real-risk issue because of the PR:H precondition and DoS-only impact; patch it in the normal Oracle CPU cadence rather than as an emergency. One note of caution: Oracle's description calls it 'easily exploitable' and lists 'multiple protocols,' but provides no CWE and no technical root cause, so the exact triggering mechanism is unverified from the available data.

An attacker who already possesses high MySQL privileges (or who has compromised such an account) connects to the server over the network via one of the supported protocols and issues a crafted request against the InnoDB component. This triggers a hang or a reliably repeatable crash, producing a complete denial of service for MySQL Server/Cluster. No public exploit code was identified in the provided data, and the low attack complexity (AC:L) means the action is straightforward once privileged access exists.