tenable:134878 · VMware ESXi 5.5 / 6.0 / 6.5 / 6.7 DoS (VMSA-2018-0018) (remote check)

01 · The Real Story

A hotel guest can slam their own room door hard enough to break their own lock — and that's the whole vulnerability

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*.

"Guest-to-own-guest DoS from 2018. If you're still on ESXi 5.5/6.0/6.5/6.7 in 2026, this CVE is the least of your problems."

02 · The Attack Path

3 steps from start to impact.

STEP 01

Attacker gets a shell inside a guest VM

The attacker must already be an authenticated local user inside a running guest VM on the hypervisor. Any normal user account inside the guest OS is sufficient — no admin or root required inside the guest.

Conditions required:

Valid guest OS credentials or existing foothold inside the VM

Where this breaks in practice:

If the attacker already has a guest shell, they can already disrupt their own workload trivially by any other means (e.g. shutdown, forkbomb, dd if=/dev/zero)

Detection/coverage: Standard EDR on the guest catches the foothold long before this CVE matters

STEP 02

Send malformed RPC to VMware Tools RPC interface

The attacker calls the VMCI/backdoor RPC channel (via vmware-rpctool or a custom client using the VMBackdoor/vmcheck interfaces) with a crafted request that trips the NULL pointer dereference in the hypervisor's RPC handler. Public PoC for this specific CVE was never widely published; the closest reference is guest-tools RPC fuzzing harnesses from ZDI research.

Conditions required:

VMware Tools RPC channel is enabled (default)
Guest can invoke rpctool or equivalent

Where this breaks in practice:

Disabling VMware Tools RPC breaks legitimate functionality but is possible per-VM via isolation.tools.* settings

Detection/coverage: No off-the-shelf detection — this is normal-looking VMCI traffic to the hypervisor

STEP 03

The attacker's own VM freezes

The RPC handler dereferences NULL and the affected VM stops responding. Per VMware's own writeup and SecurityTracker's summary, the impact is confined to the guest that sent the message. Other VMs on the same host continue running, the host itself does not crash, and there is no privilege escalation or host escape.

Conditions required:

N/A — this is the terminal state

Where this breaks in practice:

The attacker has DoS'd only themselves. To affect other tenants they'd need a foothold in each of those VMs — at which point they don't need this CVE

Detection/coverage: vCenter reports the VM as unresponsive; requires a reset. No trail of who did it beyond guest-side logs.

03 · Compensating Control

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).

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.

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.

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.

What doesn't work

Network segmentation of the ESXi management VLAN — the attack rides the guest-to-hypervisor VMCI channel, not management network, so ACLs on vmk0 do nothing
vCenter role hardening — the attacker never touches vCenter; they're inside the guest OS
Guest firewall rules on the affected VM — RPC is delivered via VMware Tools over the hypervisor backdoor, not IP traffic

04 · Intelligence Metadata

The supporting signals.

CVE	CVE-2018-6972 / VMSA-2018-0018
CWE	CWE-476 NULL Pointer Dereference
Vendor CVSS	6.5 MEDIUM — `CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H`
In-the-wild	No known exploitation. Not in CISA KEV. Zero credible campaign reports in 8 years.
EPSS	Bottom decile (<0.1%, <5th percentile) — reflects DoS-only, self-scoped nature
Public PoC	None public. Discovered by ZDI-anon submissions; no Metasploit/Exploit-DB module
Affected	ESXi 5.5/6.0/6.5/6.7 pre-July-2018 patches; Workstation 14.x < 14.1.2; Fusion 10.x < 10.1.2
Fixed	ESXi550-201806401-BG, ESXi600-201806401-BG, ESXi650-201806401-BG, ESXi670-201806401-BG
Disclosed	2018-07-19 — nearly 8 years old
Product EOL	All four affected ESXi lines are end-of-general-support. ESXi 6.7 EOGS was 2022-10-15. If you have these in prod in 2026 the CVE list is enormous.
Scanner exposure	Shodan shows the residual ESXi 6.x population is measured in a few thousand hosts globally — a rounding error against the 8.x install base

Sources.

05 · The Call

Final Verdict

↓ DOWNGRADED to LOW (2.5/10)

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.

06 · Verification

Crowdsourced verification payload.

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.

noisgate-verify.sh

BASHREAD-ONLYSAFE

#!/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