tenable:103375 · ESXi 5.5 < Build 6480267 RPC NULL Pointer Dereference Vulnerability…

01 · The Real Story

A guest OS user can crash its own VM by sending a malformed RPC — a self-inflicted wound with no host escape

CVE-2017-4925 is a NULL pointer dereference in the VMware guest RPC handler. A local user *inside* a guest VM can send a crafted RPC that causes the VMX process to hit an unmapped pointer, crashing that single virtual machine. The bug lives on VMware ESXi 5.5 before build 6480267 (patch ESXi550-201709101-SG), ESXi 6.0 before ESXi600-201706101-SG, ESXi 6.5 before ESXi650-201707101-SG, Workstation 12.x < 12.5.3, and Fusion 8.x < 8.5.4. There is no host takeover, no cross-VM impact, no data disclosure — the CVSS vector AV:L/AC:L/PR:L/UI:N/C:N/I:N/A:H says exactly that.

Tenable's original *LOW* tag is generous on the low side; NVD and VMware both scored it *Medium* (5.5). Reality sits between the two: the impact ceiling is a single VM crash by someone who already has a login on that VM. That's a nuisance, not a breach. The bigger story is that if this plugin is still firing in your environment in 2026, the finding you actually care about is "we are running ESXi 5.5, which reached end-of-general-support in September 2018 and end-of-technical-guidance in September 2020." That platform-age problem dwarfs the RPC bug by orders of magnitude.

"Guest-side DoS against a 9-year-old ESXi build that shouldn't be in your fleet at all. Life-support code, not a security emergency."

02 · The Attack Path

3 steps from start to impact.

STEP 01

Attacker gains a shell inside a guest VM

The vulnerable code path lives in the guest RPC channel, meaning the attacker must be executing code inside a guest operating system running on the vulnerable ESXi host. This is AV:L — local to the guest, not reachable across the network. Typical positions: compromised in-guest workload, a rogue tenant on a shared cluster, or an insider on a jump box.

Conditions required:

Valid guest OS session (any privileges)
Guest has VMware Tools / RPC channel active

Where this breaks in practice:

Requires prior compromise or legitimate access to a guest VM
Cannot be triggered from the management network, from another VM, or from the internet

Detection/coverage: No network signature — the RPC traffic is intra-hypervisor. Detection is by ESXi build inventory (Nessus 103375, Qualys 216307, Rapid7 vmware-esxi-cve-2017-4925).

STEP 02

Send crafted guest RPC (rpctool / vmware-rpctool)

Attacker uses the standard vmware-rpctool binary shipped with VMware Tools, or a raw backdoor-channel client (e.g., open-vm-tools rpctool.c), to send the malformed RPC command that trips the NULL deref in VMX. No custom exploit framework is required — a shell one-liner is sufficient.

Conditions required:

VMware Tools installed OR ability to write raw hypercalls via the VMware backdoor port

Where this breaks in practice:

Guests without VMware Tools still expose the backdoor port but require slightly more work
Nothing else really stops this step — the RPC is a legitimate interface

Detection/coverage: VMX core dumps and hostd.log / vmware.log entries showing VMX signal handler firing are the only host-side signal.

STEP 03

VMX process crashes → guest VM powers off

The VMX worker process for that specific VM dies. HA/DRS will typically restart the VM on the same or another host. There is no impact on other VMs, no impact on the hypervisor itself, and no escape. Impact is bounded to A:H for one VM.

Conditions required:

No preconditions beyond step 2

Where this breaks in practice:

HA restarts the VM automatically
vSphere clusters usually treat this as an ordinary VMX fault

Detection/coverage: vCenter event VM powered off unexpectedly; ESXi vmkernel.log entries.

03 · Compensating Control

Retire ESXi 5.5 hosts — The plugin fires because the host is a decade behind. Migrate workloads to ESXi 7.0 U3 or 8.0 U3 (or an actively-supported hypervisor). No mitigation SLA for a LOW verdict — treat as backlog under the noisgate remediation SLA of ≤ 365 days, but the underlying EOL platform finding should carry its own HIGH-severity ticket with a tighter timeline.

Restrict who gets guest-OS shells — Because the bug is AV:L/PR:L, controlling who lands on a guest neutralizes the primitive. Enforce least-privilege on guest OS accounts, MFA on jump hosts, and remove interactive logins from service tenants.

Apply VMware patch ESXi550-201709101-SG on any 5.5 host you cannot retire this quarter — This is the vendor's fix. It's a stopgap while migration proceeds. Do not treat patching a 5.5 host as a substitute for getting off 5.5.

Confirm HA/DRS is enabled and healthy on the cluster — If someone does trigger the VMX crash, HA restarts the guest. Verify admission control and heartbeat datastores so restart actually succeeds.

What doesn't work

Perimeter firewalls / NGFW — the RPC channel is intra-hypervisor and never touches the network.
WAF / reverse proxies — irrelevant, this isn't an HTTP surface.
Disabling vCenter access from the internet — the attacker is inside a guest, not calling the management plane.
EDR on the guest — the crash happens in the VMX process on the host, not in a guest process an EDR could observe.

04 · Intelligence Metadata

The supporting signals.

CVE	CVE-2017-4925 (VMSA-2017-0015)
In-the-wild exploitation	None observed. Not on CISA KEV. No public campaigns reference this CVE.
Public PoC	No dedicated PoC repositories. The attack primitive is trivially reproducible with `vmware-rpctool` from `open-vm-tools`, but no packaged exploit exists.
EPSS	0.00019 (~0.02%) — bottom-decile exploitation probability.
KEV status	Not listed. CISA has never added this CVE.
CVSS v3.1 vector	`AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H` → 5.5 Medium. Local vector, low privileges, availability-only impact, no scope change — no confidentiality or integrity loss.
Affected versions	ESXi 5.5 < build 6480267; ESXi 6.0 < `ESXi600-201706101-SG`; ESXi 6.5 < `ESXi650-201707101-SG`; Workstation 12.x < 12.5.3; Fusion 8.x < 8.5.4
Fixed versions	ESXi 5.5 build 6480267 (`ESXi550-201709101-SG`), and the 6.0/6.5 patches noted above. ESXi 5.5 itself is EOL since Sep 19 2020.
Exposure telemetry	Shodan surfaces a small tail of internet-facing ESXi 5.5 hosts (low thousands globally, mostly SMB and lab); GreyNoise shows no meaningful scanning for this specific CVE — attackers targeting old ESXi go straight for OpenSLP / vSphere heap CVEs instead.
Disclosed	2017-09-15 by VMware in VMSA-2017-0015. Reporter: internal VMware.

Sources.

05 · The Call

Final Verdict

= UNCHANGED to LOW (3.1/10)

Why this verdict

Impact ceiling is A:H on one VM. The CVSS vector explicitly denies confidentiality, integrity, and scope change. No hypervisor escape, no neighbor-VM impact, no host root.
Attacker must already be in the guest. AV:L + PR:L means initial access is prerequisite. If they're already there, a shutdown -h now achieves the same outcome without needing a CVE.
Zero exploitation signal. EPSS 0.00019, not KEV-listed, no PoC repos, no campaign attribution in 9 years since disclosure.
Role multiplier: hypervisor. ESXi *is* a canonical high-value role component, so the floor rule applies — but the chain does not yield host or fleet compromise here. The blast radius stops at one guest. Floor rule does not lift the verdict above LOW.
Role multiplier: multi-tenant cluster. Even on a shared-tenancy ESXi cluster, a tenant crashing their own VM is not a cross-tenant event. HA restarts the workload. No lift.
The real risk is the platform, not the CVE. If plugin 103375 is firing, you're running ESXi 5.5, which has been out of technical guidance since Sep 2020. That platform-EOL finding is what should drive your remediation ticket.

Why not higher?

MEDIUM would imply meaningful operational risk beyond a single-VM crash, but the vector precludes any cross-VM or host impact and no exploitation has materialized in nearly a decade. HIGH or CRITICAL are unreachable — there is no confidentiality or integrity primitive here, and no escape.

Why not lower?

IGNORE is tempting because the CVE-level impact is trivial, but the plugin is a reliable proxy for an EOL ESXi 5.5 host, which is a legitimate remediation obligation. Keeping it LOW preserves that signal in the backlog instead of muting it.

06 · Verification

Crowdsourced verification payload.

Run this on the ESXi host itself via SSH as root (or on a jump box with esxcli remote credentials configured). Invocation: ./check-cve-2017-4925.sh (no arguments). It reads the build number from vmware -v / esxcli system version get and compares against the patched build 6480267.

noisgate-verify.sh

BASHREAD-ONLYSAFE

#!/usr/bin/env bash
# check-cve-2017-4925.sh
# Verifies ESXi 5.5 host is at or beyond build 6480267 (VMSA-2017-0015).
# Exit codes: 0 PATCHED, 1 VULNERABLE, 2 UNKNOWN, 3 NOT_APPLICABLE
set -u

PATCHED_BUILD_55=6480267
PATCHED_BUILD_60=5572656   # ESXi600-201706101-SG
PATCHED_BUILD_65=5969303   # ESXi650-201707101-SG

if ! command -v esxcli >/dev/null 2>&1; then
  echo "UNKNOWN: esxcli not found — run this on the ESXi host" >&2
  exit 2
fi

VER=$(esxcli system version get 2>/dev/null | awk -F': *' '/Version/ {print $2}')
BUILD=$(esxcli system version get 2>/dev/null | awk -F': *' '/Build/ {print $2}' | tr -dc '0-9')

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

case "$VER" in
  5.5.*) MIN=$PATCHED_BUILD_55 ;;
  6.0.*) MIN=$PATCHED_BUILD_60 ;;
  6.5.*) MIN=$PATCHED_BUILD_65 ;;
  *)     echo "NOT_APPLICABLE: ESXi $VER build $BUILD (fixed baseline in 6.7+)"; exit 3 ;;
esac

if (( BUILD >= MIN )); then
  echo "PATCHED: ESXi $VER build $BUILD >= $MIN"
  exit 0
else
  echo "VULNERABLE: ESXi $VER build $BUILD < $MIN (CVE-2017-4925)"
  echo "NOTE: ESXi 5.5 reached End of Technical Guidance on 2020-09-19 — treat as EOL, not just unpatched." >&2
  exit 1
fi