Someone left the master key to every virtual machine under the doormat, and the door faces the hallway
CVE-2026-59309 is an authentication bypass in the VMware Directory Service (vmdir), the identity backbone of vCenter Server. A remote, unauthenticated attacker with network access to vCenter sends crafted requests that circumvent all authentication checks, yielding full administrative control over the management plane. Affected versions include vCenter 8.0 (all builds before U3k), vSphere Foundation / VMware Cloud Foundation 9.0.x (before 9.0.2.0100), 9.1.x (before 9.1.0.0300), Cloud Foundation 5.x (pending async patch KB88287), and all Telco Cloud Platform 3.0–5.1.x / Telco Cloud Infrastructure 3.0 builds. vSphere 7.x and earlier are presumed affected but are end-of-support with no patch forthcoming. Discovered by Phil Brass and Matt South of Atredis Partners, disclosed July 29, 2026 via VMSA-2026-0006. Broadcom confirms no workarounds exist.
Broadcom's CRITICAL / 9.8 rating is not vendor inflation — it is, if anything, a clinical understatement of the operational blast radius. vCenter is the single pane of glass for every ESXi host, every VM, every template, every permission, and every workflow in a VMware estate. An auth bypass here is not 'one server compromised'; it is 'every workload under that vCenter is now attacker-controlled.' Previous vCenter auth-adjacent vulns (CVE-2021-21972, CVE-2023-34048) were weaponized within days of PoC publication and became ransomware entry points. The absence of a public PoC today is a countdown timer, not a mitigating factor.
5 steps from start to impact.
Network reachability to vCenter
- TCP reachability to vCenter appliance (port 443 and/or vmdir LDAP ports)
- Most enterprises segment vCenter onto a management VLAN not directly internet-facing
- Firewall rules between user/server VLANs and management VLAN reduce lateral reachability
Send crafted authentication-bypass request to vmdir
- Knowledge of the crafted request format (currently undisclosed, no public PoC)
- No public PoC or exploit code exists as of July 30, 2026
- Broadcom has intentionally withheld technical details to slow weaponization
Obtain vCenter administrative session
- Successful auth bypass from step 2
- None — once the bypass succeeds, the management plane is fully compromised
vpxd audit events.Pivot to ESXi hosts and all managed VMs
- vCenter administrative session from step 3
- None — this is normal vCenter admin functionality
Fleet-wide compromise or ransomware deployment
- ESXi host access from step 4
- Immutable backup solutions (e.g., Veeam with hardened repos) can limit ransomware impact
- Network segmentation between vCenter management and backup infrastructure can slow lateral movement
- In-guest EDR/AV — vCenter-based attacks operate at the hypervisor management layer, below the guest OS. An attacker encrypting VMDKs at the datastore level or modifying VM configurations via the vSphere API will not trigger any in-guest endpoint protection agent.
- WAF or reverse proxy in front of vCenter — the vulnerable component is the VMware Directory Service, which may use LDAP-based protocols, not just HTTPS. A WAF protecting port 443 does not cover LDAP ports and cannot inspect the proprietary vmdir protocol for exploit payloads.
- vCenter SSO password rotation — this is an authentication *bypass*, not a credential-stuffing or brute-force attack. Rotating passwords or enforcing complexity does nothing because the attacker never presents credentials at all.
The supporting signals.
| In-the-Wild Exploitation | Not observed. Broadcom confirms no evidence of exploitation or scanning as of July 29, 2026. GreyNoise shows no related scanning activity. |
|---|---|
| Proof-of-Concept | No public PoC. Broadcom has intentionally withheld technical details. No known repos on GitHub or elsewhere. Given vCenter's value as a target, expect weaponization within days to weeks of any technical disclosure. |
| EPSS Score | Not yet scored — CVE was disclosed July 29, 2026; EPSS model has not yet ingested. Historical precedent: previous vCenter auth-bypass CVEs reached >0.90 EPSS within 30 days of PoC publication. |
| KEV Status | Not listed on CISA KEV as of July 30, 2026. Given the CRITICAL rating and vCenter's attack surface history, KEV addition is probable if exploitation is confirmed. |
| CVSS Vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H — 9.8 Critical. Every metric is at worst-case except Scope (Unchanged). Network-accessible, no authentication, no user interaction, low complexity, full CIA impact. |
| Affected Versions | vCenter 8.0 (all builds < U3k), vSphere Foundation 9.0.x (< 9.0.2.0100), 9.1.x (< 9.1.0.0300), VMware Cloud Foundation 5.x (async patch KB88287), Telco Cloud Platform 3.0–5.1.x, Telco Cloud Infrastructure 3.0. vSphere 7.x and earlier presumed affected, no patch (end-of-support). |
| Fixed Versions | vCenter 8.0 U3k, vSphere Foundation 9.0.2.0100, vSphere Foundation 9.1.0.0300. Cloud Foundation 5.x via async patch to 8.0 U3k (KB88287). Note: 8.0 U3k blocks VCF 9.1 upgrade path — plan accordingly. |
| Internet Exposure | Shodan: ~5,800 vCenter instances. Censys: ~30,000 HTTP hosts with vCenter fingerprints. Most production vCenter is on management VLANs, but even internal-only exposure is high-risk given lateral movement from any compromised host on the management segment. |
| Disclosure Date | July 29, 2026 — advisory VMSA-2026-0006 published by Broadcom. |
| Credited Researchers | Phil Brass and Matt South of Atredis Partners. Responsible disclosure through Broadcom's security response process. |
Sources.
- Broadcom Advisory VMSA-2026-0006
- Rapid7 Emergency Threat Response
- The Hacker News — Three Critical VMware Flaws
- SecurityOnline — VMware Authentication Bypass
- Penligent — CVE-2026-59309 Analysis
- AngrySysOps — vSphere 8.0 U3k VCF Compatibility
- GBHackers — Critical VMware vCenter Flaws
- CyberSecurityNews — VMware Auth Bypass
Why this verdict
- Unauthenticated remote access: The CVSS vector confirms PR:N/UI:N/AC:L — no credentials, no phishing, no user action, low complexity. This is the widest possible attack surface short of a wormable condition.
- Role multiplier: vCenter is *canonically* a high-value-role component. It is not occasionally deployed in a high-value position — it exists *solely* to manage hypervisor fleets. 100% of vCenter installations are, by definition, fleet-management control planes. Compromise yields: administrative control over all ESXi hosts → access to all VMDK virtual disks → ability to deploy ransomware at the datastore layer bypassing in-guest EDR → extraction of credentials from domain controller VMs → domain takeover. The blast radius is fleet-scale to domain-scale.
- No workaround available: Broadcom explicitly confirms no workaround. The only remediation is patching. Compensating controls (network segmentation) reduce exposure probability but do not eliminate the vulnerability. This means the window between disclosure and patch application is a period of unmitigated risk.
- Historical weaponization velocity: VMware vCenter authentication and RCE vulnerabilities have a documented pattern of rapid weaponization. CVE-2021-21972 had a public PoC within 48 hours. CVE-2023-34048 was exploited by Chinese state-sponsored actors (UNC3886) as a zero-day. CVE-2024-37079/37080 saw mass scanning within a week. The current absence of a PoC is a temporary condition.
- Friction assessment — management network segmentation: Most vCenter instances sit on management VLANs, which reduces the internet-reachable population to ~5,800–30,000 instances. However, management network access is routinely achievable post-initial-compromise via admin workstation pivot, VPN credential theft, or misconfigured segmentation. This friction reduces the *probability of opportunistic internet scanning* but does NOT meaningfully reduce the risk from targeted attackers who have any internal foothold. Given the target's value, this friction is insufficient to warrant a downgrade.
Why not higher?
A 9.8 is already at the practical ceiling of CVSS 3.1 scoring (10.0 requires Scope: Changed). The Scope metric is Unchanged because the vulnerable component and impacted component are the same security authority (vCenter). While the real-world blast radius extends to ESXi hosts and VMs, the CVSS model doesn't capture that operational amplification beyond 9.8. There is no basis to exceed the vendor's score.
Why not lower?
Downgrading would require evidence that the attack chain is impractical in real deployments or that the blast radius is limited. Neither condition holds. The attack is unauthenticated, low-complexity, and requires only network reachability to a port that must be open for vCenter to function. The target component is a Tier-0 infrastructure asset where compromise is definitionally fleet-scale. Management network segmentation is a deployment hygiene factor, not an architectural barrier — it is routinely bypassed in real intrusions. The absence of a public PoC is a *temporal* condition that does not reduce the *inherent* severity of the vulnerability.
Crowdsourced verification payload.
Run this script on the vCenter appliance itself via SSH (or on a Linux jump host with curl and network access to vCenter on port 443). Requires no special privileges beyond network reachability. Example: bash check_cve_2026_59309.sh vcenter.corp.local
#!/usr/bin/env bash
# check_cve_2026_59309.sh — Detect whether a vCenter appliance is patched for CVE-2026-59309
# Usage: bash check_cve_2026_59309.sh [vcenter_hostname_or_ip]
# Exit codes: 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN
set -euo pipefail
TARGET="${1:-localhost}"
# Known fixed build numbers (from VMSA-2026-0006)
# vCenter 8.0 U3k, 9.0.2.0100, 9.1.0.0300
FIXED_8x="8.0.3.00600" # 8.0 U3k build baseline
FIXED_90="9.0.2.0100"
FIXED_91="9.1.0.0300"
echo "[*] Querying vCenter build info at https://${TARGET}..."
RESPONSE=$(curl -sk --connect-timeout 10 "https://${TARGET}/sdk/vimServiceVersions.xml" 2>/dev/null || true)
if [ -z "$RESPONSE" ]; then
# Fallback: try the appliance API
RESPONSE=$(curl -sk --connect-timeout 10 "https://${TARGET}/rest/appliance/system/version" 2>/dev/null || true)
fi
if [ -z "$RESPONSE" ]; then
echo "[!] UNKNOWN — Could not connect to vCenter at ${TARGET}"
echo " Verify network reachability and that this is a vCenter appliance."
exit 2
fi
# Try to extract version string
VERSION=$(echo "$RESPONSE" | grep -oP '(?<=<version>)[^<]+' 2>/dev/null || true)
BUILD=$(echo "$RESPONSE" | grep -oP '(?<=<build>)[^<]+' 2>/dev/null || true)
# Fallback: JSON API response
if [ -z "$VERSION" ]; then
VERSION=$(echo "$RESPONSE" | grep -oP '"version"\s*:\s*"\K[^"]+' 2>/dev/null || true)
BUILD=$(echo "$RESPONSE" | grep -oP '"build"\s*:\s*"\K[^"]+' 2>/dev/null || true)
fi
if [ -z "$VERSION" ]; then
echo "[!] UNKNOWN — Connected but could not parse version info."
echo " Raw response (first 500 chars):"
echo "$RESPONSE" | head -c 500
exit 2
fi
echo "[*] Detected vCenter version: ${VERSION} (build: ${BUILD:-unknown})"
# Version comparison
MAJOR=$(echo "$VERSION" | cut -d. -f1)
MINOR=$(echo "$VERSION" | cut -d. -f2)
version_gte() {
# Returns 0 if $1 >= $2 using sort -V
[ "$(printf '%s\n%s' "$1" "$2" | sort -V | head -n1)" = "$2" ]
}
case "${MAJOR}.${MINOR}" in
8.0)
if version_gte "$VERSION" "$FIXED_8x"; then
echo "[+] PATCHED — vCenter ${VERSION} is at or above 8.0 U3k."
exit 0
else
echo "[-] VULNERABLE — vCenter ${VERSION} is below 8.0 U3k (${FIXED_8x})."
echo " Apply vCenter 8.0 Update 3k immediately."
exit 1
fi
;;
9.0)
if version_gte "$VERSION" "$FIXED_90"; then
echo "[+] PATCHED — vCenter ${VERSION} is at or above ${FIXED_90}."
exit 0
else
echo "[-] VULNERABLE — vCenter ${VERSION} is below ${FIXED_90}."
echo " Apply vSphere Foundation 9.0.2.0100 immediately."
exit 1
fi
;;
9.1)
if version_gte "$VERSION" "$FIXED_91"; then
echo "[+] PATCHED — vCenter ${VERSION} is at or above ${FIXED_91}."
exit 0
else
echo "[-] VULNERABLE — vCenter ${VERSION} is below ${FIXED_91}."
echo " Apply vSphere Foundation 9.1.0.0300 immediately."
exit 1
fi
;;
7.*|6.*)
echo "[-] VULNERABLE — vCenter ${VERSION} is end-of-support."
echo " No patch available. Upgrade to a supported branch immediately."
exit 1
;;
*)
echo "[!] UNKNOWN — Unrecognized vCenter version: ${VERSION}"
exit 2
;;
esac