VMware ESXi Multiple DoS

VMSA-2014-0008 bundles third-party library updates for VMware vSphere. The two CVEs that produce the DoS finding — CVE-2013-0242 and CVE-2013-1914 — are glibc bugs: a buffer overflow in extend_buffers() in the regex engine, and a stack overflow in getaddrinfo() when parsing crafted hostnames/IPs. On an ESXi host these are reachable only if some management-plane service on the hypervisor actually feeds attacker-controlled input into regcomp/regexec or getaddrinfo. Affected builds are ESXi 5.0, 5.1, and 5.5 missing patch ESXi550-201409101-SG / ESXi510-201412101-SG; the CVSSv2 vector is AV:N/AC:L/Au:N/C:N/I:N/A:P (5.0, availability-only).

The vendor's MEDIUM rating was defensible in 2014 for a network-reachable, unauthenticated DoS against a hypervisor management daemon. In 2026 it is not. ESXi 5.x reached end-of-general-support in 2020 and end-of-technical-guidance in 2022; any host that still shows this plugin firing has vastly bigger problems than a glibc DoS — it is missing five years of ESXi CVEs including multiple pre-auth RCEs (Log4Shell in vCenter, OpenSLP CVE-2021-21974, CVE-2024-37085 domain-join).

Why this verdict

• Impact ceiling is DoS-only. C:N/I:N/A:P means best case for the attacker is crashing a management daemon that auto-restarts — no guest VM compromise, no hypervisor escape, no data.
• No exploitation signal. Not on KEV, EPSS < 1%, no public weaponization, no threat-actor reporting in twelve years.
• Affected surface is end-of-life. ESXi 5.0/5.1/5.5 hit end-of-technical-guidance in 2020–2022; any host still firing this plugin is exposed to dozens of newer, higher-severity CVEs (OpenSLP CVE-2021-21974, CVE-2024-37085) that dwarf a glibc DoS.
• Role multiplier — hypervisor role, chain does NOT succeed. ESXi is a canonical CRITICAL-floor deployment role, BUT the documented chain terminates at *hostd crash*, not guest escape, not vmkernel compromise, not vCenter takeover. The role multiplier does not fire because the blast radius is bounded to a temporary management-plane outage.
• Friction stacks: requires L3 access to an isolated management VLAN, requires a reachable code path funnelling attacker input into glibc regex/resolver, and no such path has been publicly demonstrated on ESXi.

Why not higher?

MEDIUM would require either a plausible RCE path or meaningful availability impact on guest workloads. Neither exists — hostd restarts automatically and VMs keep running. There is no KEV listing, no EPSS lift, and no public PoC to justify holding at MEDIUM.

Why not lower?

Not IGNORE because a management-plane DoS on a hypervisor still has operational cost during an outage, and organizations still running ESXi 5.x should recognize this plugin as a proxy indicator for a much larger patch-hygiene failure. Document it, don't dismiss it silently.

1. Confirm ESXi management interface is isolated — Restrict vmk0 to a dedicated management VLAN reachable only from jump hosts / PAM. This nullifies the entire attack path for this CVE and every other network-reachable ESXi bug. Per noisgate LOW guidance there is no mitigation SLA — treat as backlog hygiene during the next quarterly network review.
2. Migrate off ESXi 5.x entirely — 5.0/5.1/5.5 are past end-of-technical-guidance. If plugin 87679 fires you almost certainly also have unpatched OpenSLP, log4j, and CVE-2024-37085 exposure. Plan an upgrade to 7.0 U3 or 8.0 U3 within the noisgate remediation SLA of 365 days.
3. Enable ESXi lockdown mode — Normal or Strict lockdown restricts direct hostd API access to vCenter, shrinking the population of principals who can even attempt to reach the vulnerable parsers.
4. Monitor vmkernel.log for hostd restarts — Alert on repeated hostd stopped responding events — this is your DoS detection signal since network-level IDS won't catch glibc-level triggers.

Run this on the ESXi host itself via SSH as root, or adapt for esxcli over a vCenter proxy. Example: ssh [email protected] ./check_vmsa_2014_0008.sh. Requires shell access to the hypervisor.

#!/bin/sh
# check_vmsa_2014_0008.sh - detect ESXi builds missing VMSA-2014-0008 patches
# Run on target ESXi host as root.
# Exit: 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN / not applicable

set -u

if ! command -v vmware >/dev/null 2>&1; then
  echo 'UNKNOWN: vmware CLI not present — is this an ESXi host?'
  exit 2
fi

VER=$(vmware -v 2>/dev/null | awk '{print $3}')
BUILD=$(vmware -l 2>/dev/null | awk '{print $NF}')
echo "Detected ESXi version=${VER} build=${BUILD}"

case "$VER" in
  5.0*)  FIX_BUILD=2312428 ;;   # ESXi500-201412001
  5.1*)  FIX_BUILD=2323231 ;;   # ESXi510-201412001
  5.5*)  FIX_BUILD=2068190 ;;   # ESXi550-201409001
  6.*|7.*|8.*) echo 'PATCHED: ESXi 6.x/7.x/8.x not affected by VMSA-2014-0008'; exit 0 ;;
  *) echo 'UNKNOWN: unrecognized ESXi major version'; exit 2 ;;
esac

if [ -z "$BUILD" ] || ! echo "$BUILD" | grep -qE '^[0-9]+$'; then
  echo 'UNKNOWN: could not parse build number'
  exit 2
fi

if [ "$BUILD" -ge "$FIX_BUILD" ]; then
  echo "PATCHED: build ${BUILD} >= fix build ${FIX_BUILD}"
  exit 0
else
  echo "VULNERABLE: build ${BUILD} < fix build ${FIX_BUILD} — apply VMSA-2014-0008 patch"
  echo "NOTE: ESXi 5.x is end-of-support. Priority action is upgrade to 7.0 U3 or 8.0."
  exit 1
fi

Sources

1. Tenable plugin 87679
2. Broadcom / VMware VMSA-2014-0008
3. NVD CVE-2013-0242
4. NVD CVE-2013-1914
5. CISA KEV Catalog
6. FIRST EPSS
7. VMware Product Lifecycle Matrix
8. Vulners VMSA-2014-0008