ESXi 5

CVE-2015-7547 is the classic glibc getaddrinfo() stack buffer overflow in libresolv. When an application performs an A/AAAA lookup via AF_UNSPEC, glibc allocates a 2048-byte alloca buffer for the DNS response, but a specially crafted reply (over UDP or TCP) can write up to 65535 bytes into it — potentially leading to RCE as whatever process made the DNS query. Nessus plugin 88906 flags ESXi 5.5 builds < 3568722 and ESXi 6.0 builds < 3568940, which shipped a vulnerable glibc inside the userworld. Fixes landed in VMSA-2016-0002 on 2016-02-23.

Vendor severity of MEDIUM (CVSS v2 6.8) is a fair reflection of ESXi-specific reality even though the raw glibc CVE carries a CVSS v3 9.8. The exposed attack surface on a hypervisor is narrow — ESXi does relatively few outbound DNS lookups, and hitting the flaw requires either an attacker-controlled authoritative DNS server in the resolution path or on-path MitM between ESXi and its resolver. Where the score understates the risk is deployment role: this is a hypervisor, and code execution in a userworld process on ESXi is a stepping stone toward guest escape or vCenter pivot. But since both ESXi 5.5 and 6.0 have been end-of-general-support since 2018 and 2022 respectively, the real story is not the glibc bug — it's the unsupported hypervisor underneath it.

Why this verdict

• Attack path requires DNS injection position, not internet reachability — attacker must control an authoritative zone the host queries or MitM the resolver link, which implies post-initial-access on the management network.
• No KEV listing, no known ESXi campaign in the decade since disclosure; ransomware operators targeting ESXi consistently pick OpenSLP and vSphere Client bugs instead because they're pre-auth network-reachable.
• Role multiplier (hypervisor): the affected component IS a hypervisor userworld — canonically high-value. If the chain lands, blast radius reaches guest VMs and vCenter trust. This is why the verdict does NOT drop below MEDIUM despite the friction.
• Role multiplier ceiling check: to reach fleet-scale impact the attacker still needs a second bug (userworld → VMkernel LPE, or hostd credential theft). The glibc bug alone is a foothold, not a takeover — so the floor is HIGH-adjacent, and MEDIUM sits just below because chain success rates are historically zero.
• Both affected product lines are end-of-general-support (5.5 EOGS 2018, 6.0 EOGS 2022). Any host still exposed has bigger problems than glibc, and the correct action is decommission, not just patch.

Why not higher?

No sustained exploitation observed, no weaponized ESXi payload public, and the vulnerable DNS response path is not directly internet-reachable. Ransomware crews who own ESXi as a target class have not touched this bug in ten years — the empirical evidence for HIGH just isn't there.

Why not lower?

The affected component is a hypervisor userworld, so if the chain does land, blast radius touches guest tenancy and vCenter trust. That role weight prevents this from being LOW/IGNORE even though friction is high. A crashed hostd/vpxa also creates real availability impact on production clusters.

1. Decommission ESXi 5.5 and 6.0 hosts — Both lines are past Broadcom's end of general support (5.5 in 2018, 6.0 in 2022) and receive no security fixes for the dozens of vulnerabilities disclosed since. Migrate to 7.0U3 or 8.0U3 as the primary control — noisgate MEDIUM has no mitigation SLA, but treat the EOGS status itself as HIGH: begin migration planning within 30 days.
2. Segment ESXi management network from user/DNS attack surface — Put vmk0 (management) on a dedicated VLAN with an authoritative internal resolver you control. Block outbound UDP/TCP 53 from management VLANs to anything except that resolver. Apply within the 365-day noisgate remediation window; do it sooner because it mitigates dozens of other ESXi CVEs simultaneously.
3. Apply VMSA-2016-0002 patches now if you must keep the hosts — Bring 5.5 to build 3568722+ and 6.0 to build 3568940+. Patches are ten years old and stable — no change-control excuse holds up here.
4. Pin ESXi DNS to a hardened internal resolver with DNS response size clamping — Configure a BIND/Unbound resolver to drop DNS responses larger than 1232 bytes toward management-plane clients; this defeats the oversized-response condition required to overflow the 2048-byte alloca buffer.
5. Alert on ESXi hostd/vpxa userworld crashes — Forward vmkernel.log and hostd.log to your SIEM and alarm on unexpected userworld restarts — the exploit's most likely observable failure mode is a crash before RCE.

Run this on an auditor workstation with SSH access to the ESXi host (root or an admin role with shell). Invoke as ./check_88906.sh esxi-host.example.com — it SSHes in, reads vmware -v and the build, and compares against the fixed builds from VMSA-2016-0002. Requires SSH enabled on the target (Host → Services → SSH).

#!/usr/bin/env bash
# noisgate: CVE-2015-7547 / VMSA-2016-0002 / Nessus 88906 check
# Usage: ./check_88906.sh <esxi-host>
set -u

HOST="${1:-}"
if [ -z "$HOST" ]; then
  echo "Usage: $0 <esxi-host>" >&2
  exit 2
fi

SSH_OPTS="-o StrictHostKeyChecking=accept-new -o ConnectTimeout=10"
REMOTE=$(ssh $SSH_OPTS "root@${HOST}" 'vmware -v; vmware -l' 2>/dev/null) || {
  echo "UNKNOWN: cannot SSH to ${HOST}"; exit 3;
}

VER=$(echo "$REMOTE" | grep -Eo 'ESXi [0-9]+\.[0-9]+' | head -1 | awk '{print $2}')
BUILD=$(echo "$REMOTE" | grep -Eo 'build-[0-9]+' | head -1 | cut -d- -f2)

if [ -z "$VER" ] || [ -z "$BUILD" ]; then
  echo "UNKNOWN: could not parse version/build from '${REMOTE}'"; exit 3
fi

echo "Host ${HOST}: ESXi ${VER} build ${BUILD}"

case "$VER" in
  5.5)
    FIXED=3568722
    ;;
  6.0)
    FIXED=3568940
    ;;
  *)
    # 6.5+ shipped a non-vulnerable glibc; also note EOGS status separately
    echo "PATCHED: ESXi ${VER} not affected by CVE-2015-7547"
    exit 0
    ;;
esac

if [ "$BUILD" -lt "$FIXED" ]; then
  echo "VULNERABLE: build ${BUILD} < fixed ${FIXED} for ESXi ${VER}"
  echo "NOTE: ESXi ${VER} is end-of-general-support — decommission, do not just patch."
  exit 1
else
  echo "PATCHED: build ${BUILD} >= ${FIXED} for ESXi ${VER}"
  echo "NOTE: ESXi ${VER} is still end-of-general-support — plan migration to 7.0U3/8.0U3."
  exit 0
fi

Sources

1. Tenable plugin 88906
2. VMware VMSA-2016-0002
3. NVD — CVE-2015-7547
4. Google Security Blog — glibc getaddrinfo overflow
5. Red Hat vulnerability writeup
6. Exploit-DB 39454 (PoC)
7. Cloudflare — A tale of a DNS exploit
8. Rapid7 VulnDB — VMSA-2016-0002