CVE-2026-59310: VMware vCenter RCE Exploited in 47 Countries

This week in our InSEKurity of the Week series: a directory traversal vulnerability in the VMware vCenter syslog server that lets an unauthenticated attacker with nothing but network reachability execute arbitrary code on the appliance that manages an organization’s entire virtual estate. Broadcom disclosed CVE-2026-59310 on July 29, 2026 as part of VMSA-2026-0006, rated CVSS 9.8, with a blunt note attached: there is no workaround. Five days later, the QUIRSO Threat Research team began watching compromised vCenter systems phone home. By August 7 they had counted 361 victim IP addresses across 47 countries — not exploitation attempts, but hosts already calling attacker infrastructure — with a suspected APT actor deploying the open-source reverse_ssh framework for persistent, firewall-evading access. Germany leads the victim list. What makes this week’s entry worth reading twice is not the score. It is the gap: as of publication, Broadcom’s own Q&A document still states it has no information suggesting exploitation in the wild, and CISA has not added the CVE to its KEV catalog. If you are waiting for a KEV listing to justify an emergency change, this is the week to stop doing that.

🚨 Summary

CVE ID: CVE-2026-59310
CVSS 3.1 Score: 9.8 Critical (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H), assigned by VMware as CNA
CWE: CWE-22 (Improper Limitation of a Pathname to a Restricted Directory / ‘Path Traversal’)
Affected Software: VMware vCenter 9.1.x (before 9.1.0.0300), 9.0.x (before 9.0.2.0100), 8.0 (before U3k / U2f) — plus every stack that embeds vCenter: VMware Cloud Foundation (5.x, 9.0.x, 9.1.x), VMware vSphere Foundation (9.0.x, 9.1.x), VMware Telco Cloud Platform (3.0-5.1.x) and VMware Telco Cloud Infrastructure (3.0). vSphere 7.0 is also affected and is past End of General Support.
Vulnerable component: the vCenter syslog server — the log collector service on the appliance, not the vSphere Client
Attack Vector: Network — reachability to the vCenter syslog listener
Authentication Required: None
User Interaction: None
Impact: Arbitrary code execution on the vCenter appliance; from there, administrative authority over every managed ESX host and virtual machine
Patch Status: ✅ Patched in vCenter 9.1.0.0300, 9.0.2.0100, 8.0 U3k (build 25600417) and 8.0 U2f. ❌ No workaround exists — Broadcom states this explicitly.
Published: Advisory VMSA-2026-0006 on July 29, 2026, revised to VMSA-2026-0006.1 on August 3, 2026; NVD record published July 30, 2026
Exploitation Status: 🔴 Active exploitation reported by QUIRSO — 361 victim IPs in 47 countries as of August 7, 2026. Broadcom’s advisory Q&A still states it has no information of in-the-wild exploitation.
CISA KEV: ❌ Not listed as of KEV catalog version 2026.08.17
Reported by: Phil Brass and Matt South of Atredis Partners

🖥️ What is VMware vCenter?

VMware vCenter is the centralized management server for a VMware virtualization estate. It is the appliance that inventories and controls every ESX/ESXi host in the environment, that performs vMotion and DRS placement decisions, that owns cluster configuration and HA policy, that holds the permission model determining who may do what to which virtual machine, and that brokers the credentials used to reach the hypervisors themselves. Administrators interact with it through the vSphere Client; automation reaches it through PowerCLI and the vSphere Automation REST API. In practice, one vCenter typically governs dozens to thousands of virtual machines.

That concentration is the whole point of the product, and it is also the reason a vCenter vulnerability is categorically different from a vulnerability on a single server. Code execution on vCenter is not a foothold on one host — it is administrative authority over the substrate every other host runs on. Domain controllers, backup servers, jump hosts, the SIEM collector and the file server are all, from vCenter’s perspective, just objects it can snapshot, clone, reconfigure, power off, or mount the disks of. Ransomware operators worked this out years ago, which is why hypervisor management has become one of the most consistently targeted layers in enterprise IT.

The specific component at issue here is narrower and easy to overlook. vCenter runs a syslog server — a collector that receives log messages from ESX hosts and other infrastructure so that vSphere logging can be centralized on the appliance. It listens on the standard syslog ports (UDP/TCP 514, and TCP 1514 for TLS), which Broadcom documents as inbound ports for the vCenter Server Appliance, and the appliance firewall opens them for the vmware-syslog service. A log collector is exactly the kind of component that gets configured once, forgotten, and never appears on anyone’s threat model — while quietly accepting unauthenticated input from the network by design.

Typical Use Cases

Centralized cluster management: single-pane administration of ESX hosts, clusters, resource pools, and datastores across one or many sites.
Workload mobility and availability: vMotion, Storage vMotion, Distributed Resource Scheduler, and High Availability all depend on vCenter as the decision-making authority.
Role-based access control for the virtual estate: vCenter owns the permission model that determines which administrators can touch which virtual machines.
Lifecycle and patch management: vSphere Lifecycle Manager drives ESX host remediation and image compliance from vCenter.
Automation and integration: PowerCLI, the vSphere Automation REST API, Terraform providers, backup software, and monitoring platforms all authenticate to vCenter as their entry point.
Log centralization: the appliance’s syslog service collects log messages from ESX hosts — the component this CVE lives in.

🔍 Technical Analysis

Vulnerability Description

Broadcom’s description is short and precise: “VMware vCenter contains a directory traversal vulnerability in the Syslog server. A malicious actor with network access to vCenter may exploit this issue to execute arbitrary code.”

Unpacked, that is a CWE-22 failure. The syslog service accepts input from the network and, somewhere along the path from message to disk, uses attacker-influenced data to construct a filesystem path without properly constraining it to the intended directory. Traversal sequences in that data escape the log directory, and the write lands somewhere the service account controls — somewhere that leads to execution. The CVSS vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H tells the rest of the story: reachable over the network, low attack complexity, no privileges, no user interaction, and total impact on confidentiality, integrity, and availability.

The important thing to understand about the attack surface is that a syslog collector is unauthenticated by design. Syslog as a protocol has no meaningful authentication in its common deployments; the service’s job is to accept whatever arrives on port 514 and write it down. That means there is no login to fail, no session to hijack, and no credential to brute force. The only control standing between an attacker and the vulnerable code path is network reachability — which is precisely why Broadcom’s “no workaround” statement is not a formality. There is no configuration toggle that fixes a parsing bug, and the only compensating control available is one you either already have (a properly segmented management network) or do not.

It is worth being clear about what is not public. Neither Broadcom nor the researchers who reported the flaw have published the specific message format, the traversal payload, or the file that gets written. There is no public proof-of-concept exploit for CVE-2026-59310. The exploitation that QUIRSO observed was reconstructed from victim telemetry and post-exploitation behaviour, not from a published exploit — which means the capability is in someone’s hands but not yet in everyone’s. That distinction matters for your risk calculus in exactly one direction: the actor using it today is more selective and more capable than a commodity scanner, not less.

Root Cause Analysis

Unsanitized path construction from network input (CWE-22): the syslog server derives a filesystem path from data that arrives over the network without normalizing it or confining the result to the intended directory. This is the oldest file-handling bug there is, and it keeps appearing in log-processing code specifically because log data is treated as inert text rather than as untrusted input.
An unauthenticated listener on a management appliance: syslog collection has no authentication step to fail closed on. Every packet that reaches the port reaches the parser. On an appliance whose entire value proposition is privileged control of the estate, that is an unusually consequential place to accept anonymous input.
Write primitive to a location that yields execution: a traversal that only wrote to an unremarkable directory would be an integrity problem. Broadcom rates the outcome as arbitrary code execution, which means the reachable write targets a location the appliance later executes from or interprets — turning a file-write into an RCE.
The service account’s reach: the code executes in the context of a service on the vCenter appliance. On a system whose purpose is to hold hypervisor credentials and orchestrate the estate, even a non-root service context is a launchpad rather than a limitation.
No architectural separation between “log collector” and “management plane”: the syslog service shares an appliance with the vSphere authentication stack, the inventory database, and the credentials for every managed host. A bug in the least security-critical component on the box inherits the blast radius of the most security-critical one.
No customer-side remediation short of patching: because the flaw is in the parsing code, there is no supported setting to disable, no filter to apply, and no hardening guide entry that removes it. Broadcom’s Q&A answers the workaround question with a single word: no.

Attack Vector

The exact request is not public. The diagram below shows the shape of the attack as reconstructed from the vendor description and the observed post-exploitation behaviour, so defenders can reason about where their controls sit. It contains no payload and is not an exploit.

# Illustrative attack-flow diagram -- NOT a functional exploit.
# No traversal payload, message format, or target path is reproduced here;
# none of these details are public. Shape only.

Remote attacker (no account, no credentials)
      |
      | (1) Reach the vCenter syslog listener. Standard syslog ports are
      |     UDP/TCP 514 and TCP 1514 (TLS). No authentication step exists
      |     on this path -- syslog accepts what arrives.
      v
vCenter syslog server (vmware-syslog)
      |
      | (2) CVE-2026-59310: attacker-influenced data is used to build a
      |     filesystem path. Traversal sequences escape the intended log
      |     directory (CWE-22).
      v
Write outside the log directory, into a location the service controls
      |
      | (3) That location leads to execution. Broadcom: "may exploit this
      |     issue to execute arbitrary code."
      v
Code execution on the vCenter appliance
      |
      | (4) Observed in the wild (QUIRSO): a cron job is installed for
      |     persistence, launching the open-source reverse_ssh client,
      |     which dials OUT to attacker infrastructure -- so no inbound
      |     firewall rule is required to keep the channel open.
      v
Persistent C2 on the management plane
      |
      | (5) Consequence, not a separate exploit: vCenter is the authority
      |     over every managed ESX host and virtual machine it inventories.
      v
Administrative reach over the virtual estate

Two properties of step (4) deserve emphasis, because they shape detection. First, reverse_ssh establishes an outbound connection. A perimeter that blocks inbound traffic to vCenter does nothing about a channel initiated from inside. Second, reverse_ssh is a legitimate open-source penetration testing tool, not bespoke malware. QUIRSO says so directly in the metadata of their own detection rule: “This is a dual-use tool signature. A match identifies reverse_ssh code; maliciousness must be established from deployment context and telemetry.” Finding it on a vCenter appliance is nonetheless not ambiguous — there is no legitimate reason for a reverse shell framework to live on a vCenter Server Appliance.

Exploitation in the Wild

The timeline here is unusually tight, and the disagreement between sources is itself part of the story.

Disclosure was the starting gun. Broadcom published VMSA-2026-0006 on July 29, 2026. QUIRSO observed the first compromised systems contacting attacker-controlled infrastructure on August 3, 2026 — five days later. Their assessment is blunt: “the strong correlation between the time of disclosure and exploitation suggests the disclosure as the initial starting point for the campaign.”
The curve was near-vertical. August 4 brought 151 new victim IPs in a single day. By August 5, roughly 95% of all identified victims (343 of 361) had already appeared. By August 7 the total stood at 361 victim IP addresses across 47 countries. That is a campaign that saturated its target list in about 72 hours.
These are compromises, not scans. The 361 figure counts hosts observed communicating with attacker infrastructure — successful intrusions, not exploitation attempts hitting a honeypot.
Germany heads the list of affected countries. The top five — Germany, the United States, Turkey, Iran and France — account for 185 of the 361 victim IPs, more than half the total.
The persistence mechanism is dual-use tooling. Attackers install a malicious cron job that launches reverse_ssh, an open-source SSH-based reverse-shell framework, giving them an outbound command channel that survives reboots and bypasses inbound firewall policy.
Attribution is unresolved. QUIRSO assesses a suspected APT actor but has not named one. Notably, they cite coordination with law-enforcement partners as the reason for withholding the granular indicators — so the public IoC set is deliberately thin.
The vendor and the researchers do not agree. Broadcom’s VMSA-2026-0006 Q&A document states: “Broadcom has no information to suggest that exploitation of these issues has occurred in the wild.” That document is the vendor’s supplement to the advisory, and it has not been updated to reflect QUIRSO’s findings. CISA has likewise not added CVE-2026-59310 to the KEV catalog — we verified this against KEV catalog version 2026.08.17 (1,666 entries). Treat the absence of a KEV listing as a gap in a reporting pipeline, not as evidence of safety.

Post-Exploitation Impact

Full control of the vCenter appliance: the credentials vCenter holds for managed ESX hosts, its inventory database, its certificates, and its identity-source configuration must all be considered exposed.
Administrative authority over every managed virtual machine: snapshot, clone, reconfigure, power-cycle, or attach the virtual disks of any VM in the inventory — including domain controllers, backup servers, and security tooling.
Datastore-level access to VM disks: mounting a VMDK sidesteps every in-guest control. Disk encryption at rest on the datastore does not help when the request comes from the platform that holds the keys.
Persistence that survives patching: the cron job and reverse_ssh binary live on the appliance filesystem. Installing 9.1.0.0300 closes the door; it does not evict anyone already inside.
A pivot into the guest estate: from hypervisor-level access, an attacker can reach guests that were never network-reachable from their original position.
Destruction of the recovery path: an actor with vCenter authority can delete snapshots, unregister VMs, and target backup infrastructure — which is precisely the ransomware playbook for virtualized environments.
Logging and visibility manipulation: compromising the log collector gives an attacker an obvious opportunity to influence what the estate records about them.

⚠️ Impact Assessment

Immediate Impact

Unauthenticated remote code execution on the management plane of the virtual estate, with no user interaction.
No workaround. Broadcom is explicit. Network restriction reduces exposure; only the patch remediates.
A live campaign with a 72-hour saturation curve, concentrated on Germany, the US, Turkey, Iran and France.
The alerting you rely on may not fire. No KEV listing, and a vendor Q&A that still says no known in-the-wild exploitation. Prioritization processes keyed to those signals will under-rate this.
Patching is necessary but not sufficient. If your vCenter was internet-reachable and unpatched between July 29 and the day you patched, you owe yourself a compromise assessment.

Affected Versions

Product / branch	Status	Fixed version
VMware vCenter 9.1.x	Vulnerable before fix	9.1.0.0300
VMware vCenter 9.0.x	Vulnerable before fix	9.0.2.0100
VMware vCenter 8.0 (U3 line)	Vulnerable before fix	8.0 U3k (build 25600417, released 2026-07-29)
VMware vCenter 8.0 (U2 line)	Vulnerable before fix	8.0 U2f (added in VMSA-2026-0006.1)
VMware vSphere / vCenter 7.0	Affected — past End of General Support (2025-10-02)	Extended support contract required; Broadcom urges upgrading
VMware Cloud Foundation 5.x, 9.0.x, 9.1.x	Vulnerable before fix	See VMSA for the VCF-specific bundle
VMware vSphere Foundation 9.0.x, 9.1.x	Vulnerable before fix	9.0.2.0100 / 9.1.0.0300
VMware Telco Cloud Platform 3.0-5.1.x, Telco Cloud Infrastructure 3.0	Vulnerable before fix	Follow the instructions linked in the VMSA

Broadcom notes that patches are cumulative — any version newer than the ones listed also resolves the issue, and no prior patch needs to be applied first. Two operational caveats from the release notes: these updates are not eligible for vCenter Quick Patch, and upgrading from vCenter 8.0 U3k to vCenter 9.1.0 (or any patch based on 9.1.0) is not supported at time of release — a “back-in-time” restriction to plan around if 9.1 is on your roadmap. Always confirm against the official VMSA, which Broadcom calls the source of truth.

Other CVEs in the same advisory — VMSA-2026-0006 is a five-issue bundle, and patching for CVE-2026-59310 addresses the rest of the vCenter side too:

CVE	Component	CVSS 3.1	Summary
CVE-2026-59309	VMware Directory Service (vCenter)	9.8	Unauthenticated authentication bypass
CVE-2026-59310	vCenter syslog server	9.8	Directory traversal to arbitrary code execution
CVE-2026-47876	ESX VMXNET3 adapter	9.3	Out-of-bounds write — a genuine VM escape from guest admin to host
CVE-2026-41703	ESX / Workstation / Fusion	2.7-7.6	Out-of-bounds read: information disclosure or host-process DoS
CVE-2026-41709	ESX	2.7	Insufficient logging — administrator actions not recorded

Affected Environments

Any vCenter reachable from a network an attacker can reach. Internet-exposed management interfaces are the acute case, but a flat internal network where any workstation can route to vCenter is the same problem with a slower fuse.
Environments where the syslog collector is enabled and reachable — often configured once during deployment and never revisited.
Service providers and multi-tenant estates: one vCenter governing many customers’ workloads concentrates the blast radius enormously.
Telco environments: Telco Cloud Platform and Telco Cloud Infrastructure both embed vCenter, and both are in scope.
Organizations still on vSphere 7.0 — affected, out of general support since October 2, 2025, and dependent on an extended support contract to obtain a fix at all.
Estates with a slow change-control cadence for management infrastructure: vCenter patching often requires a maintenance window that competes with everything else. This one does not disrupt running workloads (see below), which removes the usual excuse.

Attacker Profiles

State-sponsored actors: QUIRSO’s assessment points at an APT. Hypervisor management is ideal terrain for long-dwell espionage — it grants access to everything while sitting below the endpoint tooling that would normally see it.
Ransomware operators: encrypting at the hypervisor layer is the most efficient attack available against a virtualized estate, and vCenter is the shortest path to it. The current campaign’s persistence-first behaviour is consistent with either espionage or pre-positioning for later monetization.
Initial access brokers: vCenter administrative access is premium, resellable inventory.
Opportunistic actors, later: no public PoC exists today. When one appears — and for a bug this valuable, one eventually does — exploitation collapses to a scripted scan against every reachable syslog port on the internet.

🛡️ Mitigation Strategies

Immediate Actions (Priority 1) ⚡

Establish your exact vCenter version and build. Broadcom documents two methods. In the vSphere Client, the build is on the Summary tab. From PowerCLI, connect and read the properties of the connection object:

# Broadcom's documented PowerCLI method (VMSA-2026-0006 Q&A, question 25).
Connect-VIServer -Server vcenter.example.com

# Version string, e.g. 8.0.3
$global:DefaultVIServer.Version

# Build number, e.g. 25600417 for vCenter 8.0 U3k
$global:DefaultVIServer.Build

# While you are connected: ESX is affected by three other CVEs in the
# same advisory. Broadcom's documented host check (question 26):
Get-VMHost | Select-Object Name,Version,Build

The same information is available through the vSphere Automation REST API, which is convenient if you are inventorying many vCenters:

# 1) Create an API session. Prompts for the password; returns a session ID.
#    -s silent, -k skips certificate validation (drop -k once you trust the cert),
#    -u supplies the username, -X POST selects the method.
curl -sk -u 'administrator@vsphere.local' -X POST \
  https://vcenter.example.com/api/session

# 2) Read the appliance version using that session ID.
#    Returns JSON including "version" and "build".
curl -sk -H 'vmware-api-session-id: <session-id-from-step-1>' \
  https://vcenter.example.com/api/appliance/system/version

Compare the result against the fixed-version table above.

Patch. There is no alternative. Install 9.1.0.0300, 9.0.2.0100, 8.0 U3k, or 8.0 U2f as appropriate for your branch, via the VAMI or your normal vSphere update mechanism. Two facts make this an easier sell to change management than most emergency patches:
- Updating vCenter does not disrupt running workloads. Broadcom states this plainly: you lose the vSphere Client and other management interfaces briefly, but virtual machines and containers keep running.
- Patches are cumulative. You do not need to apply intermediate patches first; one update brings you current.
Note that these updates are not eligible for vCenter Quick Patch, so plan for the conventional update path.

Determine whether the syslog listener is running and who can reach it. On the appliance, Broadcom documents service-control for service status:

# On the vCenter Server Appliance shell (SSH as root).
# 'service-control' is the documented VCSA utility for managing services.
service-control --status vmware-syslog

# Full picture of what is running on the appliance.
service-control --status --all

Then verify reachability from outside your management network — the answer that matters is not what the appliance thinks, but what an attacker can touch:

# From a host OUTSIDE the intended management network.
# -Pn skips host discovery, -sU scans UDP, -p 514 checks the syslog port.
# (UDP scanning is slow; --reason explains why a state was assigned.)
sudo nmap -Pn -sU -p 514 --reason <vcenter-ip>

# TCP syslog and TLS syslog ports.
nmap -Pn -p 514,1514 --reason <vcenter-ip>

# And the management interface itself, while you are here.
nmap -Pn -p 443 --reason <vcenter-ip>

Anything other than filtered/closed from an untrusted network is a finding independent of this CVE.

If the appliance was reachable and unpatched after July 29, hunt before you declare victory. The observed persistence is a cron job plus a reverse_ssh binary. On the appliance shell:

# All of the following run on the appliance shell as root
# (crontab -u requires privilege; prefix with sudo if you are not root).

# Root's crontab -- the observed persistence mechanism.
crontab -l -u root

# System-wide cron locations on the Photon OS-based appliance.
ls -la /etc/cron.d/ /etc/cron.hourly/ /etc/cron.daily/ /var/spool/cron/

# Look for the usual download-and-run patterns inside cron definitions.
# -R recurses, -n prints line numbers, -I skips binary files,
# -E enables extended regular expressions.
grep -R -n -I -E '(curl|wget|/tmp/|base64|nc |ssh -R)' \
  /etc/cron.d /etc/cron.daily /etc/cron.hourly /var/spool/cron 2>/dev/null

# Recently added or modified systemd units -- an alternative persistence
# location. -l long listing, -t sorts by mtime (newest first).
ls -lt /etc/systemd/system/

# Files written to the appliance since the advisory date.
# -newermt takes a date string; -type f limits results to regular files.
find /tmp /var/tmp /usr/local /opt -xdev -type f -newermt '2026-07-29' \
  -printf '%T+ %p\n' 2>/dev/null | sort

Look for the outbound channel. reverse_ssh dials out, so egress telemetry is where it shows up:
```
# Established outbound TCP connections from the appliance.
# -t TCP only, -n numeric (no DNS), -p shows the owning process.
ss -tnp state established

# Anything listening that you did not put there.
ss -tlnp
```
A vCenter appliance has a small, predictable egress profile: your ESX hosts, your identity provider, your NTP and DNS servers, Broadcom update endpoints. Anything else is worth explaining.
Assume credential exposure if you find anything. vCenter holds credentials for managed ESX hosts, service accounts, and identity-source integrations. A confirmed compromise means rotating all of them, replacing appliance certificates, and reviewing vCenter permissions for accounts you did not create.

Detection Measures 🔍

QUIRSO published a YARA rule for the reverse_ssh client in their QTRDetectionContent repository. Run it against a copy of the appliance filesystem — a snapshot mounted on an analysis host — rather than installing scanning tooling onto a production vCenter:

# On an analysis host, against a mounted copy/snapshot of the appliance.
# -r recurses into directories, -s prints the matching strings for triage.
yara -r -s 2026-08-10_reverse_ssh_generic.yar /mnt/vcsa-snapshot

The rule keys on Go build metadata plus stable github.com/NHAS/reverse_ssh package paths and client strings. QUIRSO’s own caveat is important and worth repeating: this is a dual-use tool signature, so a match identifies reverse_ssh code, not automatically malicious activity. On a vCenter appliance, however, there is no benign explanation.

A portable Sigma rule for the persistence behaviour, if you forward appliance telemetry to a SIEM:

title: Suspicious Cron or Reverse Shell Persistence on VMware vCenter Appliance
status: experimental
description: >
  Detects persistence patterns consistent with the CVE-2026-59310 exploitation
  campaign reported by QUIRSO: a cron job installed on the vCenter Server
  Appliance that launches the open-source reverse_ssh client for outbound C2.
references:
  - https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/38017
  - https://github.com/QUIRSO/QTRDetectionContent
logsource:
  product: linux
  service: syslog
detection:
  keywords_cron:
    - 'CRON'
    - 'crontab'
  keywords_tooling:
    - 'reverse_ssh'
    - 'ssh -R'
    - '/tmp/'
  condition: keywords_cron and keywords_tooling
falsepositives:
  - Legitimate administrator-authored cron jobs on the appliance (should be none)
  - Authorized penetration testing using reverse_ssh
level: high

Additional hunting:

Review appliance logs from July 29 onward. vCenter logs live under /var/log/vmware/; list them by modification time (ls -lt /var/log/vmware/) and pay particular attention to the syslog service’s own directory and to anything that stops or restarts unexpectedly.
Retrospective netflow analysis. Query your flow data for outbound connections originating from vCenter management IPs to destinations outside your known-good set, back to August 3, 2026 at the latest — QUIRSO’s first observed victim contact.
Check inbound flows to ports 514 and 1514 on vCenter from any source outside your ESX estate. Your hosts should be the only things sending syslog to vCenter.
Audit vCenter accounts and permissions for additions or role changes you cannot attribute to a change ticket.
Diff the ESX host configuration against a known-good baseline. Note that CVE-2026-41709 in the same advisory is an insufficient logging flaw — administrator actions on ESX that were not recorded. Do not assume ESX audit logs are complete for this period.
Treat unpatched, internet-facing vCenter as compromised until proven otherwise. That is the researchers’ recommendation, not ours, and given a 72-hour saturation curve it is the correct default.

Long-term Security Improvements

Put the hypervisor management plane on an isolated network. vCenter, ESX management interfaces, and the syslog collector belong on a dedicated out-of-band administration network reachable only through a hardened jump host. This CVE has no workaround — but an attacker who cannot route packets to port 514 cannot exploit it either.
Inventory unauthenticated listeners on your appliances. Every management appliance in your estate runs services you did not consciously enable. Enumerate them (ss -tlnp and the vendor’s own service tooling), decide which need to be reachable and from where, and filter the rest at the network layer.
Treat log collectors as attack surface. A syslog server is a parser fed by untrusted input from the network. It deserves the same scrutiny as any other internet-facing parser, and it should not share an appliance with the credentials for your entire estate if you can avoid it.
Give management infrastructure the fastest patch SLA you have. The industry habit is to patch the workload and defer the manager. This campaign saturated in 72 hours from a standing start of five days post-disclosure. A monthly maintenance window is not a defence against that.
Build your prioritization on more than KEV. CVE-2026-59310 is being exploited globally and is not in KEV. KEV is a valuable signal and a lagging one; a CVSS 9.8 unauthenticated RCE on your hypervisor manager warrants emergency treatment on the merits.
Retire out-of-support versions. vSphere 7.0 is affected and past End of General Support. “We have an extended support contract” is a plan; “we are still on 7.0 and hope for the best” is not.
Rehearse hypervisor compromise in tabletop exercises. Ask the uncomfortable question explicitly: if vCenter is untrusted, how do we restore? Where are the backups, are they reachable from vCenter, and can we rebuild without it? Most organizations discover the answer during the incident.
Monitor egress from management appliances. Outbound C2 from a vCenter is one of the highest-signal, lowest-noise detections available, precisely because a healthy appliance talks to so few things.

🎯 Why is this Critical?

Unauthenticated code execution on the system that controls everything else. vCenter compromise is not lateral movement — it is arriving at the destination.
There is no workaround. Broadcom says so in one word. Segmentation helps; only the patch fixes it.
It is being exploited right now, at scale. 361 compromised hosts across 47 countries, with 95% of them appearing inside a single 72-hour window.
Germany heads the list of affected countries. For our clients and readers, this is not a distant statistic.
The exploitation began five days after the patch. The window between “advisory published” and “campaign underway” was less than a week — shorter than many organizations’ change-approval process.
The official signals under-rate it. No CISA KEV listing, and a vendor Q&A that still reads “no information to suggest exploitation in the wild.” A prioritization pipeline driven by those inputs will file this behind things that matter less.
Persistence outlives the patch. A cron job and a reverse_ssh binary do not care that you upgraded. Patching without hunting leaves the attacker in place with a newly hardened appliance.
The advisory bundles a VM escape. CVE-2026-47876 in the same VMSA lets an in-guest administrator execute code on the ESX host. Anyone treating this as “just the vCenter one” is leaving the hypervisor half of the problem unpatched.

🚀 Timeline and Disclosure

2025-10-02 — VMware vSphere 7.0 reaches End of General Support, establishing the context for why 7.0 users need an extended support contract to obtain a fix.
2026-07-29 — Broadcom publishes VMSA-2026-0006, covering five CVEs including CVE-2026-59310 (CVSS 9.8) and CVE-2026-59309 (CVSS 9.8). vCenter 8.0 U3k (build 25600417), 9.0.2.0100 and 9.1.0.0300 are released. No workarounds are available for any of the five. Credit for both vCenter issues goes to Phil Brass and Matt South of Atredis Partners.
2026-07-30 — The NVD record for CVE-2026-59310 is published, carrying CVSS 3.1 9.8 and CWE-22.
2026-08-03 — VMSA-2026-0006.1 is published, adding vSphere 8.0 Update 2 patches (8.0 U2f). On the same day, QUIRSO observes the first compromised systems contacting attacker infrastructure — five days after disclosure.
2026-08-04 — 151 new victim IPs appear in a single day.
2026-08-05 — 343 of the eventual 361 victim IPs (~95%) have been observed. The campaign has effectively saturated.
2026-08-07 — Victim count reaches 361 IPs across 47 countries, with Germany, the US, Turkey, Iran and France accounting for 185 of them.
2026-08-10 — QUIRSO publishes a generic YARA rule for the NHAS reverse_ssh client to their public detection-content repository.
2026-08-12 — QUIRSO publishes its campaign analysis. Coverage follows across BleepingComputer, The Hacker News, SecurityWeek, Dark Reading and Infosecurity Magazine.
2026-08-14 — The NVD record is last modified.
2026-08-17 — CVE-2026-59310 is still absent from the CISA KEV catalog (verified against catalog version 2026.08.17, 1,666 entries), and Broadcom’s advisory Q&A still states no known in-the-wild exploitation.

🔗 Resources and References

CVE: CVE-2026-59310
NVD: NVD — CVE-2026-59310
Vendor advisory: VMSA-2026-0006.1 — Broadcom Support
Vendor Q&A supplement: VMSA-2026-0006 Questions & Answers — vmware/vcf-security-and-compliance-guidelines
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory
CISA KEV Catalog: Known Exploited Vulnerabilities — not listed as of catalog version 2026.08.17
Detection content: QUIRSO QTRDetectionContent — reverse_ssh YARA rule
Related: CVE-2026-59309 (vCenter authentication bypass, CVSS 9.8) and CVE-2026-47876 (ESX VMXNET3 VM escape, CVSS 9.3) — same advisory

💼 SEKurity Supports You

CVE-2026-59310 is a clean illustration of a pattern we see repeatedly in assessments: the most dangerous exposure in an environment is rarely the application everyone worries about. It is the forgotten service on the management appliance — a log collector, an agent listener, a legacy API — that accepts unauthenticated input from a network segment nobody has audited in years. Nobody deploys a syslog collector thinking about it as an attack surface, and yet here it is, sitting on the appliance that holds the keys to every virtual machine in the estate. The campaign around this CVE also demonstrates how compressed the timelines have become: five days from vendor advisory to active exploitation, and 72 hours from there to global saturation. That is faster than most organizations can convene a change advisory board. We help clients close exactly this gap — mapping which management planes are genuinely reachable and from which networks, enumerating the unauthenticated listeners on infrastructure appliances that inventory tools routinely miss, testing whether a foothold on the virtualization layer can be converted into estate-wide control in practice, and validating that outbound C2 from a management appliance would actually generate an alert rather than a log line nobody reads. Our perimeter and infrastructure penetration testing treats hypervisor management as a primary objective, because that is how real adversaries treat it.

Our Services

Penetration Testing: Web applications, mobile apps (Android & iOS), SAP systems, Active Directory
Large-Scale Attacks: Perimeter testing, IT infrastructure testing, Red Team engagements
Security Awareness: Phishing campaigns, hacking demonstrations

Act now — before attackers do.

Contact:

🌐 Website: www.sekurity.de

📧 Inquiries: www.sekurity.de/kontakt

📱 LinkedIn: SEKurity GmbH

Your SEKurity Team — Your Trusted Adversaries

The security of your virtualization infrastructure is our drive.

InSEKurity of the Week (CW33/2026): VMware vCenter Syslog Directory Traversal (CVE-2026-59310)