MySQL 5

Tenable plugin 121227 is a rollup for Oracle MySQL 5.6.x < 5.6.43, fixed in the January 2019 CPU and released as MySQL 5.6.43 on 2019-01-21. The bundle includes multiple flaws, but the meaningful ones for 5.6 are mostly *authenticated network* bugs in Server: Replication, Server: Optimizer, Server: PS, and related paths. The highest-impact representative issue is CVE-2019-2534 (CVSS 7.1), which can let a low-privileged attacker with MySQL protocol access read sensitive data and modify some data; others in the same bundle are primarily repeatable crash / hang conditions.

Oracle's top score in this set is technically fair in a lab, but it overstates enterprise urgency in the field. The chain starts with PR:L, which means the attacker already has a valid MySQL account and network reachability to the server; in a real estate of 10,000 hosts, that usually means *post-initial-access* or a compromised app/service account, not anonymous internet exploitation. No KEV listing, no strong public weaponization signal, and no RCE path keeps this out of the top patch queue unless the database listener is internet-exposed or shared broadly across sensitive apps.

Why this verdict

• Downward adjustment: requires authenticated DB access — PR:L means the attacker already has MySQL credentials, which usually implies prior compromise of an app tier, stolen secrets, or insider reach. That is classic post-initial-access friction and the biggest reason this is not a HIGH in real enterprise operations.
• Downward adjustment: reachable population is narrower than the CVSS implies — the attack only starts if the adversary can talk directly to the MySQL listener. In modern estates, many databases are internal-only and reachable only from app subnets, bastions, or proxies, so the practical attack surface is far smaller than an internet-edge service bug.
• Downward adjustment: no host takeover path — the meaningful 5.6 issues here are data-plane abuse or DoS inside MySQL, not operating-system RCE. Even the strongest path, CVE-2019-2534, stays inside the database trust boundary.

Why not higher?

There is no evidence in the reviewed sources of KEV status, active exploitation, or broad public weaponization. More importantly, this is not unauthenticated remote code execution; the attacker must already be able to reach the DB and authenticate to it, which is a hard break from internet-scale wormable behavior.

Why not lower?

This is still a real security issue, not backlog lint. If an exposed or internally reachable MySQL server is using reusable app credentials, CVE-2019-2534 can turn that foothold into unauthorized access to sensitive data and some unauthorized writes, and the DoS issues can take application dependencies offline.

1. Restrict 3306 to known app sources — Collapse the reachable population with host firewalls, cloud security groups, or DB-tier ACLs so only approved app servers and admin jump points can talk to MySQL. For a MEDIUM verdict there is no mitigation SLA — treat this as hardening and go straight to remediation within 365 days unless the listener is internet-exposed.
2. Rotate and scope application DB credentials — These flaws become materially worse when the attacker can reuse broad service-account credentials. Reduce each app account to the minimum schemas and verbs it needs, rotate secrets out of flat files where possible, and complete this during normal hardening because there is no mitigation SLA for a MEDIUM verdict.
3. Turn on DB audit and restart monitoring — You want visibility into unusual logins, odd prepared-statement activity, replication anomalies, and mysqld restart/crash behavior, because public scanner validation is weak here. For MEDIUM, deploy as part of routine control improvement while planning the actual version upgrade inside the remediation window.
4. Prefer upgrade off the 5.6 branch entirely — If you still have Oracle MySQL 5.6, the security problem is bigger than this one plugin because the branch is long past current support expectations. Use the plugin as a forcing function to inventory holdouts and move them to a supported branch during the ≤365 day remediation window.

Run this on the target MySQL host. Invoke it as bash verify_mysql_5643.sh /usr/sbin/mysqld or simply bash verify_mysql_5643.sh if mysqld is in PATH; no root is required to read the binary version, but package metadata checks may return better results when run with standard local shell access.

#!/usr/bin/env bash
# verify_mysql_5643.sh
# Determine whether an Oracle/Percona-style MySQL 5.6 server is below 5.6.43.
# Outputs one of: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

TARGET="${1:-mysqld}"

have_cmd() {
  command -v "$1" >/dev/null 2>&1
}

version_lt() {
  # returns 0 if $1 < $2, else 1
  local a b i
  IFS='.' read -r -a a <<< "$1"
  IFS='.' read -r -a b <<< "$2"
  for ((i=0; i<3; i++)); do
    local ai="${a[i]:-0}"
    local bi="${b[i]:-0}"
    if ((10#$ai < 10#$bi)); then
      return 0
    elif ((10#$ai > 10#$bi)); then
      return 1
    fi
  done
  return 1
}

extract_version() {
  local out="$1"
  # Handles strings like:
  # /usr/sbin/mysqld  Ver 5.6.42 for Linux on x86_64 ...
  # mysql  Ver 14.14 Distrib 5.6.42, for Linux ...
  if [[ "$out" =~ Distrib[[:space:]]([0-9]+\.[0-9]+\.[0-9]+) ]]; then
    echo "${BASH_REMATCH[1]}"
    return 0
  fi
  if [[ "$out" =~ Ver[[:space:]]([0-9]+\.[0-9]+\.[0-9]+) ]]; then
    echo "${BASH_REMATCH[1]}"
    return 0
  fi
  if [[ "$out" =~ ([0-9]+\.[0-9]+\.[0-9]+) ]]; then
    echo "${BASH_REMATCH[1]}"
    return 0
  fi
  return 1
}

BIN=""
if [[ -x "$TARGET" ]]; then
  BIN="$TARGET"
elif have_cmd "$TARGET"; then
  BIN="$(command -v "$TARGET")"
elif have_cmd mysqld; then
  BIN="$(command -v mysqld)"
else
  echo "UNKNOWN: mysqld binary not found"
  exit 2
fi

RAW="$($BIN --version 2>/dev/null || true)"
if [[ -z "$RAW" ]]; then
  echo "UNKNOWN: unable to execute $BIN --version"
  exit 2
fi

VER="$(extract_version "$RAW" || true)"
if [[ -z "$VER" ]]; then
  echo "UNKNOWN: could not parse version from: $RAW"
  exit 2
fi

# Package-manager heuristic: distro backports can make version-only checks unreliable.
# If this looks like a distro package string without an obvious Oracle/Percona upstream build,
# return UNKNOWN rather than falsely calling it vulnerable.
if echo "$RAW" | grep -Eiq '(ubuntu|deb|el[0-9]|fc[0-9]|suse|red hat|debian)'; then
  if [[ "$VER" == 5.6.* ]]; then
    echo "UNKNOWN: distro-packaged MySQL 5.6 detected ($VER); verify vendor backports before trusting version-only results"
    exit 2
  fi
fi

case "$VER" in
  5.6.*)
    if version_lt "$VER" "5.6.43"; then
      echo "VULNERABLE: MySQL version $VER is below 5.6.43"
      exit 1
    else
      echo "PATCHED: MySQL version $VER is 5.6.43 or later"
      exit 0
    fi
    ;;
  5.7.*|8.*|9.*)
    echo "PATCHED: host is not on the affected 5.6.x branch (detected $VER)"
    exit 0
    ;;
  *)
    echo "UNKNOWN: detected version $VER is outside expected MySQL version patterns"
    exit 2
    ;;
esac

Sources

1. Tenable plugin 121227
2. Oracle Critical Patch Update Advisory - January 2019
3. MySQL 5.6 Release Notes
4. NVD - CVE-2019-2534
5. NVD - CVE-2019-2529
6. Ubuntu USN-3867-1: MySQL vulnerabilities
7. Percona Server for MySQL 5.6.43-84.3 release
8. CISA Known Exploited Vulnerabilities Catalog