CVE-2021-21973

What it actually does

CVE-2021-21973 is an unauthenticated server-side request forgery vulnerability in a vCenter Server vSphere Client HTML5 plugin. An attacker with network access to vCenter Server over HTTPS on port 443 can send crafted POST requests to the vulnerable plugin and cause vCenter Server to initiate outbound requests to attacker-chosen URLs. The direct impact is information disclosure: the attacker may be able to make vCenter access internal services, metadata endpoints, management interfaces, or otherwise unreachable network resources and observe responses or behavior through the vulnerable plugin.

Why it matters to the business

Successful exploitation can expose sensitive infrastructure information from vCenter-adjacent internal systems and help attackers map the virtualization management network. Because vCenter Server commonly has privileged network reachability into highly sensitive infrastructure, even a moderate-severity SSRF can materially increase the risk of follow-on compromise. This vulnerability is listed in CISA KEV, has a high EPSS score, and has been actively exploited in the wild, so internet-exposed or broadly reachable vCenter instances should be treated as urgent even though the CVSS score is 5.3. Affected products include VMware vCenter Server and VMware Cloud Foundation, which are widely used to manage business-critical virtualization estates.

How an attack unfolds

An attacker first identifies a reachable vCenter Server over HTTPS. They then probe for the vulnerable vSphere Client plugin endpoints associated with the vROps/vCenter plugin functionality. If the vulnerable plugin is present and unpatched, the attacker sends a crafted POST request containing a URL or host value that the server-side plugin processes without sufficient validation. vCenter then makes a request from the server side to the attacker-supplied destination. The attacker uses this behavior to query internal services, enumerate reachable management interfaces, collect metadata from HTTP responses, or confirm the presence of otherwise inaccessible systems. In real-world intrusion workflows, this type of SSRF is often used for reconnaissance and staging before attempting credential theft, lateral movement, or exploitation of other vCenter or internal-service vulnerabilities.

How to fix it

Upgrade affected VMware products to fixed versions or later. VMware vCenter Server is affected in 7.x before 7.0 U1c, 6.7 before 6.7 U3l, and 6.5 before 6.5 U3n. VMware Cloud Foundation is affected in 4.x before 4.2 and 3.x before 3.10.1.2. If immediate upgrade is not possible, apply VMware’s official workaround for VMSA-2021-0002, which involves disabling/removing the vulnerable vCenter Server plugin where applicable. Restrict access to vCenter Server management interfaces to trusted administrative networks only, block direct internet exposure, and enforce network egress controls from vCenter so it cannot freely reach arbitrary internal or external HTTP services.

How to confirm the fix worked

Confirm the installed vCenter Server or VMware Cloud Foundation version is at or above the fixed release: vCenter Server 7.0 U1c, 6.7 U3l, 6.5 U3n, VMware Cloud Foundation 4.2, or VMware Cloud Foundation 3.10.1.2. Validate that the vulnerable plugin endpoints are no longer accessible or that the vulnerable plugin has been disabled according to VMware guidance. Review vCenter Server reverse proxy and application logs for requests to vROps plugin paths. From a controlled test network, verify that unauthenticated POST requests to the known plugin paths do not trigger outbound server-side requests. Also confirm firewall rules limit TCP/443 access to vCenter from approved administrative sources only.

Typical attack path

1. Identify VMware vCenter Server or VMware Cloud Foundation management interfaces reachable on TCP/443.
2. Send HTTP requests to vSphere Client plugin paths to determine whether the vulnerable plugin is installed and accessible.
3. Craft a POST request to the vulnerable plugin endpoint with an attacker-controlled internal or external URL.
4. Cause vCenter Server to initiate a server-side request to the specified destination.
5. Analyze returned content, error messages, timing, or connection behavior to enumerate internal services and sensitive network locations.
6. Use discovered information to support follow-on attacks against vCenter, virtualization infrastructure, or adjacent internal systems.

How to detect it

Review vCenter Server access logs, reverse proxy logs, vSphere Client logs, web server logs, EDR network telemetry, firewall logs, proxy logs, and DNS logs. Focus on HTTP POST requests to vSphere Client vROps plugin paths, especially from unauthenticated, external, or unusual source IPs. Look for request parameters or bodies containing internal addresses, localhost, link-local ranges, cloud metadata endpoints, unusual ports, or full URLs. Correlate suspicious inbound requests to vCenter with outbound HTTP/HTTPS/DNS activity from the vCenter host shortly afterward. Useful artifacts include requests to /ui/vropspluginui/rest/services/ paths, HTTP 200/500 responses generated by those paths, unexpected vCenter-originated connections to RFC1918 ranges, 127.0.0.1, 169.254.169.254, or internal management services, and scanning patterns against multiple plugin endpoints. Because this vulnerability has been actively exploited, also investigate adjacent activity around the same time window, including failed or successful vCenter logins, exploitation attempts for other VMSA-2021-0002 vulnerabilities, abnormal plugin deployment, suspicious file uploads, or unexpected administrative operations.

• /ui/vropspluginui/rest/services/getstatus
• /ui/vropspluginui/rest/services/getvcdetails
• /ui/vropspluginui/rest/services/checkmobregister
• /ui/vropspluginui/rest/services/
• vropspluginui
• com.vmware.vrops.install
• POST /ui/vropspluginui/rest/services/
• 169.254.169.254
• 127.0.0.1
• localhost

What your security team should do

• Immediately inventory all VMware vCenter Server and VMware Cloud Foundation instances and identify versions affected by this vulnerability.
• Prioritize remediation for any instance reachable from the internet, from user networks, or from less-trusted internal segments.
• Upgrade to fixed versions or later: vCenter Server 7.0 U1c, 6.7 U3l, 6.5 U3n; VMware Cloud Foundation 4.2 or 3.10.1.2 as applicable.
• If patching cannot be completed immediately, apply VMware’s official plugin-disabling workaround and tightly restrict access to vCenter TCP/443.
• Hunt for historical requests to vulnerable plugin endpoints, especially unauthenticated POST requests and requests containing internal IP ranges, localhost, link-local addresses, or cloud metadata addresses.
• Review vCenter egress logs, proxy logs, DNS logs, and firewall telemetry for unexpected outbound HTTP/HTTPS requests initiated by vCenter Server.
• Because this issue is in CISA KEV and was due for remediation by 2022-03-21, treat any still-vulnerable system as a high-priority governance and exposure issue.
• Assess for follow-on activity, including attempts against other vCenter vulnerabilities, suspicious administrative logins, new vCenter users, unusual plugin activity, or unexpected virtual machine operations.