A malicious tenant listens through the wall of a shared apartment via the CPU's cache
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.
4 steps from start to impact.
Land code execution inside a guest VM on the target ESXi host
- Attacker controls at least one guest VM on the target ESXi host
- That VM shares a physical CPU core with the target hypervisor thread or victim VM
- Single-tenant enterprise ESXi deployments have no external attacker running guest code by default
- Requires an initial-access chain into a VM as the actual entry point
Fingerprint the CPU and confirm L1TF-vulnerable microarchitecture
L1D_FLUSH MSR or without the RDCL_NO / hyperthreading mitigation bits set. Public tooling like spectre-meltdown-checker.sh or the original Foreshadow research code from KU Leuven / U-Michigan / U-Adelaide handles this in one shot.- Intel processor of the affected generation (pre-Cascade Lake / Whiskey Lake refresh)
- Microcode not updated, or SCA-scheduler not enabled on the host
- Modern refresh hardware (2019+) has silicon-level mitigations
- Any host patched to VMSA-2018-0020 with SCAv2 enabled defeats the sequential-context vector
Prime the L1D cache and trigger a terminal page fault
- Hyperthreading enabled on the host
- Victim workload (hypervisor page tables, other VM) is co-scheduled on the sibling logical CPU
- ESXi Side-Channel-Aware Scheduler v2 prevents cross-VM co-scheduling of siblings
- Disabling HT entirely eliminates concurrent-context leak
Reconstruct secrets from the leak channel
- Attacker persistence in the guest VM long enough to sample
- A victim actually processes secrets on the shared core during the sampling window
- Low bandwidth makes broad exfil impractical
- Confidentiality-only — no code execution, no persistence gained on the host
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.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.- Network segmentation of the ESXi management interface — L1TF is not network-reachable; management-plane firewalls do nothing against a guest-resident attacker.
- Guest-OS-level Meltdown/Spectre mitigations (KPTI, retpoline) — those protect the guest kernel from guest userspace, not the hypervisor from the guest.
- EDR inside the guest VM — µ-architectural side-channel reads generate no syscalls, no file I/O, no process events for EDR to alert on.
- vMotion evacuation policies — moving a VM does not remove its cache footprint from the source core in time to matter; only the scheduler mitigation prevents concurrent sampling.
The supporting signals.
| CVE | CVE-2018-3646 (L1TF-VMM / Foreshadow-NG) |
|---|---|
| In-the-wild exploitation | *None observed*. No incidents attributed to L1TF against ESXi in 8 years since disclosure. Not on CISA KEV. |
| Public PoC | Yes — gregvish/l1tf-poc demonstrates guest-to-host L1D read; academic artifacts from the Foreshadow team (KU Leuven, TU Graz, U-Michigan, U-Adelaide, Technion) |
| EPSS | ~0.04% (bottom quartile) — no observed exploitation attempts in telemetry |
| CISA KEV | Not listed |
| CVSS | 4.7 MEDIUM — CVSS:3.0/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N. Local vector, high complexity, confidentiality-only, but scope-changed because a guest reads across the hypervisor trust boundary. |
| Affected versions | ESXi 5.5 < build 9313334, 6.0 < build 9313335, 6.5 < build 9298722, 6.7 < build 9214924. Also Workstation < 14.1.3, Fusion < 10.1.3. |
| Fixed builds / SCA scheduler | VMSA-2018-0020 ships ESXi SCAv1 (opt-in via hyperthreadingMitigation=true); SCAv2 (later patch) restores much of the HT performance while retaining safety |
| Disclosure | 2018-08-14 — coordinated with Intel, Microsoft, VMware, Red Hat, and the Foreshadow academic team |
| Exposure population | ESXi 5.5–6.7 are all end-of-general-support (5.5 EoGS 2020-09, 6.0 EoGS 2022-03, 6.5/6.7 EoGS 2022-10). Hosts still on these builds are a maintenance-debt population, not a widely exposed one. Shodan shows ~40k ESXi UIs internet-exposed as of 2026 — most already 7.0.x/8.0.x. |
Sources.
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.
Crowdsourced verification payload.
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