CVE-2026-34303

What it actually does

This is a remotely reachable denial-of-service vulnerability in the Oracle MySQL Server optimizer component. A low-privileged authenticated user with network access to MySQL over supported protocols can send crafted SQL that causes the server process to hang or crash repeatedly. The impact is limited to availability: the CVSS vector indicates no confidentiality or integrity impact, no user interaction required, low attack complexity, and high availability impact.

Why it matters to the business

A successful attack can make affected MySQL databases unavailable, disrupting applications, websites, reporting jobs, and operational workflows that depend on them. Because exploitation requires only low database privileges and network reachability, any exposed MySQL service with untrusted or broadly distributed user accounts has elevated operational risk. The issue is not listed in CISA KEV, is not reported as ransomware-used, has low EPSS at 0.00303 with a flat 30-day trend, and has no reported public exploit maturity, so urgency should be risk-based rather than emergency-driven; internet-exposed, multi-tenant, or business-critical MySQL deployments should still be prioritized.

How an attack unfolds

An attacker first obtains or already possesses valid low-privileged MySQL credentials, such as an application, reporting, or limited database user. They connect to an affected MySQL Server version over the network using a standard MySQL client or compatible protocol. The attacker then submits SQL crafted to trigger the optimizer flaw. When the vulnerable optimizer processes the statement, the MySQL server may hang or crash. By repeating the request after service recovery or restart, the attacker can create a sustained denial of service. The attack does not require administrative database privileges, local operating system access, or user interaction, and there is no indication from the provided data that it enables data theft or data modification.

How to fix it

Upgrade Oracle MySQL Server to a vendor-fixed release newer than the affected ranges. Affected versions are 8.0.0-8.0.45, 8.4.0-8.4.8, and 9.0.0-9.6.0; therefore upgrade to the applicable Oracle CPU or later release that supersedes these versions for the deployed branch. If an immediate upgrade is not possible, reduce exposure by restricting MySQL network access to trusted application hosts and administration networks, removing unused database accounts, rotating and protecting credentials, enforcing least privilege, and preventing untrusted users from running arbitrary SQL. Use connection limits, query timeouts, resource controls, and service supervision to reduce blast radius and speed recovery, but treat these as mitigations rather than a fix.

How to confirm the fix worked

Inventory MySQL Server versions using `SELECT VERSION();`, package manager data, container image tags, or configuration management records, and confirm no instance is running 8.0.0-8.0.45, 8.4.0-8.4.8, or 9.0.0-9.6.0. Verify that deployed binaries and packages come from a patched Oracle MySQL release beyond the affected ranges. Confirm MySQL is not reachable from untrusted networks and that only required application and administrative sources can connect. Review account privileges to ensure low-privileged users cannot be abused broadly. After upgrade, monitor error logs and service managers for recurring mysqld crashes or hangs under normal query workloads, and run application regression tests that cover optimizer-heavy queries such as joins, subqueries, views, derived tables, and complex predicates.

Typical attack path

1. Identify a reachable MySQL Server instance running an affected version: 8.0.0 through 8.0.45, 8.4.0 through 8.4.8, or 9.0.0 through 9.6.0.
2. Obtain valid low-privileged MySQL credentials through legitimate access, credential theft, exposed secrets, reused passwords, or compromised application accounts.
3. Connect to the MySQL service over the network using a MySQL client, connector, or compatible protocol.
4. Submit crafted SQL that exercises the vulnerable optimizer code path.
5. Cause the MySQL server process to hang or crash, interrupting dependent applications.
6. Repeat the triggering request after the database service restarts to maintain or recur the outage.

How to detect it

To determine whether this was already exploited, correlate MySQL service crashes, hangs, or restarts with authenticated client activity immediately beforehand. Review MySQL error logs for crash messages, stack traces, optimizer-related failures, abnormal shutdowns, and repeated startup sequences. Review general query logs, audit logs, proxy logs, and application database access logs for unusual SQL issued by low-privileged users shortly before each outage, especially complex queries involving joins, subqueries, derived tables, views, common table expressions, optimizer hints, or unusual predicate combinations. Review system logs such as systemd, syslog, journald, Windows Event Logs if applicable, container runtime logs, and orchestration events for mysqld process exits, restarts, health-check failures, OOM-like symptoms, or crash loops. Look for repeated crashes that follow the same database user, client IP, application account, or query pattern. Because no public exploit string is provided, detection should focus on behavior: authenticated query activity followed by mysqld hang/crash and repeated service recovery cycles.

• mysqld got signal
• mysqld: ready for connections
• InnoDB: Starting crash recovery
• InnoDB: Database was not shutdown normally
• Aborting
• mysqld: Shutdown complete
• Main process exited, code=killed
• Main process exited, code=dumped
• Failed with result 'signal'
• Failed with result 'core-dump'
• mysql.service: Scheduled restart job
• mysql.service: Start request repeated too quickly
• mysqld.service: Scheduled restart job
• mysqld.service: Start request repeated too quickly
• CrashLoopBackOff
• Back-off restarting failed container
• ERROR 2013 (HY000): Lost connection to MySQL server during query
• ERROR 2006 (HY000): MySQL server has gone away

What your security team should do

• Prioritize patching internet-exposed, externally reachable, multi-tenant, and business-critical MySQL servers first, even though EPSS is currently low and the vulnerability is not in CISA KEV.
• Inventory all Oracle MySQL Server deployments and flag versions 8.0.0-8.0.45, 8.4.0-8.4.8, and 9.0.0-9.6.0 as affected.
• Upgrade affected systems to a vendor-fixed Oracle MySQL Server release that is newer than the affected range for the deployed branch.
• Restrict MySQL access at firewalls, security groups, network ACLs, and host firewalls to trusted application and administration sources only.
• Audit low-privileged MySQL users, remove unused accounts, rotate exposed credentials, and enforce least privilege for application and reporting users.
• Enable and retain MySQL error logs, general/audit logs where feasible, slow query logs, systemd or service manager logs, and infrastructure monitoring telemetry to support post-incident analysis.
• Create alerts for repeated mysqld crashes, unexpected restarts, service hangs, connection spikes from a single user or source, and crash loops following specific authenticated sessions.
• Prepare operational runbooks for database restart, failover, connection draining, and rollback in case exploitation causes repeated availability loss before patching is complete.