CVE-2026-59310: a syslog bug that became vCenter RCE

Broadcom shipped VMSA-2026-0006.1 on July 29, patching five vulnerabilities across ESX, vCenter, Workstation, and Fusion. Two of them, CVE-2026-59309 and CVE-2026-59310, both scored a critical 9.8 and both hit vCenter Server — the single management plane that controls every ESXi host, VM, and cluster in a vSphere environment (Broadcom). Five days later, attackers were already inside. By the time researchers finished counting, 361 vCenter instances across 47 countries had been compromised — not eventually, but within about a week of the patch existing (BleepingComputer).

Root cause

CVE-2026-59310 is a directory-traversal vulnerability in vCenter’s Syslog server component. An unauthenticated attacker with network access sends a crafted request containing path-traversal sequences that let the payload escape the Syslog service’s intended write directory and land somewhere the vCenter service account can execute it — arbitrary code execution, no credentials required (Rapid7). It shipped alongside CVE-2026-59309, an authentication-bypass flaw in VMware Directory Service that lets a remote attacker skip authentication entirely and reach the vCenter management plane directly. Broadcom’s advisory doesn’t confirm the two are chained in the wild, but the shape is uncomfortable regardless: the same patch closed one hole that gets an attacker into vCenter without a password and another that gets them code execution once they’re there.

The Syslog server is meant to receive and write log data from managed hosts — accepting a filename or path fragment as part of that write path and not sufficiently validating it is the exact class of bug that’s shown up in file-upload and log-ingestion handlers for years. What makes it worse here is the target: this isn’t a web app writing to its own upload directory, it’s the write path of the process that holds API credentials and inventory control for an entire virtualization estate.

Blast radius

Broadcom disclosed and patched on July 29. Exploitation began August 3 — five days later — and the victim count climbed fast: 151 new compromised IPs by August 4, 343 by August 5, 361 across 47 countries by August 7, with the heaviest concentration in Germany, the U.S., Turkey, Iran, and France (BleepingComputer; The Hacker News). That curve is the real story: a patch existing for less than a week was already irrelevant to hundreds of organizations that hadn’t applied it, and researchers at QUIRSO tied the campaign’s start date directly to the disclosure — the advisory itself was the starting gun.

Once in, attackers didn’t just drop a webshell and move on. They deployed reverse_ssh, an open-source SSH tunneling tool, via a malicious cron job for persistence, giving them a durable outbound channel back into the vCenter host that survives a reboot and doesn’t depend on the original traversal bug staying exploitable. QUIRSO researchers suspect APT-level involvement given the coordination and target selection, though attribution evidence hasn’t been made public pending law enforcement coordination. CISA added CVE-2026-59310 to the Known Exploited Vulnerabilities catalog on August 18 with a remediation deadline of August 21 for federal civilian agencies — three days to patch a bug that had already been under active exploitation for two weeks (CISA).

Remediation

There is no workaround for either CVE-2026-59309 or CVE-2026-59310 — Broadcom’s advisory is explicit that vendor patching is the only fix. Update to vCenter Server 9.1.0.0300, 9.0.2.0100, or 8.0 U3k (8.0 U2f for the older branch); VMware Cloud Foundation and vSphere Foundation carry the same fixed builds. If you’re still triaging, the underlying exposure question is simple: is vCenter’s management interface reachable from anywhere it shouldn’t be. Unlike VCO’s SD-WAN orchestrator, which by design has to expose some surface to the internet, vCenter Server has no legitimate reason to be internet-facing at all — it should sit behind a VPN or bastion with access restricted to admin subnets, full stop.

If you’ve already patched, don’t assume you’re done — a fixed build closes the hole going forward but does nothing about an attacker who got in during the five-day exploitation window before you updated. Check for reverse_ssh processes or binaries, unrecognized cron entries on the vCenter appliance, and outbound connections to unfamiliar hosts, especially over SSH or on ports not normally used by vCenter’s legitimate services. Review vCenter audit and Syslog service logs for path-traversal patterns (../ sequences) in the window between July 29 and whenever you applied the patch. A compromised vCenter instance had root-equivalent reach into your virtualization estate for however long it sat unpatched — treat that as an incident to scope, not a box to check off.

The bigger lesson

This is the same shape as the Arista VeloCloud CVE from earlier this month: a critical, unauthenticated RCE in the one piece of software that manages everything else, exploited within days of the fix that revealed it existed. The pattern is becoming the norm rather than the exception — attackers now treat every KEV addition as a target list, and the gap between “patch available” and “mass exploitation” has compressed from months to single digits of days for anything with real downstream reach. If a piece of software’s job is to hold credentials for and control over dozens or hundreds of other systems, it needs to be patched on an emergency timeline by default, not queued into the next maintenance window — and it should never be reachable from a network any less trusted than the systems it manages.