A decade-old library DoS on a hypervisor version that's been dead for six years
Tenable plugin 78108 flags ESXi 5.5 hosts running a build below 1980513 (patch bundle ESXi550-201409101-SG, September 2014) as carrying two glibc flaws: CVE-2013-0242 (buffer overflow in glibc's regex extend_buffers) and CVE-2013-1914 (stack overflow in getaddrinfo when handling huge domain conversions). Both are remote denial-of-service bugs — no code execution, no privilege gain, just a crash of whatever userland process on the ESXi busybox environment happens to call the affected glibc paths.
Vendor severity of MEDIUM (CVSSv2 5.0, AV:N/AC:L/Au:N/C:N/I:N/A:P) is generous for 2026. The vuln is a DoS in a library path that on ESXi is barely reachable from the network — the hypervisor doesn't expose a general-purpose resolver or regex service to untrusted callers. More importantly, ESXi 5.5 reached General Support end-of-life on 19 September 2018 and Technical Guidance end on 19 September 2020. Any 5.5 host in your estate in 2026 is a compliance failure long before this specific plugin fires.
3 steps from start to impact.
Reach a glibc-consuming service on the ESXi host
regcomp/regexec or getaddrinfo code paths with attacker-controlled input. ESXi's userland is a stripped busybox; the management agents (hostd, vpxa, DCUI) and OpenSLP are the realistic candidates, but none of them expose regex or DNS lookup surface to unauthenticated remote callers by design.- Network path to ESXi management interface (443/902/427)
- A daemon on the host that passes attacker input to the vulnerable glibc call
- Management network should be segmented per VMware hardening guide
- No daemon in the default ESXi stack invokes
regexecon untrusted input - getaddrinfo is called on config-supplied hostnames, not attacker payloads
Trigger the glibc bug
- Vulnerable code path reachable
- Ability to send crafted input
- ESXi is not a general-purpose Linux — attack surface is narrow and predefined
- Even a successful trigger crashes a userland helper, not the VMkernel
Impact: userland process crash
- Trigger reached vulnerable path
- Hypervisor scheduling and running VMs are unaffected
- hostd auto-restarts
nmap -sT -p 443,902,427 from a general user VLAN — no response is the expected result.esxcli software vib install on the last-available offline depot. This is compliance theatre relative to the platform's larger exposure but closes the specific plugin finding./etc/init.d/slpd stop && chkconfig slpd off. If you own ESXi 5.5 hosts in 2026, do this today.- EDR on the ESXi host — ESXi's stripped userland does not run standard EDR agents; you cannot detect the crash chain at the endpoint layer
- WAF / reverse proxy in front of vSphere Web Client — vulnerable glibc paths are inside management-plane daemons, not behind the web tier
- Disabling DNS on the host —
getaddrinfois called by many internal paths (vpxa peer discovery, NTP, syslog forwarders); disabling resolver breaks the cluster before it helps
The supporting signals.
| CVEs | CVE-2013-0242 (glibc regex extend_buffers overflow), CVE-2013-1914 (glibc getaddrinfo stack overflow) |
|---|---|
| In-the-wild exploitation | None known against ESXi. Not on CISA KEV. No ransomware crew or APT campaign references these CVEs against hypervisors. |
| EPSS | Both CVEs sit well under 1% probability, roughly 0.1–0.4 percentile — treated as noise by FIRST's model |
| KEV status | Not listed |
| CVSS | CVSSv2 5.0 (AV:N/AC:L/Au:N/C:N/I:N/A:P) — network reachable, no auth, availability-only impact. No CVSSv3 vector published by VMware for this bundle. |
| Affected build | ESXi 5.5 < build 1980513 |
| Fixed build / patch | ESXi550-201409101-SG, released 2014-09-09 |
| Product lifecycle | ESXi 5.5 General Support ended 2018-09-19; Technical Guidance ended 2020-09-19. No upstream patches since. |
| PoC availability | Public PoCs exist for the underlying glibc bugs (oss-security, Red Hat Bugzilla). No public ESXi-targeted PoC. |
| Exposure data | Shodan queries for ESXi 5.5 return a shrinking long-tail (<a few thousand globally in 2026), dominated by neglected lab and hoster infra — not typical enterprise fleets |
| Disclosure | Underlying glibc CVEs disclosed 2013-01-29; VMware bundle 2014-09-09 |
Sources.
Why this verdict
- Impact is availability-only: C:N/I:N/A:P. No code execution, no VM escape, no credential exposure. The worst outcome is a management-agent crash while VMs keep running.
- Attack surface on ESXi is closed: the vulnerable glibc paths (
regexec,getaddrinfo) are not fed by unauthenticated network input in the default ESXi 5.5 service stack. There is no public weaponization pathway. - Role multiplier — the hypervisor: ESXi is canonically a high-value role, so any RCE here would floor at CRITICAL. But this bug does not chain to RCE or VM escape; the role multiplier does not fire because the impact is bounded to a process crash.
- Zero threat activity: not KEV, EPSS <1%, no campaigns, no ransomware TTPs reference it.
- Product EoL dwarfs the CVE: any ESXi 5.5 host in production in 2026 is exposed to dozens of far worse unpatched CVEs (VMSA-2020-0026, VMSA-2021-0002 OpenSLP RCE / KEV, VMSA-2023-0001 vCenter chain). Fix the platform, not this bug.
Why not higher?
Vendor MEDIUM assumes the network-reachable + availability-impact classification alone justifies mid-tier. In 2026, on this component, that math no longer holds: there is no realistic unauthenticated reach into the vulnerable glibc paths on ESXi's userland, no public exploit targeting the hypervisor surface, and the impact ceiling is a process crash. Nothing about this specific CVE pair warrants LOW or MEDIUM prioritization.
Why not lower?
It is not literally impossible — a determined attacker with management-network access could conceivably force a hostd restart via a crafted management-plane request. That is why the reassessed score is 2.5, not 0.0. But operationally, if you can reach an ESXi 5.5 management plane, you are already in a game-over posture that this plugin does not describe.
Crowdsourced verification payload.
Run on the target ESXi host itself over SSH as root (enable SSH temporarily via DCUI or vCenter). Invoke as ./check-tenable-78108.sh. Reports VULNERABLE if the host is ESXi 5.5 below build 1980513, PATCHED if at/above, UNKNOWN if not ESXi 5.5.
#!/bin/sh
# noisgate check — Tenable 78108 / ESXi 5.5 glibc (CVE-2013-0242, CVE-2013-1914)
# Target: ESXi host shell. Requires: root.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
set -u
FIXED_BUILD=1980513
if ! command -v vmware >/dev/null 2>&1; then
echo "UNKNOWN: not an ESXi host"
exit 2
fi
VER_LINE=$(vmware -v 2>/dev/null)
# Expected: 'VMware ESXi 5.5.0 build-XXXXXXX'
MAJOR=$(echo "$VER_LINE" | awk '{print $3}' | cut -d. -f1,2)
BUILD=$(echo "$VER_LINE" | sed -n 's/.*build-\([0-9][0-9]*\).*/\1/p')
if [ "$MAJOR" != "5.5" ]; then
echo "UNKNOWN: host is ESXi $MAJOR, plugin 78108 only applies to 5.5"
exit 2
fi
if [ -z "$BUILD" ]; then
echo "UNKNOWN: could not parse build number from: $VER_LINE"
exit 2
fi
if [ "$BUILD" -lt "$FIXED_BUILD" ]; then
echo "VULNERABLE: ESXi 5.5 build $BUILD < $FIXED_BUILD (CVE-2013-0242, CVE-2013-1914)"
echo "NOTE: ESXi 5.5 is end-of-Technical-Guidance since 2020-09-19. Decommission, do not just patch."
exit 1
fi
echo "PATCHED: ESXi 5.5 build $BUILD >= $FIXED_BUILD"
echo "NOTE: ESXi 5.5 remains end-of-life. Migrate to a supported release."
exit 0