CVE-2021-21985

What it actually does

CVE-2021-21985 is an unauthenticated remote code execution flaw in the VMware vSphere Client HTML5 interface caused by insufficient input validation in the Virtual SAN Health Check plug-in, which is enabled by default on affected vCenter Server deployments. An attacker who can reach vCenter Server over HTTPS on TCP port 443 can send crafted requests to the vSAN Health Check plug-in and cause commands to execute on the underlying vCenter operating system with unrestricted privileges. Successful exploitation can provide full compromise of the vCenter appliance, including access to virtualization management functions and potentially the ability to manipulate hosted workloads.

Why it matters to the business

This vulnerability is critical because vCenter Server is a high-value control plane for virtual infrastructure. Compromise can let an attacker disrupt operations, shut down or alter virtual machines, access sensitive configuration data, pivot into managed networks, deploy malware, or support ransomware activity. The vulnerability is listed in CISA KEV, has been exploited in the wild, is associated with ransomware use, and has an extremely high EPSS score, so unpatched internet-accessible or broadly reachable vCenter instances should be treated as urgent exposure.

How an attack unfolds

An attacker first identifies a reachable vCenter Server instance with the vSphere Client service exposed over HTTPS. Because the vulnerable vSAN Health Check plug-in is enabled by default, the attacker does not need credentials if the vulnerable endpoint is accessible. The attacker sends specially crafted HTTP requests to the vSphere Client vSAN plug-in endpoint that abuse weak input validation and unsafe method invocation behavior. If the target is vulnerable, the request causes the vCenter appliance to execute attacker-supplied operating system commands with high privileges. The attacker may then run reconnaissance commands, download tooling, establish persistence, create or modify vCenter accounts, access secrets and configuration files, manipulate virtual machines, or deploy ransomware-related payloads across the virtualized environment.

How to fix it

Apply the VMware security updates that remediate CVE-2021-21985 for affected VMware vCenter Server and VMware Cloud Foundation releases, following VMware advisory guidance for the deployed product branch. If immediate patching is not possible, apply VMware’s official workaround to disable the vulnerable vSAN Health Check plug-in until the system can be upgraded. Restrict access to vCenter Server TCP port 443 to trusted administrative networks, VPNs, or bastion hosts only; do not expose vCenter directly to the internet. Review vCenter administrative accounts, SSO configuration, plug-ins, scheduled tasks, and appliance integrity after remediation, especially for systems that were reachable before patching.

How to confirm the fix worked

Confirm the deployed vCenter Server or VMware Cloud Foundation build is a VMware-supported fixed build for this vulnerability. Verify that the vSphere Client and vSAN Health Check plug-in are either patched or, if relying on a temporary mitigation, disabled according to VMware’s documented workaround. From an unauthenticated network perspective, confirm that access to vCenter TCP port 443 is blocked except from approved administrative networks. Run an authenticated vulnerability scan or vendor-supported assessment to confirm CVE-2021-21985 is no longer reported. Review vSphere Client logs after patching to ensure exploit-like requests to vSAN plug-in endpoints are no longer succeeding and return only expected authorization or routing failures.

Typical attack path

1. Scan for exposed VMware vCenter Server or vSphere Client services on TCP port 443.
2. Fingerprint the vCenter version and confirm the HTML5 vSphere Client and vSAN Health Check plug-in are reachable.
3. Send crafted unauthenticated requests to the vulnerable vSAN Health Check plug-in endpoint.
4. Execute operating system commands on the vCenter appliance with elevated privileges.
5. Run discovery commands to identify the appliance, network, credentials, and managed virtual infrastructure.
6. Deploy a web shell, reverse shell, persistence mechanism, credential dumper, or additional payload.
7. Use vCenter access to manipulate virtual machines, pivot to adjacent systems, exfiltrate data, or support ransomware deployment.

How to detect it

Review vCenter Server and vSphere Client logs for suspicious unauthenticated requests to vSAN Health Check or h5-vsan proxy endpoints, especially requests containing Java method invocation terms, command execution strings, encoded payloads, or unusual POST bodies. Key log sources include vSphere UI logs, vCenter reverse proxy or access logs, appliance system logs, shell history, authentication logs, and EDR telemetry from the vCenter appliance. Look for HTTP requests to /ui/h5-vsan/rest/proxy/service from unexpected IP addresses, high volumes of 404/500 responses followed by successful responses, or request bodies referencing java.lang.Runtime, ProcessBuilder, getRuntime, exec, setTargetMethod, setStaticMethod, or invoke. On the host, investigate suspicious processes spawned by Java, vSphere UI, or vCenter services, especially bash, sh, python, perl, curl, wget, nc, ncat, openssl, or busybox. Also check for newly created local users, modified SSH configuration, unexpected cron jobs, web-accessible files, downloaded binaries, abnormal outbound connections, and unauthorized vCenter administrative actions such as account creation, role changes, VM power operations, snapshot changes, or datastore file modifications.

• /ui/h5-vsan/rest/proxy/service
• /ui/h5-vsan/
• h5-vsan
• vsanHealth
• vsanProviderUtils
• vsanProviderUtils_setVmodlHelper
• java.lang.Runtime
• Runtime.getRuntime
• getRuntime().exec
• ProcessBuilder
• setTargetMethod
• setStaticMethod
• setArguments
• setTargetObject
• invoke
• /var/log/vmware/vsphere-ui/logs/vsphere_client_virgo.log
• /var/log/vmware/vsphere-ui/logs/access/
• /var/log/vmware/vpxd/vpxd.log
• /var/log/vmware/vmon/vmon.log
• /var/log/vmware/sso/
• /var/log/messages
• /var/log/audit/audit.log
• bash -c
• sh -c
• wget http
• curl http
• nc -e
• ncat -e
• python -c
• perl -e

What your security team should do

• Treat any unpatched, reachable vCenter Server as a high-priority incident risk because this issue is KEV-listed, exploited in the wild, has an EPSS score near 1.0, and is associated with ransomware activity.
• Patch affected vCenter Server and VMware Cloud Foundation deployments immediately; if patching is delayed, disable the vSAN Health Check plug-in using VMware’s official workaround.
• Restrict vCenter Server management access on TCP port 443 to trusted administrative sources only and remove any direct internet exposure.
• Hunt historical logs for unauthenticated requests to vSAN Health Check or h5-vsan proxy endpoints, especially around the initial publication date and any period before patching.
• Investigate suspicious child processes spawned by vSphere UI, vCenter, or Java services, including shell interpreters, download utilities, and reverse-shell tooling.
• Rotate vCenter administrator, SSO, service account, and integration credentials if exploitation is suspected or cannot be ruled out.
• Review vCenter roles, permissions, users, plug-ins, scheduled tasks, alarms, and VM lifecycle events for unauthorized changes.
• Increase monitoring on virtualization management infrastructure and backup systems, as vCenter compromise can accelerate ransomware impact across many workloads.