VMware ESXi 5

CVE-2018-6972 is a NULL pointer dereference in the ESXi RPC handler reachable from inside a guest VM. An authenticated user *inside* a guest — with normal user privileges — sends malformed RPC traffic to the hypervisor's guest-communication interface and crashes their *own* VM. Affected builds are ESXi 5.5 before ESXi550-201806401-BG, 6.0 before ESXi600-201806401-BG, 6.5 before ESXi650-201806401-BG, 6.7 before ESXi670-201806401-BG, plus Workstation 14.x < 14.1.2 and Fusion 10.x < 10.1.2.

Vendor labeled this MEDIUM (CVSS 6.5, AV:N/AC:L/PR:L/UI:N/C:N/I:N/A:H) — and that's overstated for anyone reading it as 'network-reachable hypervisor DoS.' The AV:N is technically correct (RPC is delivered over VMCI which VMware categorizes as network) but the blast radius is a single guest crashing itself. No host escape, no cross-VM impact, no data disclosure. The realistic scoring is CVSS AV:L/S:U/A:L territory — call it a *low*.

Why this verdict

• Self-DoS only: the confirmed impact is the guest crashing itself. Any attacker with the guest shell needed to trigger this can crash the same VM with a signal.
• No lateral or upward reach: hypervisor does not crash, other VMs continue running, host memory is not disclosed. Role multiplier does NOT apply — despite ESXi being a canonical high-value hypervisor role, the chain simply does not reach the host or peer guests.
• Role multiplier — hypervisor: the affected component IS ESXi (Tier 0 hypervisor role), but the exploit outcome ends at the caller's own guest. Blast radius stops at local. The role floor of CRITICAL that normally applies to ESXi bugs does not trigger here because the chain does not escape the guest boundary.
• Age + zero exploitation: disclosed July 2018, no KEV listing, no public PoC, no known campaign use in ~8 years. EPSS bottom decile.
• Compensating patch cadence: any ESXi 6.7-and-below still running in 2026 is already outside vendor support and carries dozens of higher-priority CVEs (ESXiArgs, CVE-2021-21974, CVE-2024-37085, etc.). This CVE is not the pivot decision.

Why not higher?

MEDIUM would imply a plausible operational risk to a defender's fleet. The chain terminates at self-DoS; the attacker gains nothing they didn't already have as an authenticated guest user. There is no path to hypervisor escape, no cross-VM impact, and no confidentiality/integrity impact.

Why not lower?

IGNORE would be defensible on modern ESXi 7.x/8.x fleets that are unaffected. It is not appropriate for shops still running ESXi ≤6.7 — but the reason to act there is that the *entire supported baseline* is gone, not this specific bug. LOW captures the residual signal-to-noise for legacy-fleet inventories.

1. Confirm you are not running ESXi ≤6.7 anywhere in production — If the answer is 'yes,' this CVE is the least of your problems. All four affected release lines are past end-of-general-support. Prioritize migration to 7.0 U3 or 8.0 U3 — the LOW verdict here means no mitigation SLA; roll it into your existing EOL-remediation workstream (365-day window).
2. For any remaining legacy VM: harden VMware Tools RPC per-VM — Set isolation.tools.hgfs.disable = TRUE, isolation.tools.copy.disable = TRUE, isolation.tools.paste.disable = TRUE, and evaluate isolation.tools.setinfo.disable. Won't fully block this specific RPC path but reduces the guest→hypervisor attack surface generally.
3. Treat guest-user access as the actual boundary — This bug requires an authenticated guest user. Your control here is normal guest-OS hardening: SSO/MFA on VM console access, least-privilege for tenant users, EDR inside guests. Same controls cover this and every other guest-scoped issue.
4. Suppress this finding as noise below MEDIUM in the scanner — Tenable ranks it MEDIUM by default. Add a suppression rule tied to CVE-2018-6972 with a note pointing to the platform-EOL remediation ticket, so your scan queue reflects real risk.

Run on the ESXi host itself as root via SSH (or from an ESXCLI-authorized workstation with esxcli --server=<host>). Example: ssh root@esxi01 'sh /tmp/check-cve-2018-6972.sh'. Reads the ESXi build number and compares against the patched thresholds from VMSA-2018-0018.

#!/bin/sh
# check-cve-2018-6972.sh — VMSA-2018-0018 / CVE-2018-6972
# Reports VULNERABLE / PATCHED / UNKNOWN based on ESXi build number.
# Run on the ESXi host as root.

set -u

VER=$(vmware -v 2>/dev/null | awk '{print $3}')
BUILD=$(vmware -v 2>/dev/null | awk -F'build-' '{print $2}')

if [ -z "${VER:-}" ] || [ -z "${BUILD:-}" ]; then
  echo "UNKNOWN: could not read ESXi version/build"
  exit 2
fi

echo "Detected ESXi $VER build $BUILD"

# Patched builds from VMSA-2018-0018
# 5.5 -> 9313334 (ESXi550-201806401-BG)
# 6.0 -> 9239799 (ESXi600-201806401-BG)
# 6.5 -> 9298722 (ESXi650-201806401-BG)
# 6.7 -> 9214924 (ESXi670-201806401-BG)
case "$VER" in
  5.5*) MIN=9313334 ;;
  6.0*) MIN=9239799 ;;
  6.5*) MIN=9298722 ;;
  6.7*) MIN=9214924 ;;
  7.*|8.*) echo "PATCHED: ESXi $VER is not in the affected range"; exit 0 ;;
  *) echo "UNKNOWN: unrecognized ESXi major version $VER"; exit 2 ;;
esac

if [ "$BUILD" -ge "$MIN" ] 2>/dev/null; then
  echo "PATCHED: build $BUILD >= $MIN"
  exit 0
else
  echo "VULNERABLE: build $BUILD < $MIN (VMSA-2018-0018)"
  echo "NOTE: ESXi $VER is end-of-general-support. Prioritize upgrade to 7.0U3 or 8.0U3."
  exit 1
fi

Sources

1. Tenable plugin 134878
2. VMware VMSA-2018-0018 advisory (Broadcom)
3. CVE-2018-6972 details (cvedetails)
4. GHSA-xmm5-6qh4-9f74 (GitHub advisory)
5. Rapid7 VulnDB writeup
6. SecurityTracker 1041357
7. Tenable CVE record
8. CISA KEV catalog (not listed)