Cloudanix VulnDB

CVE-2021-22005

Critical · 9.8 CISA KEV · ransomware

CVSS

9.8

EPSS

100.0%

Published

Sep 23, 2021

CISA due date

Nov 17, 2021

Cloudanix analysis

Act now SSVC: Act

A flaw in VMware’s central virtualization management server can let an outside attacker take control of it and potentially disrupt many business systems at once.

Active In The Wild Wormable
Exploitation
Remote Unauthenticated
Attacker needs
None
Complexity
Trivial
Impact
Remote Code Execution
Component
Application
Class
Path Traversal
Remediation
Upgrade
Effort
Medium
Patch risk
Medium

What it actually does

CVE-2021-22005 is an unauthenticated arbitrary file upload vulnerability in the VMware vCenter Server Analytics service exposed over HTTPS on TCP/443. By submitting a crafted request to the vulnerable Analytics/CEIP endpoint, an attacker with network reachability to vCenter can write attacker-controlled files to unintended filesystem locations. In practical exploitation, that file-write primitive can be used to place a web shell or other executable content where vCenter services will execute it, resulting in remote code execution with the privileges of the vCenter service account. Because vCenter is a high-trust management plane, successful exploitation can expose credentials, SSO tokens, host management capabilities, VM inventory, and administrative control paths for the virtualization estate.

Why it matters to the business

This is a critical, remotely exploitable, unauthenticated vCenter vulnerability with known exploitation in the wild, inclusion in CISA KEV, a past remediation deadline of 2021-11-17, and known ransomware use. Compromise of vCenter can give attackers a path to disrupt or encrypt large portions of a virtualized environment, steal sensitive operational data, create persistence in management infrastructure, and interfere with backup, recovery, and business continuity. Any internet-exposed or broadly reachable vCenter instance should be treated as high risk until patched and reviewed for compromise.

How an attack unfolds

An attacker first identifies a reachable VMware vCenter Server over HTTPS, typically on TCP/443, and determines whether the Analytics service endpoint is present. The attacker sends a specially crafted unauthenticated upload request to the Analytics/CEIP API that abuses path handling in the upload process. The malicious payload is written outside the intended upload directory, commonly with the goal of placing a server-side script, web shell, or other executable file into a location served or loaded by vCenter components. The attacker then triggers the uploaded file or waits for the service to process it, gaining command execution on the vCenter appliance. After gaining execution, common follow-on actions include enumerating vCenter configuration, harvesting credentials or tokens, deploying persistence, pivoting to ESXi hosts or administrative interfaces, and preparing for data theft, destructive activity, or ransomware deployment.

How to fix it

Patch VMware vCenter Server and VMware Cloud Foundation deployments according to VMware Security Advisory VMSA-2021-0020 or later vendor guidance. Because no exact fixed versions were provided in the input, use the vendor-supported fixed release for the deployed product branch or upgrade to the latest supported release. Historically affected vCenter branches required patched updates such as vCenter Server 7.0 U2c or later, 6.7 U3o or later, and 6.5 U3q or later; verify against current VMware/Broadcom documentation before change implementation. If immediate patching is not possible, apply VMware’s official workaround for CVE-2021-22005, which restricts or disables the vulnerable Analytics/CEIP endpoint, and limit network access to vCenter TCP/443 to trusted administrative networks only. Workarounds should be treated as temporary risk reduction, not a replacement for patching. After patching, rotate potentially exposed administrative credentials and review vCenter SSO, service accounts, local appliance accounts, and ESXi trust relationships if exploitation is suspected.

How to confirm the fix worked

Confirm the deployed vCenter Server or VMware Cloud Foundation version is at or above the vendor-fixed level for its release branch. Verify that the vulnerable Analytics/CEIP endpoint is no longer exploitable and that any temporary workaround remains correctly applied until patching is complete. From a network perspective, confirm vCenter HTTPS access is not broadly exposed and is restricted to approved administrative sources. Review vCenter Appliance Management Interface, vSphere Client, and command-line version output, and compare the build number to VMware/Broadcom advisory guidance. Validate that web server logs no longer show unauthenticated upload attempts to Analytics endpoints and that no unexpected files exist under vCenter web application, Tomcat, STS, Analytics, or temporary upload directories.

Typical attack path

  1. Scan for VMware vCenter Server exposed over HTTPS, especially TCP/443.
  2. Probe the Analytics/CEIP endpoints for vulnerable behavior.
  3. Send a crafted unauthenticated file upload request containing path traversal or malicious archive content.
  4. Write a payload, such as a web shell or executable script, to an unintended location on the vCenter appliance.
  5. Invoke the uploaded payload through an HTTP request or service execution path to obtain remote code execution.
  6. Run discovery commands to identify vCenter version, privileges, connected ESXi hosts, VM inventory, and available credentials or tokens.
  7. Establish persistence and expand access into the virtualization management plane.
  8. Use vCenter control to disrupt workloads, steal data, disable recovery options, or support ransomware operations.

How to detect it

Review historical HTTP access logs, reverse proxy logs, load balancer logs, firewall logs, EDR telemetry, appliance shell history, vCenter service logs, and file integrity data for signs of exploitation. Focus on unauthenticated POST requests to vCenter Analytics/CEIP upload endpoints, especially from untrusted IP addresses, followed by requests for newly created files or unusual server-side scripts. Investigate unexpected files in vCenter web application directories, Tomcat directories, STS directories, Analytics directories, temporary upload paths, and other locations writable by service processes. Look for web service processes spawning shells or system utilities, including bash, sh, python, perl, curl, wget, nc, chmod, chown, base64, openssl, or PowerCLI-related tooling. Correlate suspicious endpoint hits with vCenter authentication events, new SSO users, role changes, ESXi host operations, datastore browsing, snapshot activity, backup tampering, and VM power or encryption events. Because this CVE has been exploited in the wild and used in ransomware campaigns, absence of an obvious web shell is not sufficient; also hunt for post-exploitation behavior such as credential dumping, persistence, outbound command-and-control connections, and abnormal administrative actions after the first suspicious Analytics request.

  • POST /analytics/telemetry/ph/api/hyper/send
  • POST /analytics/ph/api/hyper/send
  • /analytics/telemetry/ph/api/hyper/send
  • /analytics/ph/api/hyper/send
  • /analytics/telemetry/
  • /analytics/ph/api/
  • /usr/lib/vmware-sso/vmware-sts/webapps/ROOT/
  • /usr/lib/vmware-sso/vmware-sts/webapps/ROOT/WEB-INF/classes/
  • /usr/lib/vmware-vsphere-ui/server/work/deployer/
  • /usr/lib/vmware-vsphere-ui/server/serviceability/work/
  • /var/log/vmware/analytics/
  • /var/log/vmware/vsphere-ui/logs/
  • /var/log/vmware/vmware-sso/
  • /var/log/vmware/envoy/envoy-access.log
  • /var/log/vmware/rhttpproxy/access.log
  • /var/log/vmware/vmon/vmon.log
  • catalina.out
  • vsphere-ui-runtime.log
  • vmware-sts-idmd.log
  • cmd.exe /c
  • /bin/sh -c
  • /bin/bash -c
  • wget http
  • curl http
  • chmod +x
  • nc -e
  • bash -i
  • python -c
  • perl -e

What your security team should do

  • Immediately identify all VMware vCenter Server and VMware Cloud Foundation instances, including non-production, lab, DR, and externally exposed systems.
  • Prioritize emergency patching or upgrade because the vulnerability is unauthenticated, network-exploitable, KEV-listed, has extremely high EPSS, and is associated with ransomware activity.
  • If patching cannot be completed immediately, apply the official VMware workaround and restrict TCP/443 access to trusted administrative networks or VPN-controlled jump hosts.
  • Treat any previously internet-exposed unpatched vCenter as potentially compromised and perform forensic review before assuming remediation is complete.
  • Search historical logs for Analytics endpoint exploitation attempts, suspicious file uploads, web shell access, abnormal child processes from vCenter/Tomcat services, and unexpected privileged account activity.
  • Rotate vCenter administrator credentials, SSO credentials, service account secrets, and any credentials stored or managed through vCenter if compromise indicators are found.
  • Review ESXi hosts, datastores, backup infrastructure, and administrative integrations for signs of lateral movement or tampering.
  • Add SIEM detections for suspicious requests to vulnerable Analytics endpoints and for process execution spawned by vCenter web service components.
  • Maintain vCenter behind strict management-plane segmentation and remove direct internet exposure.
  • Document patch status and compensating controls for KEV tracking, noting that the CISA remediation due date has long passed.

The record

The vCenter Server contains an arbitrary file upload vulnerability in the Analytics service. A malicious actor with network access to port 443 on vCenter Server may exploit this issue to execute code on vCenter Server by uploading a specially crafted file.

Affected packages

Ecosystem Package Introduced Fixed

Related vulnerabilities