Oracle MySQL CVE-2026-101801

Exploitation requires an authenticated session as a high-privileged MySQL account (PR:H) with network reachability to the database over one of MySQL's supported protocols; it does not require user interaction or a non-default configuration. The decisive limiting factor is the high-privilege requirement - only a trusted, highly privileged database user (or an attacker who has already obtained such credentials) can trigger the flaw - which sharply narrows the realistic attacker population to insiders or those who have already compromised a privileged account. 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; the impact is limited to availability (service hang/crash) with no data confidentiality or integrity consequence.

This is a moderate-severity, availability-only denial-of-service flaw in the MySQL Server/Cluster Optimizer component, rated CVSS 3.1 4.9 (AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H). The signals are internally consistent and point to a lower real-world priority than the 'easily exploitable' language in Oracle's description might suggest: exploitation requires PR:H (high privileges - an existing authenticated account with substantial database privileges), which is the single biggest limiting factor, while AC:L and AV:N indicate that an already-privileged attacker can trigger it easily over the network. Impact is confined to availability (C:N/I:N/A:H) - a hang or repeatable crash (complete DoS) - with no confidentiality or integrity exposure and no scope change (S:U). No EPSS score, CISA KEV listing, or public POC is present in the provided data, so there is no evidence of active exploitation or widespread automated targeting; this reads as a high-CVSS-product (MySQL) but genuinely moderate-risk issue because the privilege barrier means the attacker must already be a trusted high-privilege DB user. Note the SSVC/EPSS/KEV inputs are absent rather than low - do not treat their absence as proof of safety. The main practical risk is a malicious or compromised privileged account, or a privileged application service account, causing service outages.

A high-privileged MySQL user (e.g. a compromised application service account or malicious DBA) connects over the network via a supported protocol and issues a specially crafted query that the Optimizer mishandles, causing the server to hang or crash and producing a complete denial of service for MySQL Server/Cluster. No public exploit code was identified in the provided data, so any attack would require the adversary to independently develop the triggering query. Because only availability is affected, the outcome is service disruption rather than data theft or tampering.