A twelve-year-old glibc parser bug on a hypervisor line that Broadcom stopped shipping patches for half a decade ago
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).
3 steps from start to impact.
Reach the ESXi management network
esxi mostly return residential lab hosts.- Routable path to ESXi management VLAN
- Firewall rules permit inbound to vmk0
- Management interfaces are almost never internet-exposed in mature shops
- Segmentation policy typically restricts vmk0 to jump hosts
- vSphere HCL guidance has recommended isolation since 5.0
Deliver a malformed hostname or regex to a vulnerable code path
regcomp/regexec) or CVE-2013-1914 (crafted hostname/IP fed to getaddrinfo). Neither is directly reachable from the outside — the attacker must find a management-plane feature that parses attacker-supplied text as a regex or resolves an attacker-supplied hostname. No public weaponized PoC exists against ESXi.- A network-facing hostd/vpxa feature that funnels input to glibc regex or resolver
- No public PoC mapping the glibc bugs to a specific ESXi RPC
- Most exposed surfaces (SOAP API, DCUI, hostd) require auth
Crash the hostd/vpxa worker
- Overflow reaches an exploitable stack/heap layout
- hostd watchdog restarts the process automatically
- No VM guest impact, no data disclosure
hostd stopped responding events — this is your DoS detection signal since network-level IDS won't catch glibc-level triggers.- Edge WAF / IPS — the management interface should not traverse a WAF; if it does, your architecture problem is bigger than this CVE.
- EDR on the guest VMs — the bug lives in hostd on the hypervisor, not in guest OS user space.
- Disabling SSH on ESXi — this DoS path is via hostd/rhttpproxy on TCP/443, not SSH.
The supporting signals.
| In-the-wild exploitation | None observed. No CISA KEV entry, no Mandiant/CrowdStrike/Unit42 campaign reporting for CVE-2013-0242 or CVE-2013-1914 against ESXi. |
|---|---|
| Public PoC | glibc-level PoCs exist in academic form but no weaponized ESXi exploit is public. No Metasploit / Nuclei / ExploitDB module targets this VMSA. |
| EPSS | Both CVEs sit at <0.5% probability, sub-40th percentile — noise-floor forecast. |
| KEV status | Not listed in CISA Known Exploited Vulnerabilities catalog. |
| CVSS | CVSS2#AV:N/AC:L/Au:N/C:N/I:N/A:P — score 5.0, availability-only, no confidentiality/integrity impact. |
| Affected versions | ESXi 5.0, 5.1, 5.5 missing patches ESXi500-201412101-SG, ESXi510-201412101-SG, ESXi550-201409101-SG. 6.x/7.x/8.x are not affected. |
| Fixed versions | ESXi 5.5 patch ESXi550-201409101-SG (Sep 2014); ESXi 5.1 patch ESXi510-201412101-SG (Dec 2014); ESXi 5.0 patch ESXi500-201412101-SG (Dec 2014). |
| Exposure telemetry | Shodan shows ~thousands of internet-facing ESXi hosts total; 5.x share is residual (<3%) and shrinking. Most orgs are on 6.7/7.0/8.0 by 2026. |
| Disclosure | glibc bugs disclosed 2013-01-29; VMware advisory issued 2014-09-09, updated 2014-12-04. |
| Reported by | glibc upstream (Bugzilla 14134, 15078); rolled into VMSA-2014-0008 by VMware Security Response. |
Sources.
Why this verdict
- Impact ceiling is DoS-only.
C:N/I:N/A:Pmeans 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.
Crowdsourced verification payload.
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