CVE-2020-3952: VMware vCenter Server Information Disclosure Vulnerability

CVE-2020-3952 is an information disclosure vulnerability in VMware vCenter Server’s Directory Service (vmdir). When the Platform Services Controller (PSC) fails to enforce access controls correctly, an attacker who can reach the service on the network can pull sensitive directory data. For IT and security teams, this matters because vCenter is a high-value management plane: leaked directory information can accelerate further compromise of the virtualization environment.

CISA lists the required action as applying updates per the vendor’s instructions. Known ransomware use is not documented for this CVE, but the exposure of sensitive directory material still warrants prompt attention.

How it works

The weakness is classified as CWE-306 (Missing Authentication for Critical Function). In this case the VMware Directory Service does not correctly implement access controls on the Platform Services Controller. An attacker who has network reachability to the LDAP-related port used by the service (port 389) can interact with vmdir without the authentication or authorization checks that should protect directory contents.

Successful abuse lets the attacker extract sensitive information stored or served by the directory. Exact request formats, response contents, and any prerequisites beyond network access to that port are not detailed in the supplied facts; defenders should treat any unauthenticated or weakly authenticated query path to vmdir as the attack surface and confirm precise mechanics against the vendor advisory.

Am I affected? How to find it in your systems

The vulnerability affects VMware vCenter Server deployments that include the Platform Services Controller and the VMware Directory Service. vCenter commonly runs as a dedicated appliance or on supported Windows hosts inside management networks, often with PSC co-located or external.

• Inventory every vCenter Server and PSC instance (appliance and Windows-based). Record build/version strings from the administration interface, appliance shell, or vendor inventory tools.
• Confirm whether vmdir is listening and reachable on port 389 from untrusted or broadly accessible network segments. Check firewall rules, security groups, and network ACLs that permit LDAP traffic to management hosts.
• Compare installed versions and PSC configuration against the fixed releases listed in the VMware advisory for CVE-2020-3952; do not assume a version is safe without that confirmation.
• Review authentication and directory logs for unexpected LDAP binds, anonymous or low-privilege queries, or bulk reads originating from unfamiliar source addresses. NetFlow or firewall logs showing sustained connections to port 389 on vCenter/PSC hosts are also useful indicators.

If public detail on exact vulnerable builds is limited in your environment documentation, treat every reachable vCenter until you have verified the vendor’s fixed-version list.

How to remediate

Patch first. Apply the VMware updates that address CVE-2020-3952 exactly as described in the vendor advisory and CISA’s direction to “apply updates per vendor instructions.” Schedule the update during a maintenance window that accounts for vCenter/PSC reboot or service restart behavior, and validate directory and single-sign-on functionality afterward.

• After patching, re-check that access controls on vmdir are enforced and that anonymous or unauthenticated LDAP access is no longer possible from outside authorized management hosts.
• Restrict management-plane network access so that only jump hosts, admin workstations, and necessary infrastructure can reach vCenter and PSC ports, including 389.
• Enforce least-privilege administrative accounts, rotate any credentials that may have been exposed, and ensure directory replication and backup channels are also protected.
• Document the new baseline version and configuration so future drift can be detected quickly.

If you can't patch immediately

Until the vendor update can be installed, reduce exposure with compensating controls focused on the network path and the directory service.

• Segment vCenter and PSC hosts onto tightly controlled management networks; block port 389 (and any other directory ports) from user LANs, DMZs, and the internet at the firewall or security-group layer.
• If a web application firewall or virtual-patching capability sits in front of management interfaces, enable any vendor- or community-supplied rules that restrict unauthenticated LDAP-style access; confirm rule coverage against the advisory because signatures may be generic for this class.
• Disable or restrict any optional directory features or external LDAP interfaces that are not required for production operation, provided the vendor documentation permits it.
• Increase monitoring: alert on new connections to port 389, large or unusual LDAP result sets, and authentication anomalies on the PSC. Retain packet captures or detailed directory logs for a short window so suspected activity can be investigated.
• Limit the number of standing administrative sessions and require multi-factor authentication for all vCenter access paths that support it.

These steps do not replace the patch; they only lower likelihood and impact until the update is applied.

If your data may have been exposed

Actively exploited vulnerabilities can lead to breaches. If logs or network telemetry suggest that sensitive directory information was retrieved, follow your incident-response process: isolate affected systems as appropriate, preserve evidence, rotate potentially compromised credentials and certificates, and assess whether further lateral movement occurred inside the virtualization environment. You can also run a free exposure scan of your email addresses against known breach data sets to see whether associated accounts appear in prior third-party breaches while you complete containment and recovery.