VMSA-2026-0006: Is Your VCF Fleet Patched? (vCenter Exploited, Now Used by Ransomware)

July 20, 2026

On July 29, 2026 Broadcom released VMSA-2026-0006, a critical security advisory for vCenter and ESX. Two months later I still see environments that are not patched, and the situation is a lot worse now than it was on release day:

August 3: CVE-2026-59310 was exploited in the wild, five days after the advisory came out.
August 18: CISA added CVE-2026-59310 to its Known Exploited Vulnerabilities (KEV) catalog.
Mid-September: CISA flagged that ransomware gangs are now using the flaw.

If your vCenter isn’t on a fixed build yet, stop reading and plan your maintenance window. After that, come back and I’ll show you how to check your versions, how to patch inside VCF, and what to look for in case someone got there first.

What is in VMSA-2026-0006?

The advisory covers five CVEs. The first three are the ones that matter most:

CVE	CVSS	Component	What it does
CVE-2026-59309	9.8	vCenter (VMware Directory Service)	Authentication bypass: anyone with network access to vCenter can get in without credentials
CVE-2026-59310	9.8	vCenter (Syslog server)	Directory traversal leading to remote code execution, actively exploited
CVE-2026-47876	9.3	ESX (VMXNET3)	Out-of-bounds write: an admin inside a VM can run code on the host (VM escape)
CVE-2026-41703	up to 7.6	ESX, Workstation, Fusion	Out-of-bounds read: information disclosure or denial of service
CVE-2026-41709	2.7	ESX	Insufficient logging: an admin can perform operations without them being logged

There is no workaround for any of these CVEs. The only fix is to patch.

The two vCenter bugs together are about as bad as it gets: no authentication needed, remote code execution, on the system that controls your whole environment. Yes, vCenter should sit on an internal management network, but plenty of attackers are already inside the network when they start looking for vCenter.

Fixed versions

This is the version table you need. It’s based on the Broadcom response matrix (advisory revision .2, updated August 19, 2026):

Product	Running	Fixed in
VCF / VVF vCenter	9.1.x	9.1.0.0300
VCF / VVF vCenter	9.0.x	9.0.2.0100
VCF / VVF ESX	9.1.x	9.1.0.0200 (ESXi-9.1.0.0200-25557999)
VCF / VVF ESX	9.0.x	9.0.2.0100 (ESXi-9.0.2.0100-25595025)
vCenter	8.0	8.0 U3k (or express patch 8.0 U2f)
ESX	8.0	8.0 U3k (U2f express patch also available)
VCF 5.x	vCenter / ESX 8.0	Async patch to 8.0 U3k
vCenter / ESX	7.0	See the 7.0 guidance added in revision .2 / contact Broadcom Support

Tip: Always check the latest revision of the advisory before you patch. Broadcom has already updated it twice.

Step 1: Check what you are running

vCenter

vpxd -v

You can also check the version in the vSphere Client (Help > About) or in the VAMI at https://:5480.

ESX hosts

On a host:

esxcli system version get

The whole fleet with PowerCLI

If you have more than a handful of hosts, PowerCLI is faster:

Connect-VIServer -Server vcenter01.lab.local

# vCenter version and build
$global:DefaultVIServer | Select-Object Name, Version, Build

# All ESX hosts with version and build
Get-VMHost | Select-Object Name, Parent, Version, Build | Sort-Object Build | Format-Table -AutoSize

Compare the builds against the table above. Anything older needs to be patched.

Step 2: Patch the VCF 9.x way

In VCF 9 you don’t patch vCenter or ESX by hand through VAMI or vLCM. If you do, you create exactly the kind of drift I wrote about in How to Fix SDDC Manager Upgrade Failures Caused by Deployment Drift. Use the lifecycle tooling instead.

2.1 Get the binaries

In VCF Operations, go to Fleet Management > Lifecycle and make sure the patch binaries are available. You can do this with:

an online depot connected to VCF Operations,
an offline depot built with the VCF Download Tool (for dark sites), or
a direct download without a depot.

2.2 Take backups

Before you touch anything, make sure you have a recent file-based backup of vCenter, SDDC Manager and NSX. It takes five minutes and can save your day.

2.3 Run the precheck

Browse to the workload domain, open Updates and run the precheck. Fix every error before you continue. A failed patch halfway through is worse than a patch that starts an hour later.

Gotcha: You cannot use the patch planner while an upgrade plan exists for that domain. If you started planning a 9.1 upgrade earlier, cancel that upgrade plan first, then create the patching plan.

2.4 Plan and apply the patch

Click Plan Patching.
Select the components (vCenter and ESX) and the target versions from the table above.
Validate the selection. The UI also shows whether vCenter supports Reduced Downtime Upgrade (RDU), which keeps downtime during the vCenter patch short.
Review the update sequence and confirm.
Run each update with Update Now or Schedule Update, following the order the planner shows.

Start with the management domain. Its vCenter manages everything else, and attackers will go for it first.

Still on VCF 5.x?

For VCF 5.x, the fix is an async patch to vCenter/ESX 8.0 U3k. Follow Broadcom’s async patch guidance for your exact 5.x version so SDDC Manager stays aware of the new builds. Don’t patch outside SDDC Manager, or the drift will come back to bite you during your next upgrade.

Step 3: Check for signs of compromise

Patching closes the hole, but it doesn’t remove an attacker who is already in. In the attacks seen so far, attackers exploited CVE-2026-59310 and then installed cron jobs that start reverse_ssh. That tool opens an outbound SSH tunnel to the attacker’s infrastructure, which gets around firewalls that only block inbound traffic.

If your vCenter ran an unpatched build any time after July 29, check at least the following on the appliance:

# Look for unexpected scheduled jobs
crontab -l
ls -la /etc/cron.d/ /etc/cron.hourly/ /etc/cron.daily/
cat /etc/crontab

# Look for unexpected outbound connections
ss -tnp | grep ESTAB

Also:

Search for reverse_ssh or any binary you don’t recognise.
Check your firewall logs for outbound connections from vCenter to unknown hosts.
Compare the accounts in VMware Directory Service (vmdir) with your list of real admins.
Review the vCenter and syslog history back to July 29 for path traversal patterns.

If you find anything suspicious, don’t just patch and move on. Treat it as an incident: isolate the appliance, preserve logs, and bring in your security team. Remember that vCenter holds the keys to every host and VM it manages.

Step 4: Reduce the attack surface

After patching, this is a good moment to tighten things up:

Only allow vCenter access from dedicated management or jump hosts.
Block outbound internet traffic from vCenter, SDDC Manager and ESX, except to the destinations you need, such as your depot and proxy.
Forward vCenter and ESX logs to an external syslog/SIEM so an attacker can’t quietly wipe them.
Add VMSA notifications to your team’s alerts. With five days between disclosure and exploitation, waiting for the next maintenance window isn’t safe anymore.

Conclusion

VMSA-2026-0006 isn’t a patch-when-you-have-time advisory. CVE-2026-59310 went from disclosure to active exploitation in five days, and it’s now in the KEV catalog and being used by ransomware gangs. The fix is simple: check your builds, patch through VCF Operations Fleet Management (management domain first), and check for the reverse_ssh persistence method.

Have you run into issues patching to 9.1.0.0300 or 9.0.2.0100? Let me know in the comments. I’m curious which prechecks give you trouble.