MySQL Server CVE-2026-101629

Exploitation requires an authenticated session with HIGH MySQL privileges (CVSS PR:H) against the InnoDB storage engine of affected MySQL Server or MySQL Cluster versions (9.7.0-9.7.3 or 26.7.0-26.7.1), reachable over the network via one of multiple supported MySQL protocols. The key limiting factor is the high-privilege prerequisite: an untrusted or low-privileged user cannot exploit it, so realistic risk is confined to multi-tenant databases, shared service accounts, or post-compromise scenarios where an attacker has already obtained elevated DB credentials. No user interaction is needed (UI:N), and no special non-default feature toggle is named in the advisory, but the impact is limited strictly to availability (hang/crash); there is no confidentiality or integrity exposure.

This is a genuinely moderate-to-low real-world priority despite being network-reachable. The CVSS 3.1 vector (AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H, base 4.9) shows the only impact is availability - an attacker can hang or repeatably crash the server (complete DOS) but cannot read or alter data (C:N/I:N). The critical mitigating signal is PR:H: the attacker must already hold high database privileges, so this is an insider or post-compromise capability, not a pre-auth remote takeover. Oracle's own text calls it 'easily exploitable' (consistent with AC:L), but that ease is gated behind the high-privilege requirement. No EPSS score, no CISA KEV listing, and no public POC were provided, so there is no evidence of active exploitation or weaponization - this appears to be a routine Oracle Critical Patch Update (October 2026) disclosure rather than an urgent threat. A high-privileged user who wanted to disrupt availability generally already has easier ways to do so (e.g., SHUTDOWN, dropping tables), which further lowers the practical uplift this vulnerability provides. Net: patch on normal CPU cadence; prioritize only where untrusted parties legitimately hold high MySQL privileges.

A user who already holds high MySQL privileges (e.g., a semi-trusted application service account or a tenant DBA in a shared/multi-tenant deployment) connects over the network via a supported protocol and issues specially crafted InnoDB operations that trigger a hang or repeatable crash, producing a complete denial of service. No public exploit code was identified at time of analysis, and the attack requires only low complexity once the privileged session is established, but delivers no data confidentiality or integrity impact.