vCenter Server is the control plane for VMware virtualization, the console from which administrators manage entire fleets of ESXi hosts and the virtual machines running on them. Compromising vCenter often means compromising everything it manages, which is why CVE-2021-21985 was treated as an emergency. It is a remote code execution vulnerability in the vSphere Client (HTML5) component of vCenter Server, caused by a lack of input validation in the vSAN Health Check plugin, and VMware assigned it a CVSS 3.1 base score of 9.8 (Critical). The plugin is enabled by default on every vCenter Server, whether or not you use vSAN, so essentially all deployments were exposed.
Timeline and impact
VMware published advisory VMSA-2021-0010 on May 25, 2021, covering CVE-2021-21985 alongside a related authentication-mechanism flaw, CVE-2021-21986, in several vCenter plugins. VMware's messaging was unusually direct, urging administrators to patch immediately and framing the risk in terms of the "critical" nature of vCenter to an organization's infrastructure.
The urgency was warranted. A working proof-of-concept was published on June 3, 2021, roughly a week after disclosure, and mass internet scanning for exposed vCenter servers followed almost immediately. Because a compromised vCenter grants control over the hypervisor layer, this class of flaw is prized by ransomware operators, who use it to encrypt VMs at the datastore level and cripple entire environments at once. CVE-2021-21985 was added to CISA's Known Exploited Vulnerabilities catalog.
Root cause
The vSphere Client is extended by plugins, and one of them, the vSAN Health Check plugin, exposes a set of HTTP endpoints. The vulnerability is that those endpoints were reachable without proper authentication and did not adequately validate the input they received. An unauthenticated attacker with network access to the vCenter management interface on port 443 could reach the plugin's endpoints and supply input that the plugin processed unsafely, resulting in command execution.
The important architectural detail is the default-enabled nature of the plugin. Administrators frequently assumed that because they did not run vSAN, its health-check component was inert, but the plugin was loaded and its endpoints were live regardless. The commands executed ran with the privileges of the underlying vCenter service, which are effectively unrestricted on the host operating system, so a single reachable endpoint became full control of the appliance. VMware's related CVE-2021-21986 addressed the broader authentication-mechanism weakness across plugins, which is why the fix and mitigation guidance covered plugin access as a category, not just this one endpoint.
Which versions were affected
CVE-2021-21985 affected vCenter Server 6.5, 6.7, and 7.0, and VMware Cloud Foundation (which bundles vCenter) 3.x and 4.x. The default-enabled plugin meant the affected surface was present on standard installations across all of those release lines.
Detection
- Inventory every vCenter Server and its exact build number, and identify any whose management interface (port 443) is reachable from untrusted networks. Internet-exposed vCenter is the highest-priority finding.
- Compare each build against the patched releases below. Build numbers, not just major versions, are what determine whether the fix is present.
- Review vCenter and vSphere Client logs for anomalous requests to the vSAN health endpoints (paths under the plugin's HTML5 namespace) and for unexpected child processes spawned by the vCenter service.
- Track vCenter as a managed asset so a future VMware advisory maps immediately to the specific instances you run.
Remediation and patched versions
Apply the fixed builds from VMSA-2021-0010: vCenter Server 7.0 U2b, 6.7 U3n, or 6.5 U3p (or any later release). Because a public exploit and mass scanning arrived within about a week, any internet-facing vCenter that was unpatched during that window should be investigated, not just upgraded.
If you genuinely could not patch immediately, VMware documented an interim mitigation that disabled the vulnerable plugin by setting the affected plugins to "incompatible" in a configuration file on the vCenter appliance, which took the endpoints offline until patching was possible. Two durable practices reduce this entire class of risk: never expose the vCenter management interface directly to the internet, and place it behind strict network segmentation so only authorized administrative networks can reach port 443.
How Safeguard helps
CVE-2021-21985 is a reminder that a default-enabled component you never intentionally used can still be your most exposed attack surface. Safeguard tracks infrastructure platforms like vCenter inside your asset and software inventories and correlates each against the CISA KEV catalog and exploit-availability signals, so an actively exploited, patch-available advisory immediately maps to the exact builds you run and jumps to the top of your queue rather than getting lost among lower-severity noise. For virtualization and management tooling shipped or deployed as images, Safeguard's container scanning flags builds pinned below a fixed version, and software composition analysis applies the same prioritization to the dependencies your own applications carry. Policy gates can block the promotion of a deployment that includes a known-exploited component. The comparison overview shows how this coverage and prioritization stack up.
When one flaw can hand over your entire hypervisor fleet, knowing exactly what you run and how it is exposed is the whole game. Get started free or read the documentation.
Frequently Asked Questions
Am I affected by CVE-2021-21985 if I do not use vSAN?
Yes. The vulnerability is in the vSAN Health Check plugin, which is enabled by default on every vCenter Server regardless of whether you have configured or use vSAN. The plugin's endpoints were loaded and reachable on standard installations, so not using vSAN did not protect you. You must apply the patched build or, as an interim step, disable the vulnerable plugin.
Which vCenter versions fix CVE-2021-21985?
Upgrade to vCenter Server 7.0 U2b, 6.7 U3n, or 6.5 U3p, or any later release, as documented in VMware advisory VMSA-2021-0010. Because build numbers determine whether the fix is present, verify the exact build after upgrading rather than relying on the major version alone. The advisory also covered the related plugin authentication flaw CVE-2021-21986.
How dangerous is a vCenter compromise?
Extremely. vCenter is the management control plane for VMware virtualization, so control over it typically means control over every ESXi host and virtual machine it manages. This is why ransomware operators prize vCenter flaws, they can encrypt or destroy entire virtual environments at the datastore level from a single foothold. An unauthenticated RCE like CVE-2021-21985 collapses the distance between "reachable on the network" and "owns the whole estate."
Should vCenter be reachable from the internet?
No. The vCenter management interface should never be directly exposed to untrusted networks. It should sit behind strict network segmentation so that only authorized administrative networks can reach port 443, and remote access should go through a VPN or bastion. Much of the mass exploitation of CVE-2021-21985 targeted internet-facing vCenter instances that scanning could discover directly.