ESXi 5

CVE-2015-6933 is a kernel memory corruption bug in the VMware Tools HGFS (Host-Guest File System) Shared Folders driver on Windows guests. A local, low-privileged user *inside the Windows VM* can corrupt guest kernel memory via crafted HGFS traffic and escalate to SYSTEM within that same guest. The affected fleet is ESXi 5.5 hosts prior to build 3248547 (patch ESXi550-201512102-SG, Dec 2015), plus companion updates to Workstation 11.x <11.1.2, Player 7.x <7.1.2, Fusion 7.x <7.1.2, and ESXi 5.0/5.1/6.0 lines with their own builds.

Tenable/VMware rated this MEDIUM (CVSS 6.3, AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L) and that label overstates the practical risk. The scope is explicitly unchanged — VMware itself notes host memory cannot be manipulated from the guest, so this is *not* a VM escape. It is a guest-local privilege escalation that only fires when Shared Folders is enabled (rare on server workloads, disabled by default on ESXi-hosted Windows guests) and requires an attacker already executing code inside the VM.

Why this verdict

• Scope Unchanged (S:U): VMware explicitly states host memory cannot be manipulated from the guest — this is guest-internal EoP, not a hypervisor breakout. That collapses the multiplier that would justify MEDIUM+ on a hypervisor CVE.
• Prerequisite stack is deep: attacker needs (a) code execution inside a Windows guest, (b) Shared Folders enabled on that guest, and (c) a working exploit for a bug with no public weaponized PoC. Each condition compounds downward.
• Role multiplier — hypervisor host: the chain does NOT succeed as a hypervisor compromise; the bug lives in the guest driver, not the VMkernel. The blast radius on ESXi is *one guest VM*, not the fleet. This is the opposite of the ESXi CVEs that earn a CRITICAL floor.
• Role multiplier — Windows guest: even in the worst case the attacker gets SYSTEM on one VM they already control. Any modern Windows LPE (PrintNightmare, CLFS, etc.) delivers the same outcome with orders of magnitude less effort.
• No exploitation signal: not in KEV, EPSS trivial, no Metasploit module, 10+ years without a public campaign leveraging this vector.
• Feature disabled by default on ESXi: the exposed installed-base share where HGFS is actively used on a server workload is a small fraction of an already-shrinking ESXi 5.5 population.

Why not higher?

MEDIUM would imply the bug meaningfully changes an attacker's position on a typical ESXi 5.5 estate. It doesn't — the attacker must already be inside a guest, the exploited feature is off by default on servers, and success yields SYSTEM on that same guest only. There is no hypervisor impact, no lateral primitive across VMs, and no evidence of in-the-wild use in a decade.

Why not lower?

IGNORE would be wrong because ESXi 5.5 is out of support and any residual host running vulnerable Tools represents a genuine (if narrow) EoP path. LOW captures the reality: log it, fold it into the ESXi 5.5 decommission project, but do not burn a change window on it in isolation.

1. Decommission ESXi 5.5 outright — ESXi 5.5 exited Technical Guidance on 2020-09-19. Any host still running it is carrying a long tail of unpatched vulns far scarier than this one. Fold this CVE into the migration to ESXi 7.0U3 or 8.x and close the whole class of issues at once — target completion within the noisgate remediation SLA for LOW (365-day backlog window).
2. Disable Shared Folders on all Windows guests — In the VM .vmx, set isolation.tools.hgfs.disable = "TRUE" and restart the guest. This kills the HGFS RPC channel entirely and neuters the vulnerable code path without touching the host. Push via PowerCLI across the cluster in one change window.
3. Remove the Shared Folders component from VMware Tools — Reinstall VMware Tools in each Windows guest with a Custom install and deselect the *Shared Folders* feature so vmhgfs.sys is never loaded. This is the belt-and-suspenders complement to the VMX flag.
4. Enforce least privilege inside guest VMs — Because this bug requires a local user in the guest, removing interactive logon for service accounts, enforcing LAPS on guest local admins, and restricting RDP reduces the population of accounts that could ever reach step 1.

Run from a workstation with PowerCLI installed and a vCenter/ESXi credential that can enumerate hosts and VMs. Invoke as .\Check-CVE-2015-6933.ps1 -VIServer vcenter.corp.local. Requires read access to host build numbers and VM advanced settings; no changes are made.

#!powershell
# Check-CVE-2015-6933.ps1
# Detects ESXi 5.5 hosts below build 3248547 AND Windows guests with HGFS Shared Folders enabled.
# Exit codes: 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN

param(
    [Parameter(Mandatory=$true)][string]$VIServer
)

$ErrorActionPreference = 'Stop'
$fixedBuild = 3248547
$vulnerable = $false
$unknown    = $false

try {
    if (-not (Get-Module -ListAvailable VMware.PowerCLI)) {
        Write-Error 'VMware.PowerCLI module not installed.'
        exit 2
    }
    Import-Module VMware.PowerCLI -ErrorAction Stop | Out-Null
    Set-PowerCLIConfiguration -InvalidCertificateAction Ignore -Confirm:$false | Out-Null
    Connect-VIServer -Server $VIServer -ErrorAction Stop | Out-Null
} catch {
    Write-Host "UNKNOWN: could not connect to $VIServer -> $_"
    exit 2
}

$hosts = Get-VMHost | Where-Object { $_.Version -like '5.5.*' }
foreach ($h in $hosts) {
    $build = [int]($h.Build)
    if ($build -lt $fixedBuild) {
        Write-Host "VULNERABLE HOST: $($h.Name) build $build < $fixedBuild"
        $vulnerable = $true

        $vms = Get-VM -Location $h | Where-Object { $_.Guest.OSFullName -match 'Windows' }
        foreach ($vm in $vms) {
            $hgfs = Get-AdvancedSetting -Entity $vm -Name 'isolation.tools.hgfs.disable' -ErrorAction SilentlyContinue
            if (-not $hgfs -or $hgfs.Value -ne 'TRUE') {
                Write-Host "  -> Guest $($vm.Name) has HGFS NOT explicitly disabled"
            }
        }
    } else {
        Write-Host "PATCHED HOST: $($h.Name) build $build"
    }
}

Disconnect-VIServer -Confirm:$false | Out-Null

if ($vulnerable) { exit 1 }
elseif ($unknown) { exit 2 }
else { Write-Host 'PATCHED'; exit 0 }

Sources

1. Tenable plugin 87942
2. NVD CVE-2015-6933
3. VMware VMSA-2016-0001 (Broadcom)
4. MITRE CVE-2015-6933
5. Tenable VMSA-2016-0001 summary plugin
6. CISA KEV catalog
7. FIRST EPSS
8. VMware ESXi 5.5 lifecycle (Broadcom)