OpenSLP/CIM Service Security Advisories for ESXi

OpenSLP/CIM Service Security Advisories for ESXi

There have been recent publications that mention VMware related security vulnerabilities. These articles serve as a reminder of the importance of regular patching.  This is the best defense against vulnerabilities and should be a foundation of your security policy. Specifically, two CVEs are mentioned: CVE-2019-5544 and CVE-2020-3992. These issues were disclosed with a critical severity rating months ago in VMSA-2019-0022 and VMSA-2020-0023 respectively, and workarounds are documented in KB76372. The workarounds in the KB remove the possibility of exploitation. 

VMware publishes all VMware Security Advisories here. You can sign up to be notified by email of any new or edited Security Advisories.

Additionally, the following resources are recommended:

VMware Security Advisories:
Mailing list for VMSAs:
VMSA RSS feed:
Workaround KB:

Sample 3rd party publications:
ZDNet Publication:
Reddit thread:


What ESXi version should I upgrade/patch to?

As of this date, upgrade to one of the following builds, or newer:

ESXi 7.0 build 17119627 (4-November-2020) or newer (recommend latest build 17551050, version 7.0 Update 1d, 4-Feb-2021)

ESXi 6.7 build 17098360 (4-November-2020) or newer (recommend latest build 17167734, 19-November-2020)

ESXi 6.5 build 17097218 (4-November-2020) or newer (recommend latest build 17167537, 19-November-2020)

(Prior to upgrading ESXi it may be necessary to upgrade vCenter server. Refer to

Are ESXi 5.5 and/or 6.0 impacted?

ESXi 5.5 and 6.0 are beyond End of Support from VMware; they are not tested for vulnerability and patches are not released.  I would operate under zero-trust & assume the vulnerability exists in these products.  vSphere 6.0 went EOS in March 2020, so it was included in the VMSA-2019-0022.  It was EOS before VMSA-2020-0023 was published.

How should I remediate older ESXi hosts?

You should be able to disable CIM service/OpenSLP on older hosts following the same KB (76372), or follow similar documentation for previous ESXi versions to stop/disable services.  You should also have network segmentation & limit IPs which can connect to ESXi/vCenter (limit to connections from a jump server etc.) which can help minimize exposure.  Firewall port 427 UDP/TCP.  There are inherent risks in running older, EOS products so you need to surround them with layers of protection following security best practices.

What is the impact of disabling CIM/SLP service on ESXi hosts?

There may be 3rd party tools which use CIM/SLP, but I cannot find specific documented examples of impact from disabling CIM/SLP service. My personal recommendation is that the security benefit from disabling it outweighs the minimal risk of impact that may be caused by disabling it.

You can run this command to get slp stats on an ESXi host:
esxcli system slp stats get

There is no known impact to VMware software such as vCenter or vROps.

What about VxRail systems?

Regarding the security vulnerabilities discussed below, per:

Apply VxRail release 7.0.130 (contains ESXi 7.0 U1c build 17325551) to patch these systems. Also note the required vCenter version, min 7.0 U1, recommended 7.0 U1c

Additional resources for reference:

ESXi build number/version mapping:

vCenter build number/version mapping:

Additional information provided by my colleague Jalissa Hunter:

Background to ESXI Ransomware Attacks: 

Two VMware ESXI vulnerabilities, CVE-2019-5544 and CVE-2020-3992, are being exploited by two ransomware gangs: RansomExx (also known as Defray777) and Babuk Locker. RansomExx and Babuk Locker are known to do extensive research on a probable target before enacting an attack. Both organizations are known for exploiting weaknesses in remote protocols, virtual VPNs, and targeting specific individuals in an organization via phishing and whaling emails. 

There are two pathways used by ransomware attackers to encrypt a vSphere datastore. They must:

  • Get access to admin vSphere privileges 
  • Get network access to the vSphere management environment 

Security remedies to mitigate attack entry from the methods mentioned above:

  • Domain Admin role(s) should not also have vSphere admin role, and normal user accounts should not have either of those roles.
  • Ensure that workloads are not on the same subnet as the management subnet of a vSphere environment, i.e., increase network segmentation. 
  • Attackers also attempt to target backups to prevent quick restoration of an environment. Ensure backups are on segmented storage. 
  • Narrow vSphere management access to a a limited set of authenticated IP addresses (use secured jump server, etc.)
  • If vSphere 7 is active in your environment, consider enabling Identity Federation feature for your AD and vSphere Trust Authority clusters for hosts that contain sensitive workloads. 
  • Update current security monitoring solutions to be able to recognize ransomware script from RansomExx. The following link contains example of the typical script utilized by RansomExx and Babuk for attacks:

DISCLAIMER: This information is not endorsed by VMware and is not an official publication. This is a personal contribution to the vExpert/VMUG #vCommunity for informational purposes only, based on my own research.  Validate all information, research and test thoroughly, especially before applying any changes to production systems. Any official publication by VMware (VMSA, KB, release notes, etc.), Dell, government agencies, etc., should supersede this blog.

Comments are closed.