← Back to Feed CACHED · 2026-07-10 09:25:50 · CACHE_KEY tenable:81085
tenable:81085 · CWE-327 · Disclosed 2015-01-27

ESXi 5

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
Do you agree?
01 · The Real Story

A decade-old patch bundle on a hypervisor that Broadcom stopped supporting in 2020

Plugin 81085 flags any ESXi 5.5 host at a build below 2352327 (January 2015 patch level) as vulnerable to a bundle of seven CVEs, dominated by POODLE (CVE-2014-3566), a handful of OpenSSL companion bugs (CVE-2014-3513, -3567, -3568), a libxml2 entity-expansion DoS (CVE-2014-3660), and a vmware-authd DoS (CVE-2014-8370). The most notable is CVE-2015-1044, an information-disclosure flaw in the ESXi authentication handling. Fix is patch bundles ESXi550-201403102-SG and ESXi550-201501101-SG, which by 2026 are ancient.

Tenable calls this HIGH (CVSSv2 8.1). Vendor listing you were shown as MEDIUM undersells reality: the underlying CVEs are individually medium-grade (mostly SSL/TLS MitM and DoS), but the *host* still failing this check in 2026 is running ESXi 5.5, which reached General Support end-of-life on 19 Sep 2018 and Technical Guidance EOL on 19 Sep 2020. There are no more patches, no more advisories, and every VMSA published since — including the 2024–2025 hypervisor escape wave — is unaddressable. MEDIUM is wrong. HIGH is right, and the reason isn't POODLE.

"ESXi 5.5 is a hypervisor five years past EOL. The bugs are old and mostly DoS/MitM — but the platform itself is the crisis."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Locate the aging hypervisor

Attacker inside the environment (or scanning the perimeter of a poorly segmented DMZ) fingerprints ESXi hosts on TCP/443 and TCP/902. Nmap NSE http-vmware-path-vuln and Nessus's own banner grab identify the 5.5 build immediately. Shodan and Censys still list a small residual population of internet-exposed 5.5 hosts primarily in SMB and lab environments.
Conditions required:
  • Network reachability to ESXi management interface
  • TCP/443 or TCP/902 open
Where this breaks in practice:
  • Well-run shops isolate the ESXi management VLAN
  • vCenter typically fronts host management
Detection/coverage: Trivial — every VM scanner (Nessus, Qualys, Rapid7, Tenable.io) fingerprints ESXi build from the SOAP endpoint.
STEP 02

Downgrade TLS to SSL 3.0 (POODLE)

If the attacker can MitM an admin session (ARP spoof on the mgmt VLAN, rogue AP, or upstream tap), openssl s_client and Thomas Pornin's original POODLE POC force renegotiation to SSL 3.0 CBC and decrypt one byte per ~256 requests. Practical only against long-lived cookies or basic-auth headers.
Conditions required:
  • Active MitM position on ESXi mgmt traffic
  • Client that still speaks SSLv3
  • Victim initiates many requests
Where this breaks in practice:
  • Modern browsers dropped SSLv3 in 2014-2015
  • vSphere Client and PowerCLI negotiate TLS 1.2+
  • Requires attacker-controlled JavaScript or long-lived session
Detection/coverage: IDS signatures for SSLv3 ClientHello (Suricata SID 2019416) fire loudly. Any modern SIEM will catch it.
STEP 03

Trigger DoS via libxml2 / vmware-authd

CVE-2014-3660 (billion laughs / entity expansion) and CVE-2014-8370 (input validation in vmware-authd) let an authenticated or network-adjacent attacker knock the management daemon offline. Both are DoS, not code execution — the guest VMs keep running but the admin loses control plane access.
Conditions required:
  • Reachable vmware-authd (TCP/902)
  • Ability to send crafted XML/auth payload
Where this breaks in practice:
  • No lateral movement value — DoS only
  • Watchdog restarts most daemons
Detection/coverage: vmkernel and hostd logs show crashes; any monitoring of hostd uptime catches it.
STEP 04

Pivot to the real problem — every VMSA since 2020

This is where the reassessment lands. An ESXi 5.5 host that failed plugin 81085 is also unpatched against VMSA-2021-0002 (CVE-2021-21974 — the ESXiArgs ransomware vector), the OpenSLP RCE chain, and everything Broadcom shipped through VMSA-2025-0010 including CVE-2025-41238. None of these have patches for 5.5. Any RCE on ESXi is a fleet-defining event: one host = every VM on it, and lateral movement to vCenter = the datacenter.
Conditions required:
  • Continued operation of ESXi 5.5
  • Any network path to the host
Where this breaks in practice:
  • None — this is unfixable on 5.5
Detection/coverage: Nessus plugins for VMSA-2021-0002 (146157) and VMSA-2023-0001 already flag these separately. Plugin 81085 is a canary for a much bigger problem.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusPOODLE actively exploited in downgrade research since 2014. CVE-2021-21974 (an unpatchable follow-on for these hosts) exploited by ESXiArgs ransomware from Feb 2023.
KEV statusThe specific 2014 CVEs are not in CISA KEV. However, downstream ESXi CVEs the host is now defenseless against — including CVE-2023-20867, CVE-2023-34048 — are KEV-listed.
PoC availabilityPOODLE PoC public since 2014 (Bodo Möller/Thomas Duong/Krzysztof Kotowicz, Google). openssl s_client reproduces trivially.
EPSSCVE-2014-3566 (POODLE): ~0.94 (94th percentile). CVE-2015-1044: ~0.05.
CVSSTenable aggregate 8.1 (CVSSv2 AV:N/AC:M/Au:N/C:C/I:P/A:N). Vendor MEDIUM label understates.
Affected versionsESXi 5.5 at any build below 2352327 (2015-01-27).
Fixed versionPatch bundles ESXi550-201403102-SG + ESXi550-201501101-SG. These are the last relevant patches — 5.5 is EOL.
Exposure dataShodan product:"VMware ESXi" version:5.5: residual internet-facing population in the low four-digits globally as of 2026, concentrated in edu/lab/legacy hosting.
DisclosureOriginal CVEs disclosed Oct 2014 – Jan 2015. VMware advisories VMSA-2014-0012 and VMSA-2015-0001.
Support statusESXi 5.5 General Support ended 2018-09-19; Technical Guidance ended 2020-09-19. No patches issued since.
04 · The Call

noisgate verdict.

Final Verdict
UPGRADED to HIGH (7.5/10)

The single decisive factor is role multiplier: the affected component is a Type-1 hypervisor, and every ESXi host by definition carries fleet-scale blast radius. The specific 2014 CVEs are pedestrian, but any host failing 81085 in 2026 is EOL and cannot be patched against six years of subsequent RCE and hypervisor-escape advisories.

HIGH vulnerability details and patch mapping
HIGH EOL status of ESXi 5.5
MEDIUM exploitability of the specific 2014 CVEs in modern client stacks

Why this verdict

  • Role multiplier — hypervisor: Any successful chain on ESXi ends in *every VM on that host* being compromised, and pivoting to vCenter turns it into a datacenter event. Per the noisgate hard rule, a canonical hypervisor deployment floors the verdict at HIGH minimum.
  • EOL amplifier: ESXi 5.5 lost Technical Guidance in Sep 2020. A host still failing this 2015 check has missed every VMSA since — including CVE-2021-21974 (ESXiArgs), CVE-2023-20867, CVE-2023-34048, and the 2025 hypervisor-escape wave. Plugin 81085 is a proxy for *systemic* unpatchability, not just POODLE.
  • Friction on the individual 2014 CVEs pulls DOWN: POODLE requires an active MitM plus an SSLv3-speaking client, which basically doesn't exist in 2026. libxml2 and vmware-authd bugs are DoS-only. If this were a supported version, MEDIUM would be defensible.
  • Net: floor of HIGH from hypervisor role + EOL exposure, not lifted to CRITICAL because the *named CVEs in the plugin* are not directly RCE and the exploit population that reaches the mgmt VLAN is bounded.

Why not higher?

The seven CVEs specifically flagged by plugin 81085 are POODLE-class MitM and DoS bugs — not remote unauthenticated RCE. CRITICAL requires a directly weaponizable chain on the flagged CVEs; the CRITICAL story here belongs to downstream VMSAs the host is separately vulnerable to, and those have their own plugins.

Why not lower?

MEDIUM assumes the host will be patched. It cannot be — 5.5 has been out of support since 2020. Any hypervisor that has drifted this far behind is a fleet-scale risk regardless of which single CVE lights up the scanner, and treating it as MEDIUM lets it sit in the 365-day backlog when it should be on a decommission plan measured in weeks.

05 · Compensating Control

What to do — in priority order.

  1. Decommission or migrate every ESXi 5.5 host within 30 days — There is no supported patch path. Migrate VMs to ESXi 7.0 U3 or 8.0 U3 (or a KVM/Proxmox target if licensing forces it). Per the noisgate HIGH mitigation SLA, this is the only real remediation.
  2. Isolate ESXi mgmt interfaces to a dedicated VLAN, ACL-restricted to jump hosts — Blocks the network reachability precondition for every step in the chain — POODLE, DoS, and the downstream VMSAs the host is now defenseless against. Deploy today; the noisgate mitigation SLA of 30 days for HIGH assumes this is the interim control.
  3. Disable SSLv3 on any remaining ESXi 5.5 hosts — Set UserVars.ESXiVPsDisabledProtocols to include sslv3 in /etc/vmware/rhttpproxy/config.xml and restart rhttpproxy. Kills the POODLE path specifically.
  4. Verify no internet exposure via external attack-surface tooling — Query Censys / Shodan / your ASM tool for vmware + 443 on your ASN ranges. Any 5.5 host reachable from the internet is a P0 — pull it offline within 24 hours.
  5. Snapshot and export every VM on the affected hosts — Assume compromise possibility during the migration window. Full offline backup before you kick off vMotion or a cold migration.
What doesn't work
  • Applying ESXi550-201501101-SG in 2026 — it only closes the 2014 CVEs and leaves you exposed to every VMSA from 2015 onward.
  • Web-server-only TLS hardening (nginx, F5) — doesn't touch hostd or vmware-authd on TCP/902.
  • EDR on the guest VMs — irrelevant; the hypervisor is below the guest kernel.
  • vCenter upgrades alone — vCenter 7/8 will manage 5.5 hosts to a limited extent, but the host itself remains unpatchable.
06 · Verification

Crowdsourced verification payload.

Run on an auditor workstation with SSH or esxcli reachability to the target ESXi host. Invoke as ./check_esxi_81085.sh <esxi-host>; needs an ESXi account with Host.Config.Settings or root SSH. Reports VULNERABLE if build < 2352327 OR the host is any 5.5 release (which is EOL).

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/usr/bin/env bash
# noisgate verification — tenable:81085
# Detects ESXi 5.5 hosts below build 2352327 AND flags any 5.5 host as EOL.
set -u
HOST="${1:-}"
if [[ -z "$HOST" ]]; then
  echo "Usage: $0 <esxi-host-or-ip>"; exit 2
fi

THRESHOLD=2352327

# Try SSH (esxcli) first; fall back to remote banner grab over HTTPS.
get_via_ssh() {
  ssh -o BatchMode=yes -o ConnectTimeout=5 root@"$HOST" \
    'vmware -v; echo ---; esxcli system version get' 2>/dev/null
}

get_via_https() {
  # ESXi exposes build info in the /sdk endpoint response headers and
  # the /client/clients.xml file on many builds.
  curl -sk --max-time 8 "https://$HOST/sdk" -X POST \
    -H 'Content-Type: text/xml' \
    --data '<?xml version="1.0"?><soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><RetrieveServiceContent xmlns="urn:vim25"><_this type="ServiceInstance">ServiceInstance</_this></RetrieveServiceContent></soap:Body></soap:Envelope>'
}

OUT="$(get_via_ssh)"
if [[ -z "$OUT" ]]; then
  OUT="$(get_via_https)"
fi

if [[ -z "$OUT" ]]; then
  echo "UNKNOWN: could not reach $HOST via SSH or HTTPS"; exit 3
fi

VERSION="$(echo "$OUT" | grep -oE 'VMware ESXi [0-9]+\.[0-9]+\.[0-9]+' | head -1)"
BUILD="$(echo "$OUT" | grep -oE 'build[- ]?[0-9]+' | grep -oE '[0-9]+' | head -1)"

if [[ -z "$VERSION" || -z "$BUILD" ]]; then
  echo "UNKNOWN: could not parse version/build from response"; exit 3
fi

echo "Detected: $VERSION build $BUILD"

# Anything 5.5 is EOL — always VULNERABLE per noisgate reassessment.
if echo "$VERSION" | grep -q 'ESXi 5\.5'; then
  if [[ "$BUILD" -lt "$THRESHOLD" ]]; then
    echo "VULNERABLE: ESXi 5.5 build $BUILD < $THRESHOLD (plugin 81085) AND version is EOL"
  else
    echo "VULNERABLE: ESXi 5.5 is EOL since 2020-09-19 — no patches available for downstream VMSAs"
  fi
  exit 1
fi

echo "PATCHED: host is not ESXi 5.5"
exit 0
07 · Bottom Line

If you remember one thing.

TL;DR
Do not treat this as MEDIUM patch hygiene — treat it as an end-of-life hypervisor discovery event. Monday: pull an inventory of every host flagged by plugin 81085, cross-reference against Shodan/Censys for any that are externally reachable, and yank those offline today. Per the noisgate mitigation SLA for HIGH, isolate management interfaces to a jump-host-only VLAN within 30 days and disable SSLv3 on any 5.5 host you cannot immediately kill. Per the noisgate remediation SLA for HIGH, every ESXi 5.5 host must be migrated to a supported version (7.0 U3 or 8.0 U3) or decommissioned within 180 days — but honestly, given the 2023 ESXiArgs and 2025 hypervisor-escape context, target 60 days if leadership will fund it. If KEV-adjacent exploitation of downstream ESXi RCEs is observed against your ASN, override to "mitigate immediately, within hours."

Sources

  1. Tenable plugin 81085
  2. VMSA-2014-0012 (POODLE/OpenSSL in ESXi)
  3. VMSA-2015-0001 (ESXi 5.5 patch)
  4. VMware ESXi lifecycle / EOL matrix
  5. CVE-2014-3566 (POODLE) - NVD
  6. CVE-2015-1044 - NVD
  7. CISA KEV — CVE-2021-21974 (ESXiArgs, unpatchable on 5.5)
  8. VMSA-2025-0010 (Broadcom)
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.