Someone can mail a postcard to your datacenter's front desk and it rewrites the building's master key card
CVE-2026-59310 is a directory traversal in VMware vCenter Server's rsyslog receiver. The Syslog service listens on UDP/514, TCP/514, and TCP/6514 — no authentication on any listener. Attacker-controlled RFC 5424 header fields (APP-NAME, HOSTNAME) are spliced directly into filesystem paths by rsyslog's omfile dynafile writer without sanitization. By padding with ../ sequences, an attacker writes arbitrary content to any location on the VCSA filesystem — including /etc/cron.d/, which cron evaluates as root within sixty seconds. One UDP packet, zero credentials, full root shell. Affected versions: vCenter 8.0 prior to 8.0 U3k, 8.0 U2 prior to 8.0 U2f, 9.0.x.x prior to 9.0.2.0100, and 9.1.x.x prior to 9.1.0.0300. VMware Cloud Foundation, vSphere Foundation, and Telco Cloud Platform share the same vulnerable component.
Broadcom rated this CVSS 9.8 CRITICAL and the score is dead-on. There is nothing to argue with here. The vector is network-reachable, complexity is trivial, no privileges or interaction needed, and impact is total confidentiality/integrity/availability loss. The vendor's score actually *underestimates* reality because CVSS Scope is marked Unchanged, yet vCenter compromise gives direct control over every ESXi host and every VM in the environment — the real blast radius is fleet-scale. Active mass exploitation began within five days of disclosure, with a China-nexus APT and Babuk ransomware operators confirmed across 361 victims in 47 countries by early August 2026. CISA added this to KEV on August 18, 2026 and subsequently flagged it as ransomware-exploited. There are no workarounds; patching is the only remediation.
5 steps from start to impact.
Reach the Syslog listener
- Network path to vCenter on port 514 (UDP/TCP) or 6514 (TCP/TLS)
- Well-segmented environments restrict port 514/6514 to designated syslog forwarders only
- Internet-facing exposure of port 514 is uncommon (port 443 is more frequently exposed)
../ or percent-encoded traversal sequences. GreyNoise and Defused Cyber have reported active scanning spikes targeting vCenter syslog ports.Send crafted RFC 5424 syslog message with path traversal
HOSTNAME field contains approximately 16 ../ sequences followed by a target path (e.g., ../../../../../../../../../../../../../../../../etc/cron.d/payload). The rsyslog omfile dynafile writer interpolates this unsanitized value into the output file path template "/var/log/vmware/esx/%hostname%/%hostname%-syslog.log". Because the hostname appears at *two* filesystem depths, both components resolve through the traversal to the same target directory — the 'used twice' trick documented by Atredis Partners (Phil Brass and Matt South). Public PoCs from ChinaRan0/CVE-2026-59310-POC, vpxuser/CVE-2026-59310, and BiuTrap/CVE-2026-59310 automate this entirely.- Ability to send a single UDP or TCP packet to the syslog port
- Knowledge of the traversal technique (public PoCs available)
- None — the exploit is a single packet with zero complexity
Arbitrary file write to /etc/cron.d/ or VAMI web root
/etc/cron.d/ to plant crontab entries that execute within one minute. Alternatively, writing to /opt/vmware/share/htdocs/ (VAMI's static web root on port 5480) plants files retrievable without authentication, enabling data exfiltration or webshell staging. Artifact names observed in the wild include zz-poc59310, vmware-vpxd-stats-*, vmware-perf-collect-*, and vmware-perf-sync-*.- Steps 1-2 completed successfully
- None — rsyslog runs as root; it can write anywhere on the filesystem
/etc/cron.d/ or /opt/vmware/share/htdocs/. YARA rule matching RFC 5424 prefix + traversal sequence + target path fragments.Root code execution via cron
185.144.28.120:3232, 5.34.176.100:5244), and webshell deployment (vmware-perf-update.jsp in the Perfcharts directory). The staging directory /tmp/.x/ and WebSocket C2 channel ws://intel.se9ly9upbhay.shop:8080/ws have been documented across multiple victims.- Cron service running (default on VCSA)
- None — cron is always running on vCenter Server Appliance
SSO credential theft and lateral movement to ESXi hosts
e876ceb47ba092420a97724a957152b3808568b0) encrypts VM disk files with the .babyk extension.- Root shell on VCSA (achieved in Step 4)
- ESXi hosts managed by the compromised vCenter
- If vCenter manages zero ESXi hosts (lab-only), blast radius is limited — but this is extremely rare in production
/etc/cron.d/, /opt/vmware/share/htdocs/, and the Perfcharts webshell directories. This does not prevent exploitation but provides sub-minute detection of successful exploitation, enabling rapid containment. Deploy within 3 days.185.144.28.120, 5.34.176.100, intel.se9ly9upbhay.shop. Block outbound SSH from the VCSA to any destination except authorized management targets. This disrupts the documented post-exploitation chain but does not prevent initial exploitation or alternative C2 channels. Deploy immediately.secpath-replace to all four rsyslog dynafile templates, neutralizing path traversal at the root cause. This is the only complete remediation. No workaround exists per Broadcom. Target deployment within 3 days (noisgate mitigation SLA) and complete across all instances within 90 days (noisgate remediation SLA). Given active ransomware exploitation, treat the 3-day window as a hard ceiling.- WAF/reverse proxy in front of vCenter port 443 — The attack targets port 514 (syslog), not port 443 (HTTPS). A WAF provides zero coverage for this vulnerability.
- MFA on vCenter SSO login — The exploit is pre-authentication. It never touches the SSO login flow. MFA is irrelevant to the initial access chain.
- EDR on Windows endpoints — vCenter Server Appliance runs Photon OS (Linux). Windows EDR agents do not execute on the VCSA. If you have Linux EDR on the VCSA, it *may* detect post-exploitation activity but will not block the initial syslog write.
- Disabling the VAMI web interface (port 5480) — This prevents the file-retrieval variant through the web root but does NOT prevent the cron-based code execution path, which is the primary attack vector observed in the wild.
- Network-level IDS/IPS with generic syslog signatures — Standard syslog inspection rules will not flag RFC 5424-compliant messages with traversal sequences in header fields. Purpose-built Sigma/Suricata rules targeting
../in HOSTNAME/APP-NAME fields are required.
The supporting signals.
| In-the-Wild Exploitation | Confirmed and ongoing. China-nexus APT campaign exploited 361 victims across 47 countries within 8 days of disclosure (Aug 3–10, 2026). Babuk ransomware deployment confirmed on ESXi hosts. CISA KEV explicitly flags ransomware use. Campaign documented by QUIRSO IR, BleepingComputer, and The Hacker News. |
|---|---|
| Proof-of-Concept Availability | Multiple weaponized PoCs public. ChinaRan0/CVE-2026-59310-POC (original), vpxuser/CVE-2026-59310 (enhanced fork with check/exec/shell/cleanup subcommands), BiuTrap/CVE-2026-59310 (netcat-based PoC), HORKimhab/CVE-2026-59310. Atredis Partners (Phil Brass, Matt South) published detailed technical reproduction methodology. |
| EPSS Score | 0.02565 (2.57%) — probability of exploitation in the next 30 days. This is a lagging indicator; actual exploitation began 5 days post-disclosure and is ongoing at scale. EPSS will likely adjust upward. |
| CISA KEV Status | Listed August 18, 2026. BOD 26-04 remediation deadline: August 21, 2026 (3-day window for FCEB agencies). Subsequently updated to flag active ransomware exploitation. |
| 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 base metric is worst-case except Scope (Unchanged), which arguably *understates* the cross-host blast radius through ESXi compromise. |
| Affected Version Ranges | vCenter 8.0 all builds prior to 8.0 U3k, 8.0 U2 prior to 8.0 U2f, 9.0.x.x prior to 9.0.2.0100, 9.1.x.x prior to 9.1.0.0300. Also affects VMware Cloud Foundation, vSphere Foundation, and Telco Cloud Platform (3.0, 4.x, 5.0.x, 5.1.x → KB449886). |
| Fixed Versions | vCenter 8.0 U3k, 8.0 U2f, 9.0.2.0100, 9.1.0.0300. Patches released July 29, 2026. The fix adds secpath-replace property replacer to all four rsyslog dynafile templates, neutralizing .. and path separators before interpolation. |
| Scanning & Exposure Data | Historically, Shodan indexes 5,000–14,000 internet-facing vCenter instances on port 443. Port 514 exposure is smaller but present. Defused Cyber observed scanning spikes against vCenter syslog ports coinciding with PoC releases. The 361 confirmed victims likely represent a fraction of total exploitation. |
| Disclosure & Attribution | Disclosed July 29, 2026 by Broadcom. Discovered by Phil Brass and Matt South at Atredis Partners. First exploitation observed August 3, 2026 (5 days post-disclosure). By August 5, 95% of eventually observed victims (343 of 361 IPs) were already compromised. |
| Related Vulnerability | CVE-2026-59309 (CVSS 9.8) — VMware Directory Service authentication bypass — disclosed in the same advisory. Both are pre-auth, network-reachable, and have been exploited in tandem. |
Sources.
- Broadcom Security Advisory VMSA-2026-0014
- Rapid7 ETR: Critical VMware vCenter Vulnerabilities CVE-2026-59309/59310
- QUIRSO: Global Exploitation of CVE-2026-59310 by China-Nexus APT
- BleepingComputer: CISA Critical VMware vCenter RCE Exploited by Ransomware Gangs
- Mobeta: vCenter Pre-Auth RCE Technical Deep Dive (CVE-2026-59309/59310)
- CybersecurityNews: VMware Syslog Path Traversal — Attack Chain and IOCs
- vpxuser/CVE-2026-59310 — Weaponized PoC on GitHub
- CISA KEV Catalog Entry
Why this verdict
- Pre-auth, zero-click, trivial complexity: A single crafted UDP packet to port 514 achieves root code execution. No credentials, no user interaction, no exploit chain complexity. The CVSS AC:L/PR:N/UI:N triple is fully accurate and there is no friction at the exploitation step itself.
- Active mass exploitation with ransomware at scale: 361 confirmed victims across 47 countries within 8 days. China-nexus APT and Babuk ransomware operators. This is not theoretical — it is an active emergency. CISA KEV-listed with a 3-day remediation deadline for federal agencies.
- Multiple weaponized PoCs freely available: At least four GitHub repositories provide turnkey exploitation tools with interactive shell, command execution, and cleanup capabilities. The barrier to entry is effectively zero for any attacker who can reach port 514.
- Syslog port reachability is realistic: While port 514 is less commonly internet-facing than port 443, it is routinely reachable from internal networks. In any post-initial-access scenario (phishing, VPN compromise, adjacent host), the attacker reaches vCenter's management VLAN. The 361-victim count confirms real-world reachability is not theoretical.
- Role multiplier: vCenter is *the* canonical hypervisor orchestration platform. 100% of vCenter installs occupy the high-value role by definition — it is the management control plane for all ESXi hosts and VMs in the environment. Compromise of vCenter = compromise of the entire virtualized fleet. The documented attack chain succeeds in this role (root on VCSA → SSO credential theft → ESXi admin → ransomware on all VM datastores). Blast radius is fleet-scale: every VM, every datastore, every ESXi host managed by that vCenter instance. This is not a workstation or line-of-business server — it is the single point of control for the virtualized infrastructure. The verdict floor is CRITICAL per the high-value-role rule, and no friction factor justifies pulling below that floor.
Why not higher?
CVSS 9.8 is already at the ceiling of the scoring model. The only metric not at maximum is Scope (Unchanged), and while the real-world blast radius extends to ESXi hosts and VMs, the CVSS 3.1 specification defines Scope narrowly. A 10.0 would require Scope:Changed with equivalent impact metrics, which the vector does not claim. The reassessed score stays at 9.8 because the vendor's assessment is accurate.
Why not lower?
Every potential downgrade argument fails under scrutiny. Port 514 not being internet-facing is the only friction point, but it is irrelevant for the majority of attack scenarios: any attacker with internal network access (post-phishing, VPN, compromised endpoint) reaches the management VLAN. The 361-victim count across 47 countries in 8 days proves reachability is not a meaningful barrier. vCenter is 100% high-value-role by definition — there is no 'workstation deployment' of vCenter. The exploit is a single packet with public tooling. Active ransomware campaigns eliminate any theoretical-only argument. Downgrading below CRITICAL would be malpractice.
Crowdsourced verification payload.
Run this script on the vCenter Server Appliance via SSH as root. Example: ssh [email protected] 'bash -s' < check_cve_2026_59310.sh. Requires root access to inspect the rsyslog configuration template and check listening ports. Returns exit code 0 (PATCHED), 1 (VULNERABLE), or 2 (UNKNOWN).
#!/bin/bash
# CVE-2026-59310 Vulnerability Check — VMware vCenter Server Appliance
# Checks for the secpath-replace fix in rsyslog dynafile templates.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
set -uo pipefail
CONF="/usr/lib/vmware-visl-integration/config/vmware-syslog.conf.template"
CRON_DIR="/etc/cron.d"
VAMI_ROOT="/opt/vmware/share/htdocs"
RESULT="UNKNOWN"
EXIT_CODE=2
echo "=== CVE-2026-59310 Vulnerability Check ==="
echo "Date: $(date -u '+%Y-%m-%d %H:%M:%S UTC')"
echo "Host: $(hostname -f 2>/dev/null || hostname)"
echo ""
# 1. Check vCenter version
if command -v vpxd &>/dev/null; then
VPXD_VER=$(vpxd -v 2>/dev/null | head -1)
echo "[INFO] vCenter version: ${VPXD_VER:-unknown}"
else
echo "[WARN] vpxd binary not found — is this a VCSA?"
fi
echo ""
# 2. Definitive check: does the rsyslog template use secpath-replace?
if [ -f "$CONF" ]; then
SECPATH_COUNT=$(grep -c 'secpath-replace' "$CONF" 2>/dev/null || true)
if [ "$SECPATH_COUNT" -ge 1 ]; then
echo "[PASS] rsyslog template contains secpath-replace ($SECPATH_COUNT occurrences)."
RESULT="PATCHED"
EXIT_CODE=0
else
echo "[FAIL] rsyslog template does NOT contain secpath-replace."
RESULT="VULNERABLE"
EXIT_CODE=1
fi
else
echo "[WARN] Config not found at $CONF"
echo "[WARN] Falling back to running rsyslog config check."
RUNNING_CONF=$(rsyslogd -N1 2>&1 || true)
if echo "$RUNNING_CONF" | grep -q 'secpath-replace'; then
echo "[PASS] Running rsyslog config contains secpath-replace."
RESULT="PATCHED"
EXIT_CODE=0
elif echo "$RUNNING_CONF" | grep -q 'dynaFile'; then
echo "[FAIL] Running rsyslog config has dynaFile templates WITHOUT secpath-replace."
RESULT="VULNERABLE"
EXIT_CODE=1
else
echo "[WARN] Cannot determine rsyslog configuration status."
fi
fi
echo ""
# 3. Check if syslog ports are listening (exposure indicator)
echo "[INFO] Syslog port exposure:"
for PORT in 514 6514; do
TCP_LISTEN=$(ss -tlnp 2>/dev/null | grep ":${PORT} " || true)
UDP_LISTEN=$(ss -ulnp 2>/dev/null | grep ":${PORT} " || true)
if [ -n "$TCP_LISTEN" ] || [ -n "$UDP_LISTEN" ]; then
echo " Port ${PORT}: LISTENING"
[ -n "$TCP_LISTEN" ] && echo " TCP: $TCP_LISTEN"
[ -n "$UDP_LISTEN" ] && echo " UDP: $UDP_LISTEN"
else
echo " Port ${PORT}: not listening"
fi
done
echo ""
# 4. IOC spot check: look for known exploitation artifacts
echo "[INFO] IOC spot check:"
IOC_FOUND=0
for ARTIFACT in "zz-poc59310" "zz-poc59310-syslog.log" "vmware-perf-update.jsp"; do
HITS=$(find "$CRON_DIR" "$VAMI_ROOT" -name "$ARTIFACT" 2>/dev/null || true)
if [ -n "$HITS" ]; then
echo " [ALERT] Found exploitation artifact: $HITS"
IOC_FOUND=1
fi
done
# Check for suspicious cron entries
SUSPICIOUS_CRON=$(grep -rl 'poc59310\|se9ly9upbhay\|185\.144\.28\.120\|5\.34\.176\.100' "$CRON_DIR" 2>/dev/null || true)
if [ -n "$SUSPICIOUS_CRON" ]; then
echo " [ALERT] Suspicious cron entries found: $SUSPICIOUS_CRON"
IOC_FOUND=1
fi
if [ "$IOC_FOUND" -eq 0 ]; then
echo " No known IOCs detected (not exhaustive)."
fi
echo ""
echo "=== Result: $RESULT ==="
exit $EXIT_CODE