Buffer overflow for the Intel

CVE-2026-20794 is a classic buffer overflow in the Intel(R) Data Center Graphics Driver for VMware ESXi, affecting releases before 2.0.2. Intel says exploitation occurs within Ring 1 / device driver context and may allow local code execution / escalation of privilege. In practice, this only matters on ESXi hosts that both run the Intel async graphics driver and have the relevant Intel data center GPU stack deployed; Intel's 2.0.2 release notes show this package targets Intel Data Center GPU Flex Series and the current package line is for ESXi 8.0.3.

Intel scored it CRITICAL 9.3 on 2026-05-12, but that overstates enterprise patch urgency. The decisive friction is in Intel's own vector: AV:L/PR:H. An attacker needs local, privileged access on the ESXi host first; that is already a serious prior compromise, and the reachable population is narrow because this is a specialist GPU driver, not a broadly exposed ESXi management service.

Why this verdict

• Start from Intel's 9.3, then cut hard for attacker position: Intel's own vector is AV:L/PR:H, which means the attacker already has privileged local access on ESXi before this CVE matters.
• Niche deployment narrows the fleet: only hosts with the Intel async graphics driver and Data Center GPU Flex deployment are in scope; most enterprises will have few or none.
• Threat intel is cold: no KEV listing, no confirmed public exploitation, and an EPSS of 0.0002 all argue against urgent patch priority.

Why not higher?

This is not remotely reachable and it is not useful for initial access. Requiring privileged local access on the hypervisor is compounded friction: the attacker has already beaten your identity, management-plane, and host-access controls before touching this bug.

Why not lower?

It is still a real memory corruption flaw in hypervisor-adjacent driver code, not a theoretical paperwork CVE. On the small number of affected hosts, successful exploitation could deepen host control or persistence, so it deserves tracking and normal maintenance remediation rather than dismissal.

1. Disable routine ESXi shell and SSH access — Keep ESXi shell/SSH in break-glass mode only, because the exploit path starts with local privileged host access. For a LOW verdict there is no SLA deadline, but this should be enforced as standing control hygiene and verified during the next access review.
2. Constrain hypervisor admin paths — Limit who can administer ESXi directly through PAM, MFA-backed jump hosts, vCenter RBAC, and session recording. This cuts off the most important prerequisite; for LOW severity there is no mitigation SLA, so fold this into normal control assurance work rather than emergency change.
3. Inventory Intel-idcgpu across clusters — Use esxcli software vib list or host inventory tooling to identify where the Intel async VIB exists so you only patch the real blast radius. Do this in your next routine vulnerability triage cycle; many fleets will discover the affected population is tiny or zero.
4. Watch for host instability and package drift — Alert on unexpected PSODs, vmkernel.log driver faults, unauthorized VIB changes, and unexplained ESXi maintenance-mode/reboot patterns on GPU hosts. This is the practical detective control when classic EDR coverage is weak on ESXi.

Run this on the ESXi host itself from ESXi Shell or over SSH as root or an account that can execute esxcli. Example: sh check-idcgpu-cve-2026-20794.sh. It reads installed VIB inventory and reports VULNERABLE, PATCHED, or UNKNOWN based on whether Intel-idcgpu is present and whether its semantic version is earlier than 2.0.2.

#!/bin/sh
# check-idcgpu-cve-2026-20794.sh
# Purpose: detect whether Intel Data Center Graphics Driver for VMware ESXi
#          is present and older than 2.0.2.
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

TARGET_MAJOR=2
TARGET_MINOR=0
TARGET_PATCH=2

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

LINE=$(esxcli software vib list 2>/dev/null | awk 'tolower($1)=="intel-idcgpu" {print $0; exit}')

if [ -z "$LINE" ]; then
  echo "UNKNOWN: Intel-idcgpu VIB not installed or not visible in esxcli output"
  exit 2
fi

VER=$(echo "$LINE" | awk '{print $2}')
BASE=$(echo "$VER" | sed -n 's/^\([0-9][0-9]*\)\.\([0-9][0-9]*\)\.\([0-9][0-9]*\).*/\1 \2 \3/p')

if [ -z "$BASE" ]; then
  echo "UNKNOWN: unable to parse installed version from '$VER'"
  exit 2
fi

set -- $BASE
MAJOR=$1
MINOR=$2
PATCH=$3

if [ "$MAJOR" -lt "$TARGET_MAJOR" ]; then
  echo "VULNERABLE: Intel-idcgpu version $VER is earlier than 2.0.2"
  exit 1
fi

if [ "$MAJOR" -gt "$TARGET_MAJOR" ]; then
  echo "PATCHED: Intel-idcgpu version $VER is newer than 2.0.2"
  exit 0
fi

if [ "$MINOR" -lt "$TARGET_MINOR" ]; then
  echo "VULNERABLE: Intel-idcgpu version $VER is earlier than 2.0.2"
  exit 1
fi

if [ "$MINOR" -gt "$TARGET_MINOR" ]; then
  echo "PATCHED: Intel-idcgpu version $VER is newer than 2.0.2"
  exit 0
fi

if [ "$PATCH" -lt "$TARGET_PATCH" ]; then
  echo "VULNERABLE: Intel-idcgpu version $VER is earlier than 2.0.2"
  exit 1
fi

echo "PATCHED: Intel-idcgpu version $VER is 2.0.2 or later"
exit 0

Sources

1. Intel Advisory INTEL-SA-01402
2. Intel download page for Intel Data Center Graphics Driver for VMware ESXi
3. Intel 2.0.2 release notes PDF
4. Intel older release notes PDF
5. Intel Device Manager for VMware vCenter Server Plug-In article
6. NVD record for CVE-2026-20794
7. CISA Known Exploited Vulnerabilities Catalog
8. FIRST EPSS API documentation