ESXi 5

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.

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.

1. 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.
2. 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.
3. 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.
4. 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.

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.

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

Sources

1. Tenable plugin 103375
2. CVE-2017-4925 (Tenable)
3. VMware VMSA-2017-0015 advisory
4. NVD entry for CVE-2017-4925
5. CVE Details — VMware ESXi 5.5 vulnerabilities
6. VMware Product Lifecycle Matrix (ESXi 5.5 EOL dates)
7. CISA Known Exploited Vulnerabilities Catalog
8. FIRST EPSS data for CVE-2017-4925