CVE-2021-21985: VMware vCenter unauthenticated RCE via vSAN Health plugin
The short version: VMware vCenter Server has a remote code execution flaw (CVE-2021-21985) in the Virtual SAN (vSAN) Health Check plugin, which is enabled by default in every vCenter deployment — whether or not you use vSAN. An attacker who can reach port 443 can execute commands with unrestricted privileges on the host, no authentication required. Public exploits followed quickly and it's in CISA's KEV catalog. If your vCenter is reachable and unpatched, this is patch-and-verify. Steady hands — but move.
At a glance
| Fact | Detail |
|---|---|
| Our severity take | Critical — in practice and on paper |
| CVSS v3.1 (NVD) | 9.8 — Critical · AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H |
| EPSS | ~100% · 99.9th percentile (2026-07-17) |
| In CISA KEV? | Yes — remediation was due 2021-11-17 |
| Known exploited? | Yes — public PoC and active exploitation; CISA notes known ransomware use |
| Vulnerability type | CWE-918 SSRF / CWE-20 improper input validation → unauthenticated remote code execution |
| Requires authenticated session? | No — pre-authentication |
| Affected | vCenter Server 6.5 < U3p, 6.7 < U3n, 7.x < 7.0 U2b; Cloud Foundation 3.x and 4.x |
| Fixed in | vCenter Server 7.0 U2b · 6.7 U3n · 6.5 U3p (and matching Cloud Foundation releases) |
What you need to know
CVE-2021-21985 is a remote code execution flaw caused by a lack of input validation in the vSAN Health Check plugin of the vSphere Client. The critical detail is that the plugin is enabled by default in all vCenter deployments — you don't have to run vSAN to be exposed. An attacker with network access to port 443 can exploit it to execute commands with unrestricted privileges on the host that runs vCenter Server.
Why the practical risk is at the top:
- It's the platform that runs everything. vCenter manages your ESXi hosts and VMs; privileged code execution there reaches the entire virtual estate.
- It's on by default. The vulnerable plugin ships enabled regardless of whether you use vSAN, so "we don't run vSAN" is not protection.
- It was weaponized fast. Public PoC exploits appeared within days, scanning followed, and CISA notes known ransomware use.
How serious we see it
Critical — in practice and on paper.
Unauthenticated, network-reachable, privileged code execution on the management plane of your virtual infrastructure, with public exploits and a KEV listing, is top-of-queue. The 9.8 fits. The bounded, reassuring part is that it's specific and fixable: particular vCenter and Cloud Foundation builds, published fixes, and a documented interim workaround — with the same caveat as its sibling flaw, that disabling the plugin from the UI alone does not protect you (you must mark it incompatible in the compatibility matrix). The catch: patched and clean are separate questions.
Recommendations
Straight from VMware's advisory (VMSA-2021-0010) and CISA:
- Patch now. Upgrade to vCenter Server 7.0 U2b / 6.7 U3n / 6.5 U3p or later.
- If you can't patch immediately, apply VMware's workaround. Mark the affected plugin incompatible per the advisory (disabling it in the UI is not sufficient).
- Hunt for prior use. Review logs for anomalous requests to the plugin and signs of code execution on the host.
- If you find indicators, respond fully. Rebuild where warranted and rotate credentials, keys, and certificates.
- Get vCenter off the public internet. Restrict management access to trusted networks.
How BreachRisk sees it
BreachRisk discovers internet-facing vCenter Server instances from little more than your domain, fingerprints the product and version, and flags exposure tied to CVE-2021-21985 — raised to the top because it's in KEV and tied to ransomware. Where authorized, it goes a step past a scanner: it sends a safe, bounded check to the affected endpoint and looks only for the response that indicates the vulnerable path is present, confirming exposure without running code on your server.
That outside-in, continuous view is the point: when a vCenter RCE breaks, the exposed appliance is already mapped, so you go straight to patch-and-verify.