No Password Required. Attackers Are Already Inside VMware vCenter. Is Your Virtual Infrastructure a Target?

Here's a sentence that should get every business leader's attention: attackers are currently breaking into VMware vCenter servers without a password.

Not by guessing passwords. Not by phishing an employee. Just by pointing an exploit at your virtualization management platform and walking in.

This isn't theoretical. As of this week, incident responders have confirmed 361 victim organizations across 47 countries actively compromised through a critical vulnerability in VMware vCenter — the software that controls most organizations' virtual server infrastructure. The exploitation wave started August 3, 2026, just five days after Broadcom publicly disclosed the flaw.

What Is VMware vCenter and Why Should You Care?

If your organization runs a data center — even a small one — there's a good chance VMware vCenter is involved. vCenter is the management platform that controls virtual machines (VMs): the software-defined servers that run your business applications, databases, and often your backups.

Think of vCenter as the master control panel for your entire virtualized infrastructure. Whoever controls vCenter controls everything running on it. That means your email server, your ERP system, your finance applications, your file shares — all of it.

This is exactly why attackers are targeting it.

What Just Happened

On July 29, 2026, Broadcom (which owns VMware) published security advisory VMSA-2026-0006, disclosing two critical vulnerabilities in vCenter Server:

CVE-2026-59309 — Authentication Bypass (CVSS 9.8 Critical). A flaw in VMware's Directory Service, the identity backbone of vCenter. An attacker with network access to vCenter can bypass authentication entirely — no username, no password, no credentials of any kind — and gain unauthorized control of the management plane.

CVE-2026-59310 — Directory Traversal with Remote Code Execution (CVSS 9.8 Critical). A flaw in vCenter's Syslog server that allows an attacker to execute arbitrary code on the system. Combined with CVE-2026-59309, an attacker can walk in without credentials and then run whatever commands they want.

Broadcom's advisory contained one particularly alarming line: there are no workarounds. Patching is the only fix.

Five days after public disclosure, attackers were already exploiting CVE-2026-59310 in the wild. By August 12, incident responders had identified 361 unique victim IP addresses across 47 countries — Germany, the United States, Turkey, Iran, and France among the most heavily targeted.

The observed attack chain: gain access via the authentication bypass or code execution flaw, install a malicious cron job for persistence, deploy reverse SSH tunneling software to maintain covert access that survives reboots and firewall rules. Attackers were setting up shop to stay.

The Five-Day Window Problem

Let's do the math. Broadcom released patches July 29. Exploitation in the wild was confirmed by August 3 — a five-day window between "patch released" and "attackers already inside."

This is the new reality of enterprise software security in 2026. Vulnerability researchers and criminal groups are watching the same advisories you are. The moment a critical patch drops, reverse engineering begins. Proof-of-concept exploits get written, tested, and deployed — often in less than a week.

The 2026 Verizon Data Breach Investigations Report found the median enterprise patch cycle for critical vulnerabilities runs around 44 days. Attackers need 5. That gap — 5 days to exploit, 44 days to patch — is where breaches live.

If your IT team received the July 29 Broadcom advisory and put vCenter patching on a normal change management schedule, you may already have a problem.

Who Is at Risk?

Any organization running VMware vCenter Server versions 8.0, 9.0.x, or 9.1.x that has not applied the following patches:

- vCenter Server 8.0 → upgrade to 8.0 Update 3k (build 25600417) - vCenter Server 9.0.x → upgrade to 9.0.2.0100 - vCenter Server 9.1.x → upgrade to 9.1.0.0300

This includes organizations running VMware Cloud Foundation (version 5.x and earlier), VMware vSphere Foundation, VMware Telco Cloud Platform, and VMware Telco Cloud Infrastructure.

VMware Cloud-delivered services are not affected — the risk is entirely with on-premises and self-managed vCenter deployments.

If your organization relies on a managed service provider, colocation facility, or IT vendor to maintain your virtualization environment, the question isn't whether you patched it — it's whether they did.

What Attackers Do Once They're In

Control of vCenter means control of the virtual machines it manages. In practice, that means attackers can:

- Access any VM's console directly — including servers running your databases, your finance systems, your HR platforms - Snapshot and exfiltrate entire virtual machines (complete copies of running servers with all their data) - Deploy ransomware at the hypervisor level — encrypting storage that underlies your entire virtual environment simultaneously - Create persistent backdoor access that survives credential resets, VM reboots, and even reimaging individual servers - Pivot to connected backup systems, often configured with elevated trust from virtualization infrastructure

The cron job persistence technique observed in active exploits deserves special attention: attackers are installing automated jobs that run on the vCenter appliance itself, below the visibility of most endpoint detection tools. This kind of persistence is designed to survive incident response — including password changes and server restarts.

Three Questions Every Business Leader Should Ask Today

1. Do we know our vCenter version and patch status right now?

This is a basic inventory question, but it's one many organizations can't answer quickly. If your answer is "I'll have to check with IT," that's the first problem to solve. Know your virtualization footprint, know your patch status, and establish a process for tracking both.

2. Who owns patching our VMware environment — and do they know about this?

If a third-party managed service provider handles your infrastructure, call them today. Don't assume they're on top of it. Ask for written confirmation of your vCenter version and when the VMSA-2026-0006 patches were or will be applied. If they're using a normal change management cycle, push for emergency treatment on this one.

3. Do we have visibility into anomalous behavior in our virtualization layer?

Most organizations monitor their servers and endpoints reasonably well. Far fewer have behavioral monitoring on their hypervisor and virtualization management plane. Ask whether your security monitoring covers vCenter audit logs, unexpected VM snapshot activity, new cron jobs on management appliances, and outbound SSH connections from infrastructure that shouldn't be making them.

The Bottom Line

Virtual infrastructure used to be considered a relatively safe layer — it was internal, complex to access, and not the obvious target that public-facing web servers were. That calculus has shifted decisively.

Attackers understand that compromising the virtualization layer gives them keys to the kingdom: every server, every application, every data store managed by that hypervisor is reachable. And with 361 confirmed victims in the first two weeks of active exploitation, this isn't a theoretical concern — it's an active campaign.

If your organization runs VMware vCenter and hasn't patched VMSA-2026-0006, that is your priority this week. Not next sprint. Not next change window. This week.

TrustPoint Cyber helps organizations assess their virtualization security posture, verify patch status across managed and vendor-hosted environments, and build monitoring that covers the layers traditional tools miss. If you're not sure where you stand, let's find out before an attacker does.