MySQL Server EUVD-2026-106161

Exploitation requires the attacker to already hold a HIGH-PRIVILEGE MySQL account (PR:H) with network access to the InnoDB-backed MySQL Server or MySQL Cluster over one of its supported protocols; no user interaction is needed (UI:N). Affected builds 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. The dominant limiting factor is the high-privilege prerequisite, which confines the practical threat to insiders or accounts already compromised; impact is limited to availability (hang/crash, complete DOS) with no data disclosure or modification. No special non-default configuration is called out in the advisory.

This is a genuine but moderate-priority issue, not a top-tier emergency. The CVSS 3.1 base score is 4.9 (Medium) with vector AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H - availability-only impact, no confidentiality or integrity loss. The decisive limiting factor is PR:H: Oracle's own wording ('high privileged attacker with network access') and the vector agree that the attacker must already hold high database privileges, which sharply narrows the realistic threat to insiders, compromised application/service accounts, or a post-authentication pivot. No EPSS score was supplied in the input, and there is no CISA KEV listing and no public proof-of-concept referenced, so exploitation probability cannot be quantified from the data provided. There are no conflicting signals here - the description, CVSS vector, and 'Denial Of Service' tag are mutually consistent (easily exploitable once privileged, network-reachable, complete DOS of the server). The worst outcome is a hang or repeatable crash (complete availability loss) of the MySQL Server/Cluster instance; because impact is confined to availability and gated behind high privileges, this should be patched in the normal Oracle quarterly cycle rather than treated as an out-of-band crisis, with priority raised where untrusted parties can obtain high-privilege MySQL accounts.

An attacker who already possesses a high-privilege MySQL account (for example, a malicious DBA, or an application service account compromised via another flaw) connects over the network via one of the supported protocols and issues a crafted request that drives the InnoDB engine into a fault condition. The server hangs or enters a repeatable crash loop, producing a complete denial of service for all dependent applications. No public exploit was identified at the time of analysis, and because the low attack complexity applies only after high privileges are obtained, real-world abuse is most plausible as an insider or post-compromise action.