ESXiArgs: a 2-year-old ESXi bug, then a global ransomware wave

VMware shipped a fix for CVE-2021-21974 in February 2021. Two years later, in early February 2023, the ESXiArgs ransomware campaign used that exact bug to hit more than 3,000 VMware ESXi hosts worldwide in the space of a few days — not because the vulnerability was new, but because thousands of hypervisors were still running unpatched, with the vulnerable service reachable from the open internet (Rapid7). It’s the same lesson as most edge-appliance breaches — the gap between “a patch exists” and “the patch got applied” is where the damage happens — but ESXiArgs is a clean case study because the vulnerable component wasn’t even something most admins knew they were running.

Root cause

CVE-2021-21974 is a heap-overflow in ESXi’s OpenSLP service — an implementation of the Service Location Protocol, used for service discovery on a local network, that ships enabled by default on ESXi 6.5, 6.7, and 7.0. A crafted request to OpenSLP’s directory-agent advertisement handling overflows a heap buffer and gets remote code execution, rated CVSSv3 8.8. VMware’s advisory is explicit that exploitation only requires network access to port 427 — no authentication against the hypervisor at all (VMware/Broadcom advisory). The fix shipped in February 2021 as a standard ESXi patch (ESXi70U1c-17325551 for 7.0, ESXi670-202102401-SG for 6.7, ESXi650-202102101-SG for 6.5).

What turned a two-year-old, already-patched bug into a mass-casualty event was exposure, not novelty. OpenSLP is meant for LAN-local service discovery — it has no legitimate reason to be reachable from the public internet — but a large population of ESXi hosts had their management network directly internet-facing anyway, whether through misconfigured firewalls, hosting-provider defaults, or hypervisors never intended to be internet-adjacent in the first place. Attackers didn’t need to find a zero-day; they needed to scan for port 427 and check the build number.

Blast radius

The campaign broke out around February 3, 2023, hitting an estimated 3,200-plus servers in its first wave across France, the US, Germany, Canada, and dozens of other countries, with French and Italian hosting customers especially hard hit — OVHcloud alone accounted for a large share of early victims (Rapid7). Because the ransomware encrypted VM configuration files at the hypervisor layer rather than inside any individual guest OS, every VM on a compromised host went down at once regardless of what that VM was running or how well-patched its own OS was — the compromise happened one layer below anything the guest could see or defend.

The first version of ESXiArgs had a real weakness: it encrypted files in size-based chunks and skipped large stretches of big files entirely, which meant the flat files backing VM virtual disks were often only partially encrypted. Security researchers showed that VM metadata could be reconstructed from the untouched portions, and CISA turned that technique into a public ESXiArgs-Recover script, released February 7 with IC3 recovery guidance alongside it. The attackers responded within days: a second wave switched to alternating 1MB encrypted/1MB skipped blocks instead of skipping whole large regions, encrypting roughly half of every large file — enough to break the CISA script’s recovery technique for victims hit after the update (ThreatDown). That back-and-forth is a reminder that a public recovery trick against a specific ransomware build is a temporary reprieve, not a durable fix — the attacker can patch their encryptor faster than most fleets patch their hypervisors.

Remediation

Patch first: if you’re running ESXi 7.0, 6.7, or 6.5 and haven’t applied the builds referenced in VMware’s advisory, that’s the baseline fix, full stop. But the more durable lesson from this campaign is to disable OpenSLP entirely if you don’t use it, which most environments don’t — esxcli network firewall ruleset set --ruleset-id slpd --enabled false plus chkconfig slpd off from the ESXi shell (or SSH) stops the service from listening at all, independent of patch level, and VMware has recommended disabling it by default in its security configuration guidance ever since.

Beyond that one service, treat the ESXi management interface the way you’d treat a domain controller, not a web server: it should never be directly reachable from the internet. Put it behind a VPN or bastion, restrict the management VMkernel port group with host firewall rules to known admin subnets, and enable lockdown mode so the hypervisor only accepts commands through vCenter rather than direct host-level API or SSH access. For backups, keep them off the same storage the hypervisor can reach and encrypt — offline or immutable backups are what actually got ESXiArgs victims back online when the recovery script didn’t apply, since a ransomware payload with hypervisor-level access can just as easily reach any backup target sitting on the same network.

The bigger lesson

ESXiArgs didn’t need a novel exploit, a supply-chain foothold, or social engineering — it needed a rarely-audited legacy service, left on by default, exposed to a network it should never have touched, with a two-year-old patch nobody had gotten around to applying. That combination is common precisely because hypervisor management planes don’t get the same patch-Tuesday attention as the workloads running on top of them; teams that are diligent about OS and application patching inside their VMs can still leave the layer underneath all of them on a build from two major security releases ago. The fix isn’t just “patch ESXi” — it’s putting the hypervisor itself, and everything it exposes by default, inside the same asset-inventory and exposure-scan process as anything else with a network interface, because a bug at that layer doesn’t compromise one workload, it compromises every workload the host happens to be running.