tenable:92949 · ESXi 5.0 / 5.1 / 5.5 / 6.0 Multiple Vulnerabilities (VMSA-2016-0010)…

01 · The Real Story

A dusty 2016 advisory that matters less for its CVEs than for what it says about the host still running them

VMSA-2016-0010 bundles two flaws: CVE-2016-5330 is a DLL side-loading bug in the VMware Tools HGFS (Shared Folders) component on Windows guests — an attacker who can drop a DLL on the guest's search path or trick a user into opening a file from a network share gets code execution as the current user. CVE-2016-5331 is a CRLF / HTTP header injection flaw in the vCenter/ESXi web layer that allows HTTP response splitting. Affected: ESXi 5.0, 5.1, 5.5, 6.0, plus the corresponding vCenter and VMware Tools packages. Fixes were shipped via KB2141429 / 2142193 / 2143976 / 2144359 in mid-2016.

Tenable's MEDIUM (CVSSv2 4.4) rating matches reality for the CVEs themselves: neither flaw is a hypervisor escape, neither yields SYSTEM on the host, and CVE-2016-5330 requires the non-default HGFS component plus user interaction. The CVSSv3 7.8 rescore is aspirational. The *real* story is not the bugs — it is that if Nessus still fires plugin 92949 in 2026, you are running a hypervisor that has been end-of-general-support since 2020 (6.0) or earlier, missing five years of critical VMSA advisories including OpenSLP RCEs and ESXiArgs ransomware exposure. Patch this and you close a 2016 finding; the underlying platform is still a strategic liability.

"Ten-year-old advisory on EOL hypervisors — the CVEs are noise, but the finding itself is a smoke alarm for unsupported ESXi."

02 · The Attack Path

4 steps from start to impact.

STEP 01

Attacker gains foothold on a Windows guest VM

CVE-2016-5330 lives in the guest, not the hypervisor. The attacker needs code execution or file-drop primitive on a Windows VM running VMware Tools with the optional HGFS/Shared Folders feature installed. Typical initial-access vectors: phishing, credential reuse, or an already-compromised user session.

Conditions required:

Windows guest VM
VMware Tools installed with HGFS component (non-default in typical install)
Attacker can write to a directory in DLL search path OR user opens attacker-controlled network share

Where this breaks in practice:

HGFS is *not* installed by 'Typical' VMware Tools setup — most fleets don't have it
Requires user interaction or prior foothold to plant the DLL
Modern EDR flags unsigned DLL loads from user-writable paths

Detection/coverage: Nessus plugin 92949 detects the missing patch on the ESXi host; Windows-side detection depends on EDR DLL-load telemetry. Metasploit module exists (vmware_hgfs_dll_hijack).

STEP 02

Trigger HGFS DLL side-load

The VMware Tools HGFS helper loads a DLL from an insecure path (CWD-style search order). The attacker's DLL executes in the context of the invoking user — usually the interactive logged-in user, not SYSTEM.

Conditions required:

HGFS process invoked while attacker DLL is in search path

Where this breaks in practice:

Payload runs at user privilege, not SYSTEM — no automatic elevation
Windows 10+ SafeDllSearchMode and AppLocker/WDAC block most naive side-loads
Signed-binary EDR policies (Defender ASR, CrowdStrike, SentinelOne) block unsigned DLL execution

Detection/coverage: Sysmon Event 7 (ImageLoad) with mismatched signer; EDR DLL-search-order-hijack rulesets.

STEP 03

(Parallel) CRLF injection against vCenter/ESXi web endpoint

CVE-2016-5331 lets an unauthenticated attacker inject \r\n into HTTP responses via a crafted request to the vCenter/ESXi web layer. The realistic impact is cache poisoning, session fixation, or phishing lure — not RCE.

Conditions required:

Reachable vCenter/ESXi HTTPS endpoint
Ability to convince a browser or downstream proxy to consume the split response

Where this breaks in practice:

vCenter/ESXi management interfaces should never be internet-exposed; Shodan/Censys population of exposed 5.x/6.0 hosts is small and shrinking
Modern browsers and CDNs enforce strict header parsing that neutralises most response-splitting outcomes
No path from CRLF to hypervisor code execution

Detection/coverage: WAF signatures for CRLF payloads; NGFW deep inspection.

STEP 04

Escalate — but not via these CVEs

Neither flaw yields VM escape, DA, or hypervisor takeover on its own. An attacker on an EOL ESXi 5.x/6.0 fleet in 2026 will pivot instead to *other* unpatched issues on the same host (SLP, DCERPC, VMCI, or the ESXiArgs class) that this advisory does not cover. That is the real risk this finding surfaces.

Conditions required:

Presence of any of the ~40 subsequent VMSA advisories that have accumulated since 2020

Where this breaks in practice:

None if the host is truly still on 5.x/6.0 — that is the point

Detection/coverage: Full ESXi CVE audit; do not rely on plugin 92949 alone.

03 · Compensating Control

Inventory every ESXi 5.x/6.0 host this week and flag them for platform replacement, not just patching — The 2016 patch closes this VMSA but leaves you on an EOL hypervisor. Build an upgrade plan to 7.0 U3 or 8.0 — this is the real remediation. Since verdict is MEDIUM there is no noisgate mitigation SLA, but the EOL condition itself warrants prioritisation independent of this CVE.

Uninstall or disable the HGFS Shared Folders component in VMware Tools on all Windows guests — This is the attack surface for CVE-2016-5330. Redeploy VMware Tools with Typical (which omits HGFS) or run VMwareToolboxCmd.exe to disable shared folders. Fleet-wide via GPO or config management within the 365-day remediation window.

Segment the vSphere management network off the corporate LAN — Neutralises CVE-2016-5331 (unreachable endpoint = unreachable CRLF) and blunts the far more dangerous EOL-era ESXi bugs. Jump-host access only, MFA at the bastion. Standard hardening — do it inside the 365-day window.

Update VMware Tools to 10.0.6+ across all guests as a matter of course — Fixes CVE-2016-5330 at the source. VMware Tools updates are trivial compared to hypervisor patching and can be rolled fleet-wide via config management.

What doesn't work

Host-based firewalls on the ESXi hypervisor — irrelevant to CVE-2016-5330, which is guest-side.
Patching only the ESXi host — CVE-2016-5330 also requires the VMware Tools update on every Windows guest; the host patch alone leaves guests vulnerable.
WAF in front of vCenter — helps against CVE-2016-5331 but does nothing for the guest-side DLL side-load, and most orgs don't front management planes with a WAF anyway.
EDR alone — will *sometimes* catch the DLL side-load but the friction is inconsistent across vendors and doesn't touch the CRLF endpoint.

04 · Intelligence Metadata

The supporting signals.

CVEs	CVE-2016-5330 (HGFS DLL side-load, guest-side) + CVE-2016-5331 (CRLF / HTTP response splitting, vCenter/ESXi)
In-the-wild status	Not on CISA KEV. No credible reports of targeted campaigns leveraging these specific CVEs; the class is folded into generic post-exploitation tradecraft.
Proof-of-concept	Public Metasploit module for the HGFS DLL hijack pattern; CRLF PoCs are trivial one-liners with `curl`.
EPSS	Both CVEs sit around 0.1–0.3 percentile (very low forecast exploitation probability as of 2026).
CVSS	CVSSv2 4.4 MEDIUM (AV:L/AC:M/Au:N/C:P/I:P/A:P); Tenable's CVSSv3 7.8 rescore assumes user-context RCE. Real-world impact matches v2.
Affected	ESXi 5.0, 5.1, 5.5, 6.0; vCenter Server 6.0 before U2; VMware Tools <10.0.6 on Windows guests with HGFS
Fixed	ESXi650-201703001 baseline covers 6.0 U2+; VMware Tools 10.0.6+. All affected ESXi trains are end-of-support — no path forward except upgrading to 7.0 U3 or 8.0.
Exposure	Shodan/Censys show a very small and declining external population of ESXi 5.x/6.0 management interfaces — most residual instances are inside enterprise networks, not internet-facing.
Disclosed	2016-08-04 by VMware in VMSA-2016-0010
Reporter	CVE-2016-5330 credited to Yorick Koster (Securify); CVE-2016-5331 credited via VMware coordinated disclosure

Sources.

05 · The Call

Final Verdict

= UNCHANGED to MEDIUM (5.0/10)

Why this verdict

Chain terminates below the hypervisor. CVE-2016-5330 executes in the *guest* user context; CVE-2016-5331 is response splitting. Neither reaches the ESXi kernel or vmkernel, so the hypervisor role multiplier does not apply.
Prerequisite friction is heavy. HGFS Shared Folders is not installed by the default VMware Tools setup, and the CRLF flaw requires reachable management-plane HTTPS — an interface no mature program exposes externally.
No KEV, no campaigns, EPSS near zero. Ten years post-disclosure with no adversary interest is signal, not noise.
Role multiplier — hypervisor: The affected component runs on ESXi (canonical high-value role, ≥90% of installs), but the documented chain does *not* succeed at fleet scale here — outcome is user-context RCE in a guest, not domain/fleet compromise. Floor does not lift above MEDIUM for these specific CVEs.
The finding is a proxy metric. Any host still returning this plugin in 2026 is running an EOL hypervisor missing five years of criticals (OpenSLP, ESXiArgs class). Treat the *finding* seriously even though the *CVEs* are not.

Why not higher?

To justify HIGH, the chain would need to end in VM escape, DA-tier credential theft, or fleet compromise. It does not — it ends in user-context code execution in a guest OS with a non-default component. HIGH would also require credible active exploitation, which is absent (no KEV, near-zero EPSS).

Why not lower?

LOW/IGNORE would be wrong because Metasploit tooling exists, the affected fleet is by definition EOL and unlikely to receive discipline elsewhere, and the compensating controls (HGFS removal, management-plane segmentation) are non-trivial in legacy vSphere environments.

06 · Verification

Crowdsourced verification payload.

Run on an auditor workstation with PowerCLI installed and a vCenter/ESXi read-only credential. Invoke as .\Check-VMSA-2016-0010.ps1 -Server vcenter.corp.local. Requires network reach to the management endpoint and vSphere.View privilege. Outputs VULNERABLE, PATCHED, or UNKNOWN per host.

noisgate-verify.ps1

POWERSHELLREAD-ONLYSAFE

#Requires -Modules VMware.PowerCLI
# Check-VMSA-2016-0010.ps1 — audit ESXi hosts for VMSA-2016-0010 patch level
param(
    [Parameter(Mandatory=$true)][string]$Server,
    [PSCredential]$Credential = (Get-Credential -Message 'vCenter/ESXi read-only creds')
)

$ErrorActionPreference = 'Stop'
Set-PowerCLIConfiguration -InvalidCertificateAction Ignore -Confirm:$false | Out-Null

try {
    Connect-VIServer -Server $Server -Credential $Credential | Out-Null
} catch {
    Write-Output 'UNKNOWN: connection failed'
    exit 2
}

# Minimum patched builds addressing VMSA-2016-0010
$minBuild = @{
    '5.0' = 3982828   # ESXi500-201606001
    '5.1' = 3872664   # ESXi510-201605001
    '5.5' = 3872664   # ESXi550-201607001
    '6.0' = 3825889   # ESXi600-201608001
}

$exitCode = 0
Get-VMHost | ForEach-Object {
    $ver   = ($_.Version)
    $build = [int]$_.Build
    $line  = "$($_.Name)  Version=$ver  Build=$build  "

    if ($ver -match '^7\.|^8\.') {
        Write-Output "$line=> PATCHED (post-EOL train, VMSA-2016-0010 superseded)"
    } elseif ($minBuild.ContainsKey($ver)) {
        if ($build -ge $minBuild[$ver]) {
            Write-Output "$line=> PATCHED"
        } else {
            Write-Output "$line=> VULNERABLE (needs build >= $($minBuild[$ver])) — AND host is EOL, plan platform upgrade"
            $exitCode = 1
        }
    } else {
        Write-Output "$line=> UNKNOWN version"
        if ($exitCode -eq 0) { $exitCode = 3 }
    }
}

Disconnect-VIServer -Server $Server -Confirm:$false | Out-Null
exit $exitCode