Broadcom shipped patches for two critical vCenter Server vulnerabilities on 29 July 2026. Five days later, according to the German incident-response firm QUIRSO, a threat actor was already using them to drop backdoors on unpatched management servers. By the time CISA added the flaws to its Known Exploited Vulnerabilities catalog on 18 August, QUIRSO had counted 361 distinct victim IP addresses across 47 countries — and in at least one case, the intrusion ended with Babuk-derived ransomware running against the ESXi hosts vCenter was supposed to be managing.
The two flaws
Broadcom’s advisory, VMSA-2026-0006, covers several products, but two vCenter Server bugs carry identical CVSS 9.8 scores and did the damage:
- CVE-2026-59309 — an authentication bypass in vCenter’s VMware Directory Service, letting a remote attacker skip login entirely.
- CVE-2026-59310 — a directory traversal vulnerability in vCenter’s Syslog server, letting an attacker with network access to vCenter write files outside the intended directory and execute arbitrary code.
Neither requires prior credentials. Neither has a workaround — Broadcom’s advisory is explicit that the only fix is the patched build (vCenter Server 8.0 U3k, or 9.0.2.0100 / 9.1.0.0300 for the newer Cloud Foundation and vSphere Foundation lines). For anything sitting on an unpatched vCenter appliance reachable on the network, that combination is essentially a skeleton key.
From syslog write to root shell
Rapid7’s technical analysis lays out why a directory traversal bug in a logging component is so dangerous: the Syslog server writes attacker-influenced content to files inside the vCenter Server Appliance’s filesystem. Path traversal means the attacker can choose where that content lands. Land it somewhere the appliance later executes — a cron entry, a startup script — and a stream of log lines becomes a foothold.
That is what The Hacker News, reporting on QUIRSO’s
investigation,
describes happening in the wild: a malformed cron file written through the
syslog abuse, which then pulls down a Linux implant researchers labeled
linuxFile from external infrastructure. From there the pattern is
familiar — a WebSocket connection back to attacker infrastructure for
command and control, systemd and cron entries for persistence, SSH keys
injected for durable access, and reconnaissance against the vSphere REST API
using a spoofed GoodMoodle-VCFleet/1.0 user agent to blend in with routine
management traffic.
Root on vCenter is root on everything it manages
vCenter is not just another server. It is the control plane for every ESXi host, VM, datastore and network policy in the environment it manages — the same structural fact that made a stolen Okta super-admin session so damaging in the MGM Resorts breach, and the same reason vSphere HA leans so heavily on vCenter staying trustworthy. Once the attacker had a foothold on the appliance, QUIRSO’s writeup describes lateral movement into the ESXi hosts themselves via newly created accounts, and — in at least one documented case — the deployment of a Babuk-derived ransomware locker against those hosts. Encrypting an ESXi host doesn’t just lock files; it takes down every VM running on it at once, the same blast-radius problem the MGM breach exposed a different way.
Who’s behind it, and how confident that attribution is
QUIRSO’s attribution — a “suspected China-nexus” actor, assessed with moderate confidence — rests on circumstantial but consistent evidence: Chinese-language artifacts in the attacker’s own scripts, apparent reuse of research published in Chinese-language security venues, and activity patterns consistent with a UTC+08:00 working day. None of that is proof of state sponsorship, and the researchers frame it as moderate confidence for a reason — this is the kind of signal that narrows the field without closing the case. What is not in dispute is the scale: 361 unique victim IPs is not a targeted operation against one organization, it’s opportunistic scanning-and-exploiting at internet scale against every vCenter appliance the actor could reach before patches propagated.
The five-day window
Broadcom published fixes on 29 July. QUIRSO’s timeline has exploitation evidence for the companion authentication-bypass CVE by 1 August — three days later — and full syslog-traversal exploitation activity established within the week. CISA’s KEV entry didn’t land until 18 August, three weeks into active exploitation. That gap is not a criticism of CISA’s process; KEV additions require confirmed evidence of in-the-wild use, which takes time to establish and verify. It is, however, a reminder that the KEV catalog is a lagging indicator. Waiting for a CVE to appear on it before prioritizing a patch means treating a three-week-old fire as breaking news.
The lessons that generalise
A patch’s publication date is the start of the exploitation clock, not the end of your patching window. Five days from advisory to active exploitation is fast, but it is no longer unusual for internet-facing management infrastructure. Attackers now routinely diff patched and unpatched builds within hours of release to reverse-engineer the fix.
Management planes should not be internet-reachable, full stop. Every technical step in this campaign assumed the attacker had network access to vCenter’s Syslog service and REST API. A vCenter appliance reachable only from a locked-down management VLAN, with no path from the general network or the internet, turns a CVSS 9.8 remote exploit into a bug that requires an existing foothold to even reach.
Logging and management-plane services deserve the same scrutiny as authentication code. A syslog receiver feels like plumbing, not attack surface. This campaign is a reminder that anything which writes attacker-influenced data to disk is a potential code-execution primitive, regardless of how mundane its job description sounds.
Attribution confidence and impact severity are separate axes. “Moderate confidence, suspected nation-state” told defenders nothing they needed to change operationally. What mattered was CVSS 9.8, no workaround, internet-exploitable, and a documented five-day time-to-exploitation — all knowable the day Broadcom published the advisory, independent of who eventually turned out to be behind the keyboard.
Tech-Bee is an independent technology publication. This piece is drawn from Broadcom’s VMSA-2026-0006 advisory, CISA’s Known Exploited Vulnerabilities catalog, Rapid7’s technical analysis of the vulnerabilities, and The Hacker News’s reporting on QUIRSO GmbH’s incident-response investigation. Attribution to a “suspected China-nexus” actor reflects QUIRSO’s own stated confidence level, not independent confirmation by Tech-Bee.
