VMware vCenter Server RCE — CVE-2021-21972 Research Lab

Author: Niranjan Pokhrel

Independent research project reproducing and documenting a critical, publicly disclosed VMware vCenter Server vulnerability in an isolated home lab, to understand the vulnerability class, exploitation path, and defensive mitigations.

Summary

Why this project

vCenter Server is the central management plane for VMware virtualised infrastructure — compromising it can mean compromising an entire virtual data centre. This vulnerability is a textbook example of how a missing authentication check on a single plugin endpoint can escalate to full host takeover. I built this lab to move from reading a CVE advisory to actually understanding the attack surface, the exploitation chain, and — just as importantly — how it should have been prevented and how to detect it defensively.

Vulnerability overview

The vulnerability lives in the vSphere Client (HTML5), specifically a vCenter Server plugin that exposes a file upload endpoint (/ui/vropspluginui/rest/services/uploadova) without requiring authentication. An attacker with network access to port 443 can send a crafted POST request to this endpoint and upload arbitrary files — including a web shell — to a web-accessible directory on the underlying OS. This gives the attacker code execution with the privileges of the vCenter service, effectively full control of the appliance.

At a high level, the attack chain is:

1. Discovery — identify an internet- or network-exposed vCenter Server on port 443.
2. Verification — confirm the vulnerable, unauthenticated upload endpoint responds as expected (no valid session required).
3. Exploitation — upload a malicious archive containing a web shell to a web-accessible path, then invoke it via HTTP to execute commands on the host OS.
4. Impact — arbitrary command execution as the vCenter service account, enabling lateral movement across the managed virtual infrastructure.

Lab environment

Built entirely in an isolated, non-internet-facing virtual network with no production data:

• Hypervisor host: VMware ESXi (nested virtualisation)
• Target: vCenter Server Appliance, deliberately deployed on a vulnerable version (pre-patch) for research purposes only
• Attacker machine: Kali Linux
• Detection tooling: Nmap with a community-maintained NSE vulnerability-detection script
• Network: fully isolated lab subnet, no internet exposure, torn down after testing

(Specific IP addressing, credentials, and infrastructure details from the original build are intentionally omitted from this public writeup.)

Detection

Vulnerability presence can be confirmed defensively (i.e. by a blue team or auditor) using a public Nmap NSE script that checks whether the target's upload endpoint responds in a way consistent with the unpatched vulnerability — this is the same kind of check a vulnerability scanner or internal security team would run to identify exposed, unpatched vCenter instances on their network before an attacker does.

nmap -p443 --script CVE-2021-21972.nse <target-ip>

A vulnerable target flags as VULNERABLE (Exploitable) in the scan output, which is the trigger to prioritise immediate patching.

Exploitation (high-level only)

A working proof-of-concept exploit for this CVE has been publicly available since 2021 (originally published by security researcher chacka0101, linked in References). In the interest of not distributing a ready-to-run RCE payload from this profile, I'm not reproducing the exploit code here — the point of this writeup is the understanding, not the tooling. In summary, the public exploit automates steps 2–3 above: it packages a JSP web shell into the expected upload format, POSTs it to the vulnerable endpoint, confirms it landed in a web-accessible path, and then uses it to trigger a reverse shell back to the attacker.

Mitigation & defensive takeaways

• Patch immediately. VMware released fixed builds for all affected versions (7.0 U1c+, 6.7 U3l+, 6.5 U3n+) — patching remains the primary fix.
• Restrict management interface exposure. The Australian Cyber Security Centre's advisory on this CVE recommended restricting access to vCenter management interfaces both internally and externally — management planes for virtualisation infrastructure should never be broadly reachable.
• Network segmentation & ACLs limiting inbound access to vCenter's management port reduce the attack surface even before a patch is applied.
• Disable the vulnerable plugin as an interim workaround where patching isn't immediately possible (VMware published a documented workaround for the vROps plugin).
• Monitor for anomalous file uploads / new files in web-accessible directories on vCenter appliances as a detection control.

Skills demonstrated

• Building and configuring a nested ESXi + vCenter Server virtual lab from scratch
• Reading and interpreting vendor security advisories (VMSA) and CVE/CVSS scoring
• Vulnerability scanning and detection using Nmap NSE scripting
• Understanding of SSRF and unauthenticated file-upload vulnerability classes
• Translating a technical vulnerability into concrete mitigation guidance aligned with vendor and national cybersecurity centre (ACSC) recommendations

References

1. VMware, VMSA-2021-0002: VMware vCenter Server updates address remote code execution vulnerability in the vSphere Client (CVE-2021-21972), vmware.com
2. FIRST, CVSS v3.1 Calculator, first.org
3. CVE Details, CVE-2021-21972, cvedetails.com
4. VMware Knowledge Base, kb.vmware.com/s/article/82374
5. Australian Cyber Security Centre, VMware vCenter Server Plugin Remote Code Execution Vulnerability (CVE-2021-21972), cyber.gov.au
6. chacka0101, Exploits for CVE-2021-21972, github.com/chacka0101/exploits

This project was conducted in a fully isolated, non-production lab environment for educational and professional development purposes. No unauthorised systems were accessed.