When Broadcom published VMSA-2026-0006 on 29 July, we noted here that the company's own track record with vCenter flaws was blunt: advisory first, working exploit within weeks. This time nobody had to wait weeks. The Hacker News' reporting and a technical writeup from QUIRSO's threat research team both track exploitation of CVE-2026-59309 starting 1 August, three days after the patch, and CVE-2026-59310 by 3 August. Five calendar days, patch to compromise at scale.
An auth bypass and a directory traversal, chained
The advisory covered two unauthenticated, CVSS 9.8 flaws in vCenter Server. CVE-2026-59309 is an authentication bypass in vCenter's Directory Service - it gets an attacker past the login. CVE-2026-59310 is a directory traversal in the Syslog server component, the part of vCenter that quietly collects and archives log messages from across the virtual infrastructure. Chained together, an attacker with network access to vCenter can manipulate the paths that syslog writes to, landing arbitrary files in directories the operating system was never meant to let a log collector touch - which is a roundabout but effective way to get code execution as root. Broadcom's own advisory is explicit that there's no workaround for either flaw; the fix is VMware vCenter Server 8.0 U3k, or the equivalent build in VMware Cloud Foundation and vSphere Foundation 9.1.0.0300 and 9.0.2.0100.
361 victims, 47 countries, one backdoor
Once inside, the actor's tradecraft was consistent enough across victims that researchers could fingerprint it: a backdoor tracked as "linuxFile" (also seen as systemlog or linux_x86), installed via systemd services, cron jobs and injected SSH keys for persistence, talking back to a WebSocket-based command-and-control channel with XOR-obfuscated addressing. QUIRSO's Denis Szadkowski described the C2 traffic as using "the malware's own application-layer cryptography" on top of that obfuscation - not sophisticated in any single step, but layered enough to slow down casual inspection. Timezone and language artifacts in the tooling point to UTC+08:00 working hours, which alongside the tradecraft is why researchers are calling this a suspected China-nexus operation rather than crediting it to a named group outright. Germany, the United States, Turkey, Iran and France account for 185 of the 361 victim IP addresses counted so far, spanning technology firms, universities, research institutions and telecoms operators - a spread that reads more like opportunistic scanning of every exposed vCenter instance than a targeted campaign against a specific sector.
Root access is rarely the end state
Some victims have already seen the next stage: a Babuk-derived ransomware variant, appending a .babyk extension to encrypted files on compromised ESXi hosts. That's the visible outcome, and the one that gets an incident escalated on a Monday morning, but root-level access to a vCenter Server is a foothold with far more uses than encryption - credential harvesting across every VM it manages, lateral movement into anything on the same management network, or simply sitting quietly as a persistence mechanism nobody's looking for yet. Ransomware is what tells a security team a breach happened; it's rarely the full extent of what an attacker with that level of access chose to do.
Why this is the exact scenario CISA just wrote a directive for
Publicly exposed, listed in CISA's Known Exploited Vulnerabilities catalog, exploitable at scale with no manual steps, and capable of handing over total system control - CVE-2026-59310 ticks all four of the criteria CISA set out in Binding Operational Directive 26-04, issued in June, for the small category of flaws federal agencies must now patch within three calendar days rather than the standard cycle. We've written a fuller framework for what operationalising that kind of SLA actually takes, beyond federal agencies who are required to, in our new white paper on the three-day patch mandate.
- Patch to VMware vCenter Server 8.0 U3k, or VMware Cloud Foundation/vSphere Foundation 9.1.0.0300 or 9.0.2.0100, immediately - there is no vendor-supported workaround for either flaw.
- Confirm vCenter Server is not reachable from the internet; both flaws require only network access to the management interface, not valid credentials.
- Check for the "linuxFile" backdoor: unexpected systemd services, cron entries and SSH authorized_keys additions on vCenter Server Appliances, plus outbound WebSocket connections that don't match known management traffic.
- If compromise is suspected, assume the exposure extends beyond the vCenter host itself - review credential material and lateral access for every VM under that instance's management, not just the appliance.
- Treat any CVE meeting all four of CISA's BOD 26-04 criteria - internet-facing, KEV-listed, automatable, full-control - as a same-week priority regardless of whether your organisation is a federal agency the directive actually binds.
Five days from patch to 361 organisations is not a gap most vulnerability management cycles are built to close. If you'd like help testing whether yours can, email sales@halfteck.com.