CVE-2026-59309 and 59310: VMware vCenter Bugs Attackers Hit in Five Days

A patch that closes an unauthenticated path into your virtualization management plane is exactly the kind of update that should ship same-day, everywhere. Most environments don’t move that fast, and attackers know it. Broadcom fixed CVE-2026-59309 and CVE-2026-59310 in vCenter Server on July 29, 2026. By August 3, researchers were already watching compromised instances phone home to attacker infrastructure. If vCenter is reachable from anywhere an attacker could plausibly reach, patching this week isn’t optional, and if you were unpatched between those dates, patching alone may not be enough.

What’s actually broken

VMSA-2026-0006 covers two separate, both-critical bugs in vCenter Server, and they chain together nastily.

CVE-2026-59309 lives in VMware Directory Service (vmdir), the identity backbone vCenter uses to authenticate every login across a vSphere environment. The bug lets a network-based attacker skip authentication entirely, no valid username, password, or token required, and reach the management plane with what amounts to administrative access. For a system whose entire job is controlling who can touch your virtual machines, that’s about as bad as a flaw gets.

CVE-2026-59310 is a directory traversal in vCenter’s Syslog server. Crafted input lets a remote, unauthenticated attacker write files outside the directory the syslog service is supposed to be confined to, and researchers have confirmed this path leads to arbitrary code execution on the appliance itself.

Both carry a CVSSv3.1 score of 9.8, both require no authentication, and both need nothing more than network reachability to vCenter’s management interface. Broadcom’s advisory is blunt about mitigation: there isn’t one. No configuration change disables the affected components without breaking vCenter’s core function, so the patch is the only fix.

The five-day gap that mattered

What turns a critical advisory into an active incident is how fast attackers move, and here they moved fast. Broadcom’s patch landed July 29. Researchers tracking exploitation identified compromised vCenter instances first reaching out to attacker-controlled domains on August 3, five days after the fix was public and, for a meaningful number of environments, before it was actually applied.

The attack chain researchers observed follows a consistent pattern:

1. Path traversal via CVE-2026-59310 against an unpatched vCenter instance
2. Arbitrary file write used to drop a malicious cron job on the appliance
3. Cron job launches reverse_ssh, opening an outbound tunnel to
   attacker infrastructure that survives a simple process kill
4. Attacker maintains standing access to the vCenter management plane
   and, by extension, every host and VM it manages

That reverse_ssh step is the detail worth sitting with. It’s not a smash-and-grab. It’s built for persistence, an outbound connection that looks like ordinary egress traffic from a management appliance rather than an inbound exploit attempt your perimeter tooling is watching for. Researchers have counted 361 unique victim IP addresses across 47 countries running this exact pattern, and a separate, suspected China-nexus campaign has been observed chaining the same flaw to deploy Babuk-derived ransomware rather than just holding access. Meanwhile, a second wave of scanning activity is now fingerprinting vCenter instances specifically for CVE-2026-59309, walking the /websso SAML flow and probing POST /sdk/, the kind of reconnaissance that precedes a second round of exploitation against whatever didn’t get caught in the first.

Why this one deserves the fire drill

Vulnerability management programs triage by severity score and exploitability, and by both measures this pair clears the bar for immediate action rather than the next maintenance window. An unauthenticated bypass into your virtualization control plane isn’t a bug that affects one application or one server, it’s a bug that affects everything vCenter can reach, which for most organizations running VMware is the majority of their virtual infrastructure. Pair that blast radius with confirmed active exploitation inside a week of disclosure, and this sits in the same urgency bracket as any KEV-listed vulnerability, whether or not it’s formally on that specific list yet.

The persistence mechanism is also why “patch and move on” isn’t a complete response here. A reverse_ssh cron job planted before you applied the fix survives the patch. Closing the door after an attacker is already inside doesn’t remove them, it just stops new attackers from walking in through the same door.

What to actually do

1. Patch vCenter Server now if you haven’t. Broadcom’s advisory has the specific build numbers for every supported vSphere version; there’s no partial mitigation to buy time with.
2. Check for the persistence pattern before declaring the incident closed. Look at the vCenter appliance’s cron configuration for anything invoking reverse_ssh or an unfamiliar binary, and review outbound connections from the appliance for tunnels to unrecognized hosts.
3. Audit vmdir’s account list against your actual admin roster. An authentication bypass this clean is a plausible path to silently created administrative accounts, not just a one-time access event.
4. Review vCenter and syslog history back to July 29 for path traversal patterns or unexpected file writes, since exploitation is confirmed to have started within days of disclosure, not weeks.
5. Restrict network reachability to vCenter’s management interface as a standing practice, not just a stopgap. A management plane this critical shouldn’t be reachable from a flat network or the internet regardless of patch status.

If your team runs a formal vulnerability management process and wants a second set of eyes on how vCenter and the rest of the management plane are segmented, our team has walked several clients through exactly this kind of post-disclosure exposure review, the same discipline that matters for any actively exploited, unauthenticated bug regardless of which vendor ships it next.