The Admin Account You Never Created: How CVE-2026-59310 Turned vpxuser Into a Master Key

There is an account in your VMware estate that you did not create, whose password you have never typed, that holds full administrative rights on every ESXi host you own, and that lockdown mode deliberately does not apply to.

It is called vpxuser. vCenter creates one per managed host so it can do its job. It rotates itself on a schedule you probably left at the default. It does not appear in your privileged access review, because your PAM tool has no idea it exists. And in August 2026, a suspected China-nexus actor built an entire campaign around collecting it.

The CVE gets the headlines. CVE-2026-59310, CVSS 9.8, a directory traversal in the vCenter Syslog server that Broadcom disclosed on July 29 in VMSA-2026-0006. Five days later, on August 3, the first victims started calling home to attacker infrastructure. The German incident response firm QUIRSO mapped the result: 361 unique compromised IP addresses across 47 countries, with Germany, the United States, Turkey, Iran and France accounting for 185 of them. By August 5, roughly 343 of those 361 were already in the set. Two days of work, ninety-five percent of the campaign.

CISA added it to the Known Exploited Vulnerabilities catalog on August 18 and gave federal civilian agencies until August 21 under BOD 26-04. That is a three-day remediation window on a system most organisations schedule maintenance for a month in advance.

But patch timing is the boring part of this story. What the attacker did after root is the interesting part, and almost none of it required another exploit.

The bug is a delivery mechanism. The account is the payload.

The traversal itself is unglamorous. Malformed input to the syslog server writes a file outside its intended directory, and the directory the attacker picked was /etc/cron.d/. QUIRSO documented dropped files named zz-poc59310 and zz-poc59310-syslog.log, which tells you something about the operator's tradecraft: they kept the proof-of-concept filename. Commands then ran as root on a schedule. No exploit chain, no privilege escalation, no memory corruption gymnastics. A cron file.

From there the intrusion reads like a checklist written by someone who has administered vSphere for a living:

Persistence went in three layers deep. A system service named sys-9436d8.service to restart the backdoor. Fake VMware-styled cron tasks that re-enabled SSH whenever it got turned off. Attacker keys appended to root's authorized_keys. A JSP web shell at vmware-perf-update.jsp dropped into the Perfcharts directory, which is a legitimate vCenter web application, so it sits among files that belong there. Staging went to /tmp/.x/ and a backdoor directory under /root/.local/share/. The reverse_ssh framework handled remote access, meaning every connection was outbound. If your egress policy from the management network is "allow", and it usually is, you never saw it.

Then a sudoers file at /etc/sudoers.d/vmware-perf granted the perfcharts service account passwordless root. That is the move I want defenders to sit with. The attacker already had root. They spent effort converting root into a legitimate-looking identity with root, attached to a service that is supposed to exist.

And then the shopping trip. LDAP utilities against the local directory service. Temp files named .ldappw and .sso_domain. New accounts created: adminuser in vSphere SSO and as an ESXi local admin, vcadmin via a Base64-encoded Python script, and vcenter_admin, which QUIRSO suggests may correlate with activity against CVE-2026-59309, the CVSS 9.8 authentication bypass in vmdir disclosed in the same advisory.

And vpxuser. Harvested systematically, because vpxuser is the one credential that unlocks every ESXi host under that vCenter without touching vCenter again.

Why rotation does not save you here

Here is the detail people get wrong about vpxuser, and I have had this argument in enough rooms to know it lands badly the first time.

vCenter rotates the vpxuser password automatically. The default is every 30 days, governed by the VirtualCenter.VimPasswordExpirationLoop and VimPasswordExpirationInDays settings. Because rotation is automatic, vpxuser gets mentally filed under "handled" and drops out of credential hygiene conversations entirely.

Rotation is a control against credential ageing. It does nothing against an attacker who owns the machine that performs the rotation. When you are root on the vCenter Server Appliance, you are inside the system of record for that password. You do not need to crack it or wait it out. You read it, and when it changes, you read the new one, because your cron job and your systemd service and your web shell are all still there.

This is the same structural failure I wrote about in the service account lateral movement blind spot: credentials that no human ever handles get treated as though no human ever will. vpxuser is worse than a typical service account, though, because of the lockdown mode exemption. Lockdown mode is the control most organisations point to when asked how ESXi hosts are protected from direct access. It restricts host operations to vCenter. vpxuser is how vCenter performs those operations, so vpxuser is exempt by design. Your hardening control and your compromised credential are the same mechanism viewed from two sides.

"No matching authentication events"

The single line in QUIRSO's analysis that should change how you write detections is this one: root-level command execution occurred with no corresponding authentication events.

Think about what that does to a SIEM. Every correlation rule you have for privilege abuse starts from an authentication artefact. A logon event, a session token, a sudo invocation tied to a user, an API call with a principal attached. The traversal bypasses that entirely, because the syslog server writing a file is not an authentication decision. It is I/O. There is no principal to log because nothing authenticated.

Then the attacker starts creating accounts that do authenticate, and by that point the events look normal. adminuser logging into an ESXi host is a valid SSO principal doing a valid thing. perfcharts running commands as root has a sudoers entry authorising it. vpxuser connecting to every host in the cluster is what vpxuser does all day.

The visibility problem compounds at the hypervisor layer. ESXi does not run your EDR agent. It cannot, in most cases, because these tools are built for guest operating systems and vendors do not ship a hypervisor build. Mandiant's Alex Marvi has put it bluntly: most organisations run no malware detection on their ESXi hypervisors at all. So the layer holding every virtual machine you own is monitored by whatever the platform vendor decided to log, and the box aggregating those logs is frequently vCenter itself, which is the box that just got rooted.

That combination explains the last stage. Local admin accounts created on ESXi hosts. Ransomware and a helper script (run.sh) copied in through the vSphere datastore browser, which is a management feature, not an exploit. The high-availability agent removed so hosts would not try to restart what was about to be killed. VMs stopped. Then a Babuk-derived encryptor, appending .babyk, encrypting only the first 512 MB of large VMDK files.

That 512 MB choice is an efficiency decision, and it tells you the operator understands the target. You do not need to encrypt a two-terabyte disk to destroy it. You need the partition table, the boot sector and the start of the filesystem. Partial encryption of a whole datastore finishes in minutes. Full encryption would take a night, and a night is long enough for someone to notice.

Mandiant's M-Trends 2026 puts median dwell time at 14 days globally, and nine days where the organisation detected the intrusion itself. Hypervisor-focused intrusions do not respect that average. Mandiant also reported hypervisor ransomware jumping from 3% of cases in the first half of 2025 to 25% in the second half. When CrowdStrike measured breakout time at 27 seconds, the point was that detection budgets built around days are already fiction. At the hypervisor layer they are worse than fiction, because the detection surface is not slow. It is largely absent.

Where deception has an unfair advantage

I am generally sceptical of security tooling that claims to solve a visibility problem by adding more telemetry to a place that already generates too much. This is not that situation, and the reason is specific to how this attack chain works.

Look at the sequence again. The attacker got root without authenticating, so signature-based and behaviour-based detection had nothing to anchor to. Then they queried the local directory service over LDAP to enumerate what identities exist.

That enumeration step is the seam. Everything before it is invisible. Everything after it is credential use that looks legitimate. But the enumeration itself is an attacker reading a list, and a list is something you control the contents of.

A decoy vSphere SSO principal sitting in vmdir gets returned in that ldapsearch output alongside the real ones. It has no consumer. No automation job references it, no cluster operation depends on it, no admin has it in a password manager. The only way it ever gets used is if somebody read it out of a directory dump and tried it, which is exactly one thing and never a false positive. That is a different quality of signal from "this service account authenticated from an unusual source", which is the sort of alert that gets tuned into silence within a quarter. It is the same property that makes honeytokens catch insiders that DLP and UEBA cannot: the decoy has no legitimate use, so use is the whole detection.

The management network offers a second seam. This operator did discovery before deploying ransomware, because they had to know which hosts existed and which datastores were worth touching. Decoy services on the management VLAN, which is what MineField exists to place, are contacted only by something scanning. Your monitoring platform knows what it polls. Nothing else on a well-run management segment goes looking.

Neither of these prevents CVE-2026-59310. Patching prevents CVE-2026-59310. What they change is the interval between "attacker has root on vCenter" and "someone knows", and in this campaign that interval was the difference between a rebuilt appliance and an encrypted datacentre. It is the same argument I made about FortiGate credentials that survive the patch: fixing the vulnerability does not revoke what was taken through it.

The order I would work in

If you run vSphere, patch first: 9.1.0.0300, 9.0.2.0100, 8.0 U3k or 8.0 U2f. There is no workaround. Then get the management interface off anything internet-facing, which is how most of those 361 hosts were reachable in the first place.

After that, treat this as a credential incident rather than a patching incident, because that is what it is. Look at /etc/cron.d/, /etc/sudoers.d/, the Perfcharts application directory and root's authorized_keys for the artefacts above. Enumerate every vSphere SSO account and every ESXi local account and reconcile against a list you can justify, paying attention to anything created since late July. Rotate vpxuser across the estate, and understand that rotation only means something once you are confident nothing is still resident on the appliance. Then look at outbound connections from the management segment, because reverse_ssh does not need an inbound rule.

The uncomfortable conclusion is that your hypervisor management plane is an identity provider. It issues credentials, it holds a directory, it federates to your hosts, and it exempts its own service account from the control you tell auditors protects those hosts. Almost nobody governs it as an identity provider, and this campaign is what that gap costs. If you want to see what a decoy identity looks like sitting in a directory that attackers actually enumerate, book a walkthrough with our team and we will build one against your environment rather than a slide.