VMware ESX

CVE-2026-41703 is an out-of-bounds read in the VMware hypervisor host process affecting ESXi (all current branches: 8.0, 9.0, 9.1), Workstation 25H2, and Fusion 25H2. An attacker who already holds VM deployment privileges — typically a vSphere admin or delegated VM creator — can craft a malicious VM configuration that triggers an OOB read in the host-side process. On ESXi the result is information disclosure from host memory plus a potential denial-of-service crash of the host process. On Workstation and Fusion, Broadcom explicitly rates this at CVSS 2.7 (LOW) because the impact is limited to info disclosure only. Critically, Broadcom confirms this is not a VM escape and does not yield code execution on the host.

The vendor's HIGH / 7.6 rating on ESXi is technically defensible because of the S:C (Scope: Changed) flag — the vulnerable component is the guest VM context but the impacted component is the host process. However, that score overstates real-world risk for two reasons. First, the prerequisite is PR:H, meaning the attacker must already possess elevated vSphere privileges; an external attacker or a compromised guest OS alone cannot reach this code path. Second, the ceiling of impact is a read primitive plus a process crash — no persistence, no lateral movement, no host takeover. In the same advisory (VMSA-2026-0006), three CRITICAL flaws (CVE-2026-59309, CVE-2026-59310, CVE-2026-47876) deliver authentication bypass, directory traversal, and actual VM escape respectively, dwarfing this bug's operational significance.

Why this verdict

• PR:H gate: The attacker must already hold vSphere VM-deployment privileges — typically fewer than 10 accounts per cluster in hardened environments. This is not reachable from a compromised guest OS or an unauthenticated network position, eliminating the vast majority of threat actors.
• Impact ceiling is read-only + DoS: Broadcom explicitly states this is not a VM escape and does not yield code execution. The worst-case outcome is leaking fragments of host process memory and crashing the host process, which HA restarts in seconds. This cannot produce domain takeover, fleet compromise, or lateral movement.
• Role multiplier: ESXi (hypervisor — canonical high-value role). The chain *does* succeed in this role, but the blast radius tops out at *host-level DoS + info leak*, not host takeover or fleet compromise. A crashed hostd process triggers HA failover, not data destruction. Because the outcome does not meet the threshold of 'domain takeover / fleet compromise / mass data egress / supply-chain pivot,' the HIGH floor does not engage.
• No exploitation pressure: Zero in-the-wild exploitation, no public PoC, no KEV listing. The companion CVEs in VMSA-2026-0006 (auth bypass, VM escape) will consume all attacker R&D attention before this read primitive becomes interesting.

Why not higher?

Elevating to HIGH would require either active exploitation evidence or an impact ceiling that reaches code execution / VM escape / fleet compromise. This CVE delivers none of those. The S:C flag in the CVSS vector inflates the vendor score, but Scope Changed here means 'guest triggers a read in the host process' — the actual consequence is an info leak and a recoverable process crash, not a security boundary violation that yields control.

Why not lower?

Dropping to LOW would undervalue the fact that the target *is* a production hypervisor hosting dozens to hundreds of VMs. Even a DoS-only condition on an ESXi host causes operational disruption during HA failover, and the information disclosure component could theoretically leak sensitive host memory (encryption keys, session tokens). The 7.6 vendor score is inflated, but the asset class keeps this above trivial.

1. Restrict VM deployment privileges to named, MFA-protected accounts — The entire attack requires PR:H — VM deploy rights. Audit your vSphere roles and strip VirtualMachine.Inventory.Create and VirtualMachine.Config.* from any account that doesn't strictly need them. This is your primary compensating control and should be validated within the noisgate remediation SLA of 365 days, though a privilege audit can often be done within days.
2. Enable vm.restrictAdvancedConfig on all ESXi hosts — This VMware hardening flag blocks VMs from setting arbitrary advanced configuration keys, which is the likely trigger mechanism for this class of OOB read. Enabled by default in VCF 5.x/ESXi 9.x but may be off in legacy 8.0 environments.
3. Ensure ESXi management interfaces are not exposed to untrusted networks — Segment the vSphere management network (vCenter, ESXi DCUI/API) behind a jump host or PAM gateway. This adds a network-layer gate before the PR:H credential gate.
4. Deploy Qualys QIDs 388184, 216356, 216358 for asset inventory — Scan to identify which hosts are unpatched. Use results to prioritize patching within the 365-day remediation window. No mitigation SLA applies for MEDIUM.

Run this script on each ESXi host via SSH (or push via Ansible/PowerCLI remote SSH). Requires root access. Example: ssh root@esxi-host 'bash -s' < check_cve_2026_41703.sh

#!/bin/bash
# check_cve_2026_41703.sh
# Checks whether an ESXi host is patched against CVE-2026-41703
# Run as root on the ESXi host.
# Exit codes: 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN

PATCHED_BUILDS_8="25557999"
PATCHED_BUILDS_90="25595025"
PATCHED_BUILDS_91="25557999"

BUILD=$(vmware -v 2>/dev/null)
if [ -z "$BUILD" ]; then
  echo "UNKNOWN - cannot determine ESXi version. Is this an ESXi host?"
  exit 2
fi

VERSION=$(echo "$BUILD" | grep -oP '\d+\.\d+\.\d+')
BUILD_NUM=$(echo "$BUILD" | grep -oP '\d+$')

if [ -z "$BUILD_NUM" ]; then
  echo "UNKNOWN - could not parse build number from: $BUILD"
  exit 2
fi

echo "Detected: $BUILD (version=$VERSION build=$BUILD_NUM)"

case "$VERSION" in
  8.0.*)
    if [ "$BUILD_NUM" -ge "$PATCHED_BUILDS_8" ]; then
      echo "PATCHED - build $BUILD_NUM >= $PATCHED_BUILDS_8 (ESXi 8.0 U3k+)"
      exit 0
    else
      echo "VULNERABLE - build $BUILD_NUM < $PATCHED_BUILDS_8 (needs ESXi 8.0 U3k)"
      exit 1
    fi
    ;;
  9.0.*)
    if [ "$BUILD_NUM" -ge "$PATCHED_BUILDS_90" ]; then
      echo "PATCHED - build $BUILD_NUM >= $PATCHED_BUILDS_90 (ESXi 9.0.2.0100+)"
      exit 0
    else
      echo "VULNERABLE - build $BUILD_NUM < $PATCHED_BUILDS_90"
      exit 1
    fi
    ;;
  9.1.*)
    if [ "$BUILD_NUM" -ge "$PATCHED_BUILDS_91" ]; then
      echo "PATCHED - build $BUILD_NUM >= $PATCHED_BUILDS_91 (ESXi 9.1.0.0200+)"
      exit 0
    else
      echo "VULNERABLE - build $BUILD_NUM < $PATCHED_BUILDS_91"
      exit 1
    fi
    ;;
  *)
    echo "UNKNOWN - unrecognized ESXi version: $VERSION"
    exit 2
    ;;
esac

Sources

1. VMSA-2026-0006 — Broadcom/VMware Security Advisory
2. BleepingComputer — VMware fixes three critical flaws
3. The Hacker News — Three Critical VMware Flaws
4. Qualys ThreatPROTECT — VMware ESX, vCenter, Workstation, and Fusion Multiple Vulnerabilities
5. NHS England Digital — Cyber Alert CC-4821
6. SecurityWeek — Critical VM Escape Vulnerability Patched in VMware ESXi
7. Angry Sysops — vSphere 8.0 Update 3k Fixes Critical CVEs