Is CVE-2021-21972 (VMware vCenter Server Remote Code Execution) being exploited in the wild?

Yes. CISA added CVE-2021-21972 to its Known Exploited Vulnerabilities catalogue on 3 November 2021, which it does only when there is reliable evidence of active exploitation. CISA lists it as known to be used in ransomware campaigns. VMware vCenter Server vSphere Client contains a remote code execution vulnerability in a vCenter Server plugin which allows an attacker with network access to port 443 to execute commands with unrestricted privileges on the underlying operating system.

How to tell whether this CVE is actively exploited

The practical test is not whether a proof-of-concept exists, but whether a trusted authority has confirmed real-world abuse. For CVE-2021-21972, CISA’s KEV listing is the key signal because it indicates active exploitation, not just theoretical exposure. The fact that it is also associated with ransomware makes fast triage and containment more urgent.

For vulnerability response, the right first question is whether the affected vCenter Server instances are internet reachable or otherwise reachable on the exposed service path, because that is what turns a software flaw into an operational incident. A patchable RCE in a management plane should be treated as an asset exposure problem as much as a code defect.

Why this vulnerability is especially high impact in practice

Remote code execution in a virtualisation management component is high leverage because compromise of the management plane can give an attacker broad control over the underlying environment. In practice, that means the issue is not limited to one application host, it can become a path to broader administrative control, persistence, and rapid follow-on activity.

When the flaw is reachable over a standard management port, defenders should assume attackers can discover it quickly and attempt opportunistic exploitation. The risk increases when the system is exposed beyond a tightly controlled administrative network, or when patching is delayed while the service remains reachable.

What defenders should do while validating exposure

Start by confirming whether any vCenter Server systems are present, whether they are exposed to the networks that matter, and whether they are still running the vulnerable plugin path. Then compare your estate against the vendor advisory and the CISA KEV catalogue rather than relying on generic scanner output alone, because KEV status changes the remediation priority.

If patching or full remediation must wait, reduce exposure immediately by restricting access to the management interface, hardening network paths, and monitoring for signs of suspicious administrative activity. Where the flaw could have been used for command execution, assume the attacker may also have touched nearby credentials, sessions, or administrative workflows.

Risk and Threat Considerations

This type of CVE is dangerous because it combines active exploitation with privileged execution on infrastructure that defenders often trust by default. Once attackers reach the management plane, they can use that access to pivot into virtualised workloads, deploy persistence, or disrupt recovery.

Failure mechanism: The vulnerable plugin processes attacker-controlled input over an exposed management service and converts that input into command execution on the underlying operating system.

Impact: A successful exploit can lead to full server compromise, follow-on lateral movement, and broader environment control, especially when the management system has privileged reach into the estate.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	Active exploitation makes prioritised vulnerability handling central.
Recommendation — Prioritise, validate, and remediate the KEV-listed vCenter exposure first.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	The question is about an exploited software flaw requiring urgent remediation.
	RA-5 — Vulnerability Monitoring and Scanning	Exposure confirmation and KEV status depend on reliable vulnerability monitoring.
	SC-7 — Boundary Protection	Restricting reachable management interfaces reduces exploitability while patching is pending.
Recommendation — Track, verify, and remediate the vCenter flaw under flaw-remediation discipline. Continuously scan for the vulnerable vCenter service and validate remediation status. Restrict access paths to the vCenter management interface and isolate it from untrusted networks.
NIST CSF 2.0	PR.AA-05 — Least Privilege	An RCE on a management plane is far more dangerous when access is broadly trusted.
Recommendation — Limit administrative reach and constrain exposed management access to the smallest necessary scope.

Practitioner Guidance

What to verify: Confirm not just whether the CVE is present, but whether the affected system is reachable, whether the vendor fix has been applied, and whether the instance has any signs of post-exploitation such as unexpected admin actions, new scheduled tasks, or unusual service changes.

Decision rule: If the system is internet exposed or otherwise reachable from untrusted networks, treat it as urgent remediation even if no abuse has been observed yet. If patching must wait, isolate the system first, then investigate for compromise before you accept the delay as safe.

Practitioner takeaway: For KEV-listed RCEs on management infrastructure, the right priority is exposure reduction and compromise assessment, not just patch installation.