Is CVE-2020-3952 (VMware vCenter Server Information Disclosure) being exploited in the wild?

How to confirm whether CVE-2020-3952 is in the exploited-in-the-wild category

For a CVE question, the practical test is not whether the flaw exists in the abstract, but whether it has been publicly treated as actively exploited. Here, CISA’s KEV listing is the key signal because it is curated specifically for vulnerabilities with reliable evidence of exploitation. The question for defenders is whether the asset is exposed, whether the required action has been completed, and whether the vulnerable access path is still reachable.

For vulnerability triage, start with the authoritative records in the CISA Known Exploited Vulnerabilities Catalog and the NIST National Vulnerability Database. The KEV entry tells you whether exploitation has been confirmed, while the NVD record helps you align internal inventory to the exact CVE and understand where it sits in your vulnerability workflow.

Because the issue is an information disclosure flaw in vCenter Server’s vmdir access controls, exposure review should focus on whether the Platform Services Controller role and the affected directory service path are present in your environment. If the affected service is internet-reachable or broadly reachable inside a management network, treat that as a higher-priority exposure than a dormant instance with strict network segmentation.

Why information disclosure in vCenter matters operationally

Information disclosure in a virtualization control plane is serious because vCenter often sits near the centre of administrative trust. Even when a flaw does not directly execute code, leaking directory or access-related data can help an attacker map the environment, identify privileged relationships, and prepare follow-on actions against management systems, identity stores, or adjacent infrastructure. That is why KEV inclusion should be treated as a concrete operational signal, not just a catalogue label.

The most relevant internal navigation for this kind of response is the Zero-Day and Exploited Vulnerabilities Guide, which aligns with the normal response pattern for KEV-class issues: prioritise exposure confirmation, apply the vendor fix or mitigation, and verify whether compromise may already have occurred. For broader remediation discipline, the Vulnerability Management Guide is useful because KEV-driven response depends on scope accuracy, exception handling, and validation after remediation.

Because CISA has not linked this CVE to known ransomware campaigns, the immediate response should not assume ransomware-specific behaviour. The more defensible assumption is that exploitation may be opportunistic, targeted, or preparatory, so defenders should evaluate both exposure and any sign that the management plane has been used to support later movement or disclosure.

What to do when patching or mitigation is delayed

If you cannot remediate immediately, reduce the reachable attack surface first. Restrict access to vCenter and related administrative paths, tighten network segmentation, and review whether any external-facing or broadly accessible management interfaces can be removed from reach. In parallel, look for signs that the affected directory service or platform access paths have already been queried in unusual ways, especially from administrative or service-side sources that should not normally touch them.

There is no substitute for authoritative verification of whether your version and deployment path are actually affected, so the vendor advisory should drive any version-specific decision. But from a security operations standpoint, a KEV-listed vulnerability should already be treated as a time-sensitive item even before patch windows open, because the exposure value is partly determined by how quickly the environment can be reached and used after disclosure.

Risk and Threat Considerations

Exploited vulnerabilities in management infrastructure are attractive because they can expose high-value data or relationships without requiring immediate full compromise. In a vCenter context, the risk is not limited to the disclosed information itself, it also includes what that information enables next, such as targeting privileged workflows, discovering management dependencies, or narrowing an attacker’s path to more valuable systems.

Failure mechanism: The flaw exists because access controls in the Platform Services Controller and vmdir do not correctly prevent disclosure of information that should remain protected, so an attacker who can reach the vulnerable service may extract data through a path that should have been denied.

Impact: Even without direct code execution, the disclosure can improve attacker reconnaissance, support privilege mapping, and shorten the path to later compromise of the virtualisation management plane or adjacent systems.

Practitioner Guidance

What to verify: Confirm whether any vCenter Server instance with the vulnerable directory-service path is still reachable from untrusted or overly broad internal networks, then verify whether the CISA KEV requirement has been operationalised in your patch or mitigation queue.

Decision rule: If the vulnerable service is exposed and the environment has not yet been remediated, treat the issue as an urgent exploitation concern and prioritise containment and exposure reduction before lower-value maintenance work.

What good looks like: You should be able to show that the exposed path is removed or tightly constrained, the KEV entry has been addressed, and post-remediation review has checked for unusual administrative activity around the affected system.

Practitioner takeaway: For a KEV-listed vCenter disclosure flaw, the right question is not simply “is it patchable”, but “has the exposed management path been closed quickly enough to prevent opportunistic use and follow-on access”.

Related resources from NHI Mgmt Group

• How do you patch or mitigate CVE-2020-3952 (VMware vCenter Server Information Disclosure)?
• CVE-2020-3952 (VMware vCenter Server Information Disclosure)
• Is CVE-2022-22948 (VMware vCenter Server Incorrect Default File Permissions Vulnerability) being exploited in the wild?
• Is CVE-2024-37079 (Broadcom VMware vCenter Server Out-of-bounds Write) being exploited in the wild?