HowToFixMe
● Critical · CVSS 9.8 ⚠ ACTIVELY EXPLOITED — CISA KEV

How to Fix CVE-2020-3952: Critical Information Disclosure in VMware vCenter Server

By the Sai Kiran Pandrala · Reviewed and edited by Sai Kiran Pandrala, Editor

⚡ At a glance
SeverityCVSS 9.8, Critical
Actively exploited?Yes, listed in CISA KEV (added 2021-11-03)
AffectedVMware vCenter Server 6.7 (embedded or external PSC), only when upgraded from an earlier release line such as 6.0 or 6.5. Clean 6.7 installs are not affected.
Fixed invCenter Server 6.7 Update 3f (6.7u3f), per VMware advisory VMSA-2020-0006
Type (CWE)CWE-306: Missing Authentication for Critical Function (vmdir access-control failure → information disclosure / auth bypass)

Exploitation status

CVE-2020-3952 is actively exploited in the wild. CISA added it to the Known Exploited Vulnerabilities (KEV) catalog on as “VMware vCenter Server Information Disclosure Vulnerability”, which makes patching mandatory for U.S. federal agencies under Binding Operational Directive 22-01. Federal agencies were required to remediate it by . If you run an affected system, treat this as an emergency change, not a scheduled one.

Public exploit availability: a working authentication-bypass write-up for vCenter Server 6.7 is published on Packet Storm (linked below), and the vulnerability sits on the CISA KEV catalog. Proof-of-concept code that abuses the vmdir access-control flaw to read directory data and forge an administrator login is publicly circulated. Treat weaponization as certain and patch on an emergency timeline.

Authoritative references:

⚠️ Patch immediately. Upgrade vCenter Server 6.7 to Update 3f (6.7u3f) per VMSA-2020-0006. CVE-2020-3952 is in CISA's Known Exploited Vulnerabilities catalog (added 2021-11-03); federal agencies had until 2022-05-03 to remediate.

What is CVE-2020-3952?

vmdir is the embedded directory service that backs vCenter Single Sign-On. It lives inside the Platform Services Controller (PSC), whether that PSC is embedded in the vCenter Server appliance or deployed externally. Under certain conditions, vmdir does not correctly enforce its access controls. That is a classic CWE-306: Missing Authentication for Critical Function, where a security-critical directory operation that should require authentication can be reached without it.

This is not a remote code execution bug and it is not a denial-of-service bug. It is an information-disclosure and authentication-bypass flaw. With network reach to the vmdir LDAP endpoint, an attacker can query directory contents that should be protected, including the SSO database that holds password material and certificates. From there the path to extracting or forging an administrator login, and then taking over every host and VM that vCenter manages, is very short. That is why the CVSS base score is the maximum-impact 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H): unauthenticated, network-reachable, low complexity, total impact on confidentiality, integrity, and availability.

One detail decides whether you are exposed. The flaw only affects vCenter Server 6.7 that was upgraded from an earlier line (6.0 or 6.5). A clean 6.7 install is not vulnerable, because the broken vmdir access-control state is inherited through the upgrade, not created by a fresh deployment. So an environment that has been carried forward across upgrade cycles for years is exactly the one most likely to be hit.

Am I affected?

You are exposed if all three are true: the build is vCenter Server 6.7, it is below Update 3f, and the appliance was upgraded into 6.7 from 6.0 or 6.5 instead of installed clean. Check the running build from the appliance, not from an ESXi host, vCenter and ESXi are separate products and ESXi version probes tell you nothing about this CVE.

From the vCenter Server Appliance (vCSA) shell, enable and enter the shell, then read the version file:

# SSH to the vCSA, then:
shell
cat /etc/vmware/.buildInfo            # shows the appliance build
vpxd -v                              # vpxd service version string

Or open the VAMI management interface at https://<vcsa-fqdn>:5480 and read the version and build under Summary. Map the build number against VMware's build-to-version table; anything below the 6.7u3f build is vulnerable if it was an upgrade.

How to fix CVE-2020-3952

The fix is a single, vendor-supported action: update vCenter Server 6.7 to Update 3f (6.7u3f) or later. VMware shipped 6.7u3f specifically to correct the vmdir access-control behaviour. Apply it to every PSC and vCenter node in the SSO domain: embedded and external alike. There is no partial mitigation that substitutes for the update; vmdir is core SSO infrastructure and cannot simply be firewalled off from the vCenter services that depend on it.

Patch the appliance through the VAMI (recommended)

  1. Take a snapshot or file-based backup of the vCSA first (VAMI → Backup, or snapshot while powered off). vCenter upgrades are hard to roll back without one.
  2. Browse to https://<vcsa-fqdn>:5480 and log in as root.
  3. Go to Update. Click Check Updates → Check CD-ROM + URL to pull from VMware's repository, or stage an offline patch ISO mounted to the appliance.
  4. Select the 6.7 Update 3f patch and click Stage and Install. Accept the EULA and let the appliance reboot when prompted.

Patch the appliance from the shell (software-packages)

The vCSA exposes the same updater on the command line. These commands run inside the appliance shell; they are appliance-native, not generic Linux package commands:

# SSH to the vCSA as root, then enter the shell
shell

# Stage from VMware's online repository (or use --iso for a mounted patch ISO)
software-packages stage --url --acceptEulas

# Review what will be applied
software-packages list --staged

# Install the staged 6.7u3f patch, then reboot
software-packages install --staged
reboot

If you run an external PSC topology, patch the external PSC nodes first, then the vCenter Server nodes, following the order in the VMware update documentation for your topology. In an enhanced-linked-mode SSO domain, bring every node to 6.7u3f so no unpatched vmdir replica remains reachable.

If you can't patch immediately

VMware published no workaround for CVE-2020-3952. The update is the only supported fix, and the vmdir LDAP service cannot be disabled without breaking Single Sign-On. The only meaningful interim control is to shrink who can reach vmdir on the network while you schedule the emergency change.

vmdir answers on LDAP TCP 389 (and 636 for LDAPS); the SSO HTTPS endpoints sit on 443. Restrict those ports at the perimeter and on the management network so only your vCenter administration subnet can talk to the appliance. On an upstream firewall or a host-based filter in front of the vCSA:

# Example upstream filter: allow only the vCenter admin subnet to reach vmdir LDAP,
# drop everything else. Adjust 10.20.0.0/24 to your real admin subnet.
iptables -A INPUT -p tcp -m multiport --dports 389,636 -s 10.20.0.0/24 -j ACCEPT
iptables -A INPUT -p tcp -m multiport --dports 389,636 -j DROP

Treat this strictly as blast-radius reduction. Any host inside the allowed subnet that an attacker already controls still reaches the flaw, so do not let the firewall rule become a reason to delay 6.7u3f.

Verify the fix

After the appliance reboots, confirm the running build is at or above the 6.7u3f build from the VAMI Summary page or from the shell:

cat /etc/vmware/.buildInfo
vpxd -v

Then log into the vSphere Client and confirm SSO, inventory, and host connections came back healthy. Re-run whatever vulnerability scanner flagged the finding and confirm CVE-2020-3952 has cleared. Because this is an active-exploitation KEV item, also review vmdir and SSO logs (/var/log/vmware/vmdird/ and the SSO/STS logs) for anomalous LDAP binds or directory reads during the exposure window. If the appliance was reachable from untrusted networks before patching, assume the SSO credential store may have been read and rotate SSO and service-account credentials.

Frequently asked questions

Which version of vCenter Server fixes CVE-2020-3952?

vCenter Server 6.7 Update 3f (6.7u3f), released alongside VMware advisory VMSA-2020-0006. Update every embedded and external PSC and every vCenter node in the SSO domain to 6.7u3f or later.

Is my vCenter Server affected if it was a clean 6.7 install?

No. Only 6.7 deployments upgraded from an earlier line (6.0 or 6.5) are affected. A fresh, clean 6.7 install (embedded or external PSC) is not vulnerable, because the broken vmdir access-control state is carried over by the upgrade path and never created on a clean install.

What can an attacker actually do with this flaw?

vmdir fails to enforce access controls, so an unauthenticated attacker with network reach to the vmdir LDAP endpoint can read protected directory data, including SSO credential and certificate material. and use it to forge an administrator login. That yields full control of vCenter Single Sign-On and, through it, every host and VM vCenter manages. The 9.8 CVSS reflects that total impact.

Is there a public exploit for CVE-2020-3952?

Yes. A public authentication-bypass write-up for vCenter Server 6.7 is hosted on Packet Storm (linked in the references), and the CVE is on the CISA KEV catalog with confirmed in-the-wild exploitation. Treat working attack code as available and patch on an emergency timeline.

References

Written by Sai Kiran Pandrala on 2026-05-25. Sourced from the official vendor advisory, the NVD record, and the CISA KEV listing. Always confirm against the vendor advisory before applying changes in production.

Additional nearby issues sensible to fix in the same maintenance window:

People also ask

Which version of vCenter Server fixes CVE-2020-3952?

vCenter Server 6.7 Update 3f (6.7u3f), released alongside VMware advisory VMSA-2020-0006. Update every embedded and external PSC and every vCenter node in the SSO domain to 6.7u3f or later.

Is my vCenter Server affected if it was a clean 6.7 install?

No. Only 6.7 deployments upgraded from an earlier line (6.0 or 6.5) are affected. A fresh, clean 6.7 install is not vulnerable, because the broken vmdir access-control state is carried over by the upgrade path and never created on a clean install.

What can an attacker actually do with this flaw?

vmdir fails to enforce access controls, so an unauthenticated attacker with network reach to the vmdir LDAP endpoint can read protected directory data, including SSO credential and certificate material, and use it to forge an administrator login. That yields full control of vCenter Single Sign-On and every host and VM vCenter manages.

Is there a public exploit for CVE-2020-3952?

Yes. A public authentication-bypass write-up for vCenter Server 6.7 is hosted on Packet Storm, and the CVE is on the CISA KEV catalog with confirmed in-the-wild exploitation. Treat working attack code as available and patch on an emergency timeline.