ESXi 5

CVE-2018-3646 (L1 Terminal Fault / Foreshadow-NG, VMM variant) lets code inside a guest VM speculatively read data resident in the physical CPU core's L1 data cache — which on a hyperthreaded core includes memory belonging to the hypervisor scheduler and to sibling VMs sharing that core. Tenable plugin 111759 flags ESXi 5.5, 6.0, 6.5, and 6.7 hosts that are missing the VMSA-2018-0020 hypervisor updates that ship the ESXi Side-Channel-Aware Scheduler (SCAv1/SCAv2) and consume the Intel microcode fixes. Affected builds are anything prior to the August 2018 ESXi patches: 5.5 build 9313334, 6.0 build 9313335, 6.5 build 9298722, 6.7 build 9214924 and later.

The vendor MEDIUM (CVSS 4.7, AV:L/AC:M/PR:L/UI:N/S:C/C:H/I:N/A:N) is *fair, arguably even a hair generous*. Confidentiality-only, attacker must already be executing arbitrary code inside a guest VM on the same physical core as the target, exploitation is slow (kilobytes/second of leaked cache), and mitigations exist even without patching (disable hyperthreading, or ensure single-tenant pCPU pinning). The only reason to lift this above MEDIUM is a multi-tenant scenario where you are actually renting VMs to untrusted third parties — most enterprise ESXi fleets are not that.

Why this verdict

• Prerequisite is guest-code execution, not network reachability — L1TF-VMM has AV:L. There is no pre-auth, network-facing attack surface here; the attacker has to already be inside a VM on the target host. That single friction point collapses the exposed population by two orders of magnitude versus a remote-unauth ESXi bug.
• Confidentiality-only, low bandwidth — leak is measured in KB/s, no integrity or availability impact, no code execution. Even a successful chain does not give the attacker fleet control — it gives them a slow drip of cache-resident data that may or may not include a useful secret.
• Free mitigation exists without patching — disabling hyperthreading or enabling hyperthreadingMitigation=true (SCAv1/v2) neutralizes the concurrent-context vector on every affected build. Defenders who cannot patch have an operational lever that costs performance, not security.
• Role multiplier — multi-tenant IaaS host: chain succeeds; blast radius is tenant-to-tenant confidentiality breach on the same physical core. Serious for a hosting provider, but this is <5% of enterprise ESXi installed base. Verdict floor for this role: HIGH.
• Role multiplier — single-tenant enterprise ESXi: chain requires the attacker to have *already compromised* one of your own VMs, at which point L1TF is the least of your problems. Blast radius: incremental read of neighbor VMs on same core. This is the ≥90% deployment role, and the outcome is not fleet-scale. Verdict floor: MEDIUM.
• No KEV, no known campaigns, EPSS in the bottom quartile eight years post-disclosure. Ransomware crews, state actors, and IABs have universally ignored L1TF in favor of easier ESXi bugs (CVE-2021-21974, CVE-2024-37085). Treat empirical exploitation data as decisive.

Why not higher?

Upgrading to HIGH would require the affected component to canonically occupy a high-value role where the chain ends in fleet or cross-tenant compromise. ESXi *is* a hypervisor (which normally floors at CRITICAL), but the L1TF-VMM chain specifically requires the attacker to already control a co-resident guest — it is not an unauth path to hypervisor code execution like CVE-2024-37085 or ESXiArgs-class bugs. In the dominant single-tenant deployment, the prerequisite is itself a full compromise event.

Why not lower?

Downgrading to LOW ignores the genuine multi-tenant scenario (IaaS, service providers, VDI farms with mixed trust) where the chain does succeed and does cross a real trust boundary. It also ignores that unpatched ESXi 5.5–6.7 hosts in 2026 typically carry many other unpatched CVEs; leaving L1TF unaddressed signals broader maintenance debt worth flagging at MEDIUM.

1. Enable the ESXi Side-Channel-Aware Scheduler — Set VMkernel.Boot.hyperthreadingMitigation = TRUE on each affected host (SCAv1) or upgrade to a build supporting SCAv2 which restores most HT performance. This neutralizes the concurrent-context vector without a hardware change. No noisgate mitigation SLA at MEDIUM, but treat as the *default* control you enable when you touch the host for any reason.
2. Disable Intel Hyperthreading on hosts running mixed-trust workloads — In the BIOS/UEFI, disable HT on ESXi hosts that mix tenants of different trust levels (dev + prod, tenant A + tenant B). Cuts vCPU capacity ~30% but eliminates the concurrent-context L1TF leak entirely. Apply before onboarding any new untrusted tenant workload.
3. Pin sensitive workloads to dedicated hosts or dedicated pCPUs — Use DRS host groups and CPU affinity to keep secrets-processing VMs (secrets managers, KDCs, PKI CAs) on hosts that never co-host untrusted workloads. Eliminates the sibling-thread precondition regardless of microcode status.
4. Verify Intel microcode currency alongside ESXi build — The ESXi patch is necessary but not sufficient — Intel L1D_FLUSH microcode must also be present. Check with esxcli hardware cpu global get and confirm microcode revision matches Intel's L1TF-safe revision for the CPU model. Roll microcode via ESXi patch bundles.
5. Upgrade off ESXi 5.5/6.0/6.5/6.7 entirely — All four are past End of General Support (5.5: 2020, 6.0: 2022, 6.5/6.7: 2022). Even resolving L1TF, these hosts accrue unpatched CVEs monthly. Fold into your existing hypervisor refresh program to ESXi 8.0.x on the noisgate remediation SLA (≤ 365 days for MEDIUM).

Run this on the target ESXi host over SSH as root, e.g. ssh [email protected] ./check-l1tf.sh. It confirms the ESXi build is at or above the VMSA-2018-0020 fixed build and reports whether the Side-Channel-Aware Scheduler is enabled. Outputs VULNERABLE, PATCHED, or UNKNOWN.

#!/bin/sh
# check-l1tf.sh — VMSA-2018-0020 / CVE-2018-3646 posture check for ESXi
# Run on the ESXi host as root. Requires esxcli.

set -u

if ! command -v esxcli >/dev/null 2>&1; then
  echo "UNKNOWN: esxcli not found — not an ESXi host?"
  exit 2
fi

VER=$(esxcli system version get | awk -F': ' '/^   Version:/ {print $2}')
BUILD=$(esxcli system version get | awk -F': ' '/^   Build:/ {print $2}' | tr -d 'Releasebuild-')

# VMSA-2018-0020 fixed builds
case "$VER" in
  5.5.0) FIX=9313334 ;;
  6.0.0) FIX=9313335 ;;
  6.5.0) FIX=9298722 ;;
  6.7.0) FIX=9214924 ;;
  7.*|8.*) echo "PATCHED: ESXi $VER build $BUILD is post-L1TF baseline"; exit 0 ;;
  *) echo "UNKNOWN: unrecognized ESXi version $VER"; exit 2 ;;
esac

SCA=$(esxcli system settings kernel list -o hyperthreadingMitigation 2>/dev/null \
       | awk '/hyperthreadingMitigation/ {print $3}')

if [ "${BUILD:-0}" -lt "$FIX" ]; then
  echo "VULNERABLE: ESXi $VER build $BUILD < required $FIX (VMSA-2018-0020)"
  exit 1
fi

if [ "$SCA" != "TRUE" ]; then
  echo "VULNERABLE: patched build present but SCA scheduler (hyperthreadingMitigation) is not enabled — concurrent-context L1TF vector still open"
  exit 1
fi

echo "PATCHED: ESXi $VER build $BUILD >= $FIX and SCA scheduler enabled"
exit 0

Sources

1. Tenable plugin 111759
2. VMSA-2018-0020 (Broadcom)
3. VMware L1TF-VMM response (KB 317621)
4. Side-Channel-Aware Scheduler mitigation guide (KB 330041)
5. Tenable CVE-2018-3646 record
6. gregvish/l1tf-poc — guest-to-host L1D read PoC
7. Rapid7 VMSA-2018-0020 / CVE-2018-3646
8. vInfrastructure Blog — L1TF vSphere patches