VMware vCenter contains a directory traversal vulnerability in the Syslog server.

CVE-2026-59310 is a directory traversal vulnerability in VMware vCenter Server's built-in Syslog service. An unauthenticated attacker with network access to the Syslog listener (ports 514/TCP, 1514/TCP, 514/UDP) can craft path-traversal payloads that escape the intended directory and achieve arbitrary code execution on the vCenter appliance as root. Affected versions span vCenter 8.0 (all builds before U3k), vCenter 9.0.x (before 9.0.2.0100), and vCenter 9.1.x (before 9.1.0.0300), plus downstream products VMware Cloud Foundation 5.x/9.x, vSphere Foundation 9.x, and Telco Cloud Platform 3.0–5.1.x. Broadcom states no workarounds exist.

Broadcom rates this CRITICAL at 9.8 and the vendor severity is fully justified. vCenter is not a random appliance — it *is* the management plane for every ESXi host and every VM in your environment. The CVSS vector (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) correctly captures the no-auth, no-interaction, full-impact nature of the bug. While vCenter should never be internet-facing, it is always reachable on management VLANs, meaning any attacker with internal network access — post-phish, post-VPN, post-contractor-laptop — can reach it. The 9.8 is not hype; it reflects a genuinely catastrophic attack surface on a component whose compromise cascades to the entire virtualized estate.

Why this verdict

• Unauth network RCE with zero interaction — the CVSS vector AV:N/AC:L/PR:N/UI:N is the most dangerous attack profile possible. No credentials, no phishing, no user clicks required.
• Role multiplier: vCenter IS the hypervisor control plane. This is not a component that *sometimes* runs in a high-value role — it exists exclusively to manage ESXi hosts and VMs. Compromise of vCenter gives the attacker root on vCenter → credentials for all ESXi hosts → control of every VM → domain controllers, databases, backup servers, the entire fleet. Blast radius is fleet-scale by definition. This alone floors the verdict at CRITICAL.
• No workarounds exist. Broadcom explicitly confirms there is no mitigation short of patching or total network isolation of the Syslog ports. You cannot disable the Syslog service without breaking log forwarding functionality.
• vCenter's KEV track record is 10 prior entries. History shows that vCenter RCE bugs are weaponized rapidly (CVE-2021-21985, CVE-2023-34048, CVE-2024-37079). The window between disclosure and exploitation has been shrinking with each iteration.
• Management network reachability is not meaningful friction. While vCenter is not internet-facing in best-practice deployments, it is always reachable from the management VLAN. Any attacker with internal network access — post-phish, compromised VPN, rogue contractor, or lateral movement from any server subnet — can reach it. 'Requires internal network' is not a downgrade factor for a post-initial-access scenario.

Why not higher?

A 9.8 is already the maximum practical CVSS score for Scope:Unchanged. There is no higher severity bucket than CRITICAL. The only thing preventing a 10.0 is that Scope is Unchanged in the CVSS vector (the Syslog service itself is the vulnerable component, not a cross-scope boundary like a VM escape).

Why not lower?

Downgrading below CRITICAL would require evidence that the attack chain has meaningful friction or that vCenter occupies a low-value role in some deployments — neither is true. The bug is unauthenticated, requires no interaction, has no workaround, and the target component is the single most important infrastructure management server in any VMware environment. Even the absence of a public PoC is temporary — Atredis Partners' responsible disclosure and the patch diff will yield exploitation details rapidly. Historical precedent (CVE-2021-21985 weaponized in <2 weeks) confirms this.

1. Firewall the vCenter Syslog ports immediately — Block inbound traffic to ports 514/TCP, 514/UDP, and 1514/TCP on every vCenter appliance from all sources except explicitly authorized syslog *clients* (ESXi hosts that forward logs to vCenter). This is your only compensating control since no vendor workaround exists. Deploy within the noisgate mitigation SLA of 3 days for CRITICAL findings. Use host-based firewall rules (iptables on VCSA) and network ACLs on the management VLAN switch/firewall.
2. Restrict management VLAN access — Tighten ACLs on your management network segment so only jump hosts and authorized admin workstations can reach vCenter on *any* port. This reduces the population of hosts that could be used as a pivot point. If you don't already have microsegmentation here, this CVE is your forcing function.
3. Enable FIM on vCenter appliance — Deploy or verify file integrity monitoring on the VCSA appliance filesystem, focusing on /etc/cron.d/, /etc/systemd/system/, /usr/lib/vmware-syslog/, and web shell paths under /usr/lib/vmware-vsphere-ui/. This provides detection-in-depth if the compensating firewall rule is bypassed.
4. Monitor vSphere API for anomalous operations — Alert on unusual vSphere API calls — bulk VM snapshot creation, VIB installation on ESXi hosts, SSO credential extraction, or permission changes — which would indicate post-exploitation activity if the vulnerability is exploited before patching.

Run this script on each vCenter Server Appliance (VCSA) via SSH as root. Example: ssh [email protected] 'bash -s' < check_cve_2026_59310.sh. Requires root shell access to the VCSA.

#!/bin/bash
# check_cve_2026_59310.sh
# Checks VMware vCenter Server for CVE-2026-59310 (Syslog directory traversal)
# Run on the VCSA appliance as root.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -euo pipefail

PATCHED_BUILDS_8="25163495"  # 8.0 U3k build number (verify against release notes)
PATCHED_VER_90="9.0.2.0100"
PATCHED_VER_91="9.1.0.0300"

# Get vCenter version and build
if command -v vpxd >/dev/null 2>&1; then
    FULL_VER=$(vpxd -v 2>/dev/null || echo "")
elif [ -f /etc/vmware/version ]; then
    FULL_VER=$(cat /etc/vmware/version)
else
    echo "UNKNOWN - Cannot determine vCenter version. Is this a VCSA?"
    exit 2
fi

if [ -z "$FULL_VER" ]; then
    echo "UNKNOWN - Could not read vCenter version info."
    exit 2
fi

echo "Detected vCenter: $FULL_VER"

# Extract version components
VER=$(echo "$FULL_VER" | grep -oP '[0-9]+\.[0-9]+\.[0-9]+' | head -1 || echo "")
BUILD=$(echo "$FULL_VER" | grep -oP 'build-\K[0-9]+' || echo "")

if [ -z "$VER" ]; then
    echo "UNKNOWN - Could not parse version string from: $FULL_VER"
    exit 2
fi

MAJOR=$(echo "$VER" | cut -d. -f1)
MINOR=$(echo "$VER" | cut -d. -f2)

echo "Parsed version: $VER (build: ${BUILD:-unknown})"

# Version comparison function
ver_gte() {
    printf '%s\n%s' "$2" "$1" | sort -V -C
}

if [ "$MAJOR" -eq 8 ]; then
    # vCenter 8.0 — check for U3k build
    if [ -n "$BUILD" ] && [ "$BUILD" -ge "$PATCHED_BUILDS_8" ] 2>/dev/null; then
        echo "PATCHED - vCenter 8.0 build $BUILD is >= U3k ($PATCHED_BUILDS_8)"
        exit 0
    else
        echo "VULNERABLE - vCenter 8.0 build ${BUILD:-unknown} is below U3k ($PATCHED_BUILDS_8)"
        exit 1
    fi
elif [ "$MAJOR" -eq 9 ] && [ "$MINOR" -eq 0 ]; then
    if ver_gte "$VER" "9.0.2"; then
        echo "PATCHED - vCenter $VER meets or exceeds fixed version $PATCHED_VER_90"
        exit 0
    else
        echo "VULNERABLE - vCenter $VER is below fixed version $PATCHED_VER_90"
        exit 1
    fi
elif [ "$MAJOR" -eq 9 ] && [ "$MINOR" -eq 1 ]; then
    if ver_gte "$VER" "9.1.0"; then
        echo "PATCHED - vCenter $VER meets or exceeds fixed version $PATCHED_VER_91"
        exit 0
    else
        echo "VULNERABLE - vCenter $VER is below fixed version $PATCHED_VER_91"
        exit 1
    fi
else
    echo "UNKNOWN - vCenter version $VER is outside known affected ranges (8.0, 9.0.x, 9.1.x)"
    exit 2
fi

Sources

1. VMSA-2026-0006 — Broadcom Security Advisory
2. Rapid7 ETR — CVE-2026-59309 & CVE-2026-59310 Analysis
3. BleepingComputer — VMware fixes three critical flaws
4. GBHackers — Critical VMware vCenter Flaws
5. Qualys ThreatPROTECT — VMware ESX, vCenter Multiple Vulnerabilities
6. Field Effect — Broadcom Patches Critical VMware Vulnerabilities
7. NVD — CVE-2026-59310
8. HADESS — vCenter Attack Surface Analysis