Vulnerability in the MySQL Server

CVE-2026-60315 is a flaw in MySQL Server's X Plugin — the component that speaks the X Protocol on TCP 33060 for the document-store / MySQL Shell interface. The CVSS vector (AV:N/AC:L/PR:N/UI:N/C:L/I:N/A:H) tells the whole story: an unauthenticated attacker with network reach to 33060 sends a crafted message and crashes the server, with a minor confidentiality side-effect. Affected trains: MySQL Server 8.4.0–8.4.10 and 9.7.0–9.7.1; MySQL Cluster consuming the same server binaries inherits the flaw. Fixes ship in the Oracle CPU July 2026 as 8.4.11 and 9.7.2.

Oracle's HIGH (8.2) rating is defensible but slightly inflated for the median enterprise. There is no RCE, no auth bypass, no data exfil path — just a repeatable service kill. On an internet-exposed database (rare but real) it is legitimately HIGH; on a properly segmented data tier it is closer to a MEDIUM operational-risk bug. We keep the verdict at HIGH because MySQL sits in the high-value 'production data tier' role bucket and a reliable unauthenticated outage against that role is a real fleet-scale event.

Why this verdict

• Role multiplier: MySQL is canonical data-tier infrastructure; chain outcome on a prod OLTP node = application-wide outage, on an InnoDB/NDB cluster = quorum loss. Floor is HIGH.
• Unauthenticated pre-auth vector: PR:N means anyone with a TCP path wins — no credential stuffing, no phishing pretext, no lateral movement burn.
• But: availability-only impact. C:L / I:N / A:H is a crash bug, not RCE. Attacker gets an outage, not your data. That's why the score sits below the 8.2 Oracle assigned rather than being pushed to CRITICAL.
• Exposure narrowing: Port 33060 is rarely internet-exposed; the bug is far more relevant to internal-attacker / post-initial-access scenarios than to opportunistic mass exploitation.
• No PoC yet, no KEV — pressure is medium-term, not hair-on-fire.

Why not higher?

Not CRITICAL because there is no code execution, no data disclosure at scale, and no privilege escalation. The worst outcome is a service outage that mysqld_safe / orchestration will attempt to recover from within minutes. CRITICAL is reserved for chains ending in RCE, DA, or mass data egress.

Why not lower?

Not MEDIUM because the affected role is a production database and the vector is unauthenticated network. A repeatable pre-auth DoS against your OLTP engine is not a MEDIUM problem regardless of how narrow the exposed population is — one exposed node is enough to earn a Sev-1 page.

1. Block or firewall TCP/33060 at the host and network edge — Restrict mysqlx_bind_address to 127.0.0.1 (or a dedicated management VLAN) and drop 33060 at security groups / NGFW. Deploy within 30 days per noisgate HIGH mitigation SLA; do it in hours if any node is internet-reachable.
2. Disable the X Plugin where not used — SET PERSIST mysqlx = OFF; or --skip-mysqlx on startup removes the attack surface entirely. Most classic-protocol workloads (JDBC, PDO, mysql-client) do not need X Protocol. Do this alongside firewalling within the 30-day window.
3. Rate-limit new connections to 33060 — Use iptables hashlimit, nftables, or the WAF/NGFW in front of the DB to cap connections-per-source-per-second on 33060 so a loop-crash payload gets throttled before it becomes a sustained outage.
4. Confirm mysqld auto-restart is configured — Verify systemd Restart=on-failure and RestartSec are set; monitor for mysqld restart storms in Prometheus/CloudWatch. This won't stop the bug but it shortens each outage window while you roll the patch.
5. Schedule the Oracle CPU July 2026 rollout — Upgrade to 8.4.11 / 9.7.2 within the noisgate 180-day HIGH remediation SLA — stage in dev, canary one replica, then rolling upgrade the cluster.

Run this from a Linux host that can reach the MySQL server over the network (auditor workstation or jumpbox); no MySQL credentials required. Usage: ./check-cve-2026-60315.sh <host> [mysqlx_port] — example: ./check-cve-2026-60315.sh db01.internal 33060. It prints VULNERABLE / PATCHED / UNKNOWN and exits with a matching code.

#!/usr/bin/env bash
# check-cve-2026-60315.sh — noisgate verifier for MySQL X Plugin DoS
# Exit 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN
set -u
HOST="${1:-}"; PORT="${2:-33060}"
if [[ -z "$HOST" ]]; then echo "usage: $0 <host> [port]" >&2; exit 2; fi

# Prefer local check if we're ON the DB host
if command -v mysqld >/dev/null 2>&1; then
  V=$(mysqld --version 2>/dev/null | grep -Eo '[0-9]+\.[0-9]+\.[0-9]+' | head -1)
  echo "local mysqld version: ${V:-unknown}"
  case "$V" in
    8.4.11|8.4.1[2-9]|8.[5-9].*|9.7.2|9.7.[3-9]|9.[8-9].*|1[0-9].*) echo PATCHED; exit 0;;
    8.4.[0-9]|8.4.10|9.7.0|9.7.1) echo VULNERABLE; exit 1;;
  esac
fi

# Remote check — probe X Protocol port and try to fingerprint via mysqlsh if available
if ! (echo > "/dev/tcp/${HOST}/${PORT}") 2>/dev/null; then
  echo "port ${PORT} closed on ${HOST} — X Plugin not reachable (attack surface absent)"
  echo UNKNOWN; exit 2
fi
echo "port ${PORT} is OPEN on ${HOST}"

if command -v mysqlsh >/dev/null 2>&1; then
  BANNER=$(mysqlsh --uri "mysqlx://probe@${HOST}:${PORT}" --sql -e 'SELECT VERSION();' 2>&1 | grep -Eo '[0-9]+\.[0-9]+\.[0-9]+' | head -1)
  if [[ -n "$BANNER" ]]; then
    echo "remote version banner: $BANNER"
    case "$BANNER" in
      8.4.11|8.4.1[2-9]|8.[5-9].*|9.7.2|9.7.[3-9]|9.[8-9].*|1[0-9].*) echo PATCHED; exit 0;;
      8.4.[0-9]|8.4.10|9.7.0|9.7.1) echo VULNERABLE; exit 1;;
    esac
  fi
fi

echo "could not determine version remotely — treat as VULNERABLE until proven otherwise if 33060 is exposed"
echo UNKNOWN; exit 2

Sources

1. Oracle Critical Patch Update — July 2026
2. Oracle CVE → Advisory mapping
3. MySQL 8.4 Reference — X Plugin
4. Ubuntu bug — mysqlx listening on all interfaces by default
5. PentestPad — Port 33060 MYSQLX overview
6. Oracle MySQL CVE index (cvedetails)
7. CISA Known Exploited Vulnerabilities Catalog
8. FIRST EPSS