ESXi 5

Tenable plugin 105486 rolls up VMSA-2017-0021 and VMSA-2018-0002 against ESXi 5.5, 6.0, and 6.5. The bundle covers four CVEs: CVE-2017-4940 (stored XSS in the ESXi Host Client), CVE-2017-4941 (stack overflow via an authenticated VNC session that yields code execution *inside* the guest VM — not a host escape), and CVE-2017-5715 / CVE-2017-5753 (Spectre v2 and v1 microcode/hypervisor mitigations). Fixes shipped in ESXi 6.5 Patch 02 (build 7526125), 6.0 U3e (build 7504637), and 5.5 U3g (build 7504623).

Vendor severity of MEDIUM is roughly fair *for the individual bugs* — none of these is a clean unauthenticated guest-to-host escape, and the Spectre pair is a side-channel mitigation, not an RCE. But the vendor label misses the real question: the affected products are all end-of-general-support. ESXi 5.5 EOL'd in September 2018, 6.0 in March 2020, 6.5 in October 2022. If plugin 105486 is firing in 2026, the finding you're chasing is not CVE-2017-4941 — it's *why do we still have ESXi 6.5 hosts in production*. That reframes it as HIGH.

Why this verdict

• Role multiplier — hypervisor: ESXi is a canonical high-value-role component; a chain that ends in host compromise ends in *fleet* compromise (every guest, every snapshot, every datastore). The floor for a hypervisor finding is HIGH.
• Vendor MEDIUM understates the deployment reality: the plugin's affected-version set is entirely EOL. Any host firing this in 2026 is also carrying CVE-2020-3992, CVE-2021-21974, CVE-2024-37085 — bugs that *are* KEV-listed and actively used by ransomware crews.
• Individual CVE friction is real: CVE-2017-4941 needs authenticated VNC and only yields *in-guest* code exec; XSS needs a second admin to click; Spectre needs co-tenancy and is impractical. That's what keeps this from being CRITICAL on the bundle alone.
• Not on KEV, EPSS is low: so this is not an emergency *because of these specific CVEs*. It is an emergency *because the box is unsupported*.

Why not higher?

None of the four CVEs is a clean unauthenticated guest-to-host escape, none are KEV-listed, and none have wormable public exploits. CRITICAL is reserved for hypervisor bugs where the chain provably lands host-code-exec from an unprivileged guest (e.g., CVE-2024-22252/22253).

Why not lower?

MEDIUM would be defensible if this plugin were firing against a *supported* build with the fix simply skipped. It is not — it fires only on EOL versions, and an EOL hypervisor is a fleet-scale liability regardless of the specific CVE list on the report.

1. Isolate ESXi management network — Restrict TCP/443, /902, /5988-5989 on ESXi mgmt vmk interfaces to a dedicated jump-host subnet, enforce MFA on that jump host. Complete within 30 days per the noisgate HIGH mitigation SLA.
2. Disable VNC on all VMs — Remove RemoteDisplay.vnc.enabled = TRUE and RemoteDisplay.vnc.port from every .vmx. This kills the CVE-2017-4941 vector entirely and is a hardening baseline anyway. Push via PowerCLI within 30 days.
3. Enable ESXi Lockdown Mode (Strict) — Cuts off direct DCUI/SSH/Host Client access, forces all admin through vCenter with audit trail. Deploy across the fleet within the 30-day mitigation window.
4. Plan migration off ESXi 5.5/6.0/6.5 — The only durable fix is upgrading to a supported line (7.0 U3 or 8.0 U2+). Land the migration plan inside the noisgate HIGH remediation SLA of ≤ 180 days.
5. Snapshot + immutable backup of guest data — In case the host is already compromised by a later CVE, an offline immutable backup means ESXiArgs-style encryption is recoverable. Verify restore tests during the migration window.

Run on an auditor workstation with PowerCLI 12+ installed and a vCenter read-only account. Invoke as: .\Check-VMSA-2017-0021.ps1 -vCenter vcsa.corp.local. Reports each ESXi host as VULNERABLE / PATCHED / UNKNOWN based on build number against the VMSA-2017-0021 / VMSA-2018-0002 fixed builds.

#requires -Modules VMware.PowerCLI
# Check-VMSA-2017-0021.ps1
# Reports ESXi hosts vulnerable to VMSA-2017-0021 / VMSA-2018-0002 bundle (Tenable 105486)
param(
    [Parameter(Mandatory=$true)][string]$vCenter
)

# Fixed builds per VMware KB (see VMSA-2017-0021 / VMSA-2018-0002)
$fixedBuilds = @{
    '5.5.0' = 7504623
    '6.0.0' = 7504637
    '6.5.0' = 7526125
}

try {
    Set-PowerCLIConfiguration -InvalidCertificateAction Ignore -Confirm:$false | Out-Null
    Connect-VIServer -Server $vCenter -ErrorAction Stop | Out-Null
} catch {
    Write-Host "UNKNOWN: cannot connect to $vCenter - $_"
    exit 2
}

$anyVuln = $false
foreach ($h in Get-VMHost) {
    $ver = $h.Version
    $build = [int]$h.Build
    if ($fixedBuilds.ContainsKey($ver)) {
        if ($build -lt $fixedBuilds[$ver]) {
            Write-Host ("VULNERABLE: {0} ESXi {1} build {2} (< fixed build {3}) - also EOL" -f $h.Name,$ver,$build,$fixedBuilds[$ver])
            $anyVuln = $true
        } else {
            Write-Host ("PATCHED (still EOL train): {0} ESXi {1} build {2}" -f $h.Name,$ver,$build)
        }
    } elseif ($ver -match '^(7|8)\.') {
        Write-Host ("PATCHED (supported line): {0} ESXi {1} build {2}" -f $h.Name,$ver,$build)
    } else {
        Write-Host ("UNKNOWN: {0} ESXi {1} build {2}" -f $h.Name,$ver,$build)
    }
}

Disconnect-VIServer -Confirm:$false -Force | Out-Null
if ($anyVuln) { exit 1 } else { exit 0 }

Sources

1. Tenable plugin 105486
2. VMSA-2017-0021 advisory
3. VMSA-2018-0002 (Spectre) advisory
4. NVD CVE-2017-4941
5. NVD CVE-2017-4940
6. xairy/vmware-exploitation reference collection
7. VMware Product Lifecycle Matrix
8. CISA Known Exploited Vulnerabilities Catalog