Is CVE-2021-22005 (VMware vCenter Server File Upload) being exploited in the wild?

By NHI Mgmt Group Editorial Team Updated October 19, 2026 Domain: Threats, Abuse & Incident Response

Yes. CISA added CVE-2021-22005 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 contains a file upload vulnerability in the Analytics service that allows a user with network access to port 443 to execute code.

What “being exploited in the wild” means for this CVE

This question is not asking whether the vulnerability exists, it is asking whether real attackers are already using it against live systems. For CVE-2021-22005, the practical meaning of “yes” is that defenders should treat exposure as an active incident response problem, not a theoretical patching item. CISA’s KEV entry is the operational signal that exploitation has crossed from possibility to confirmed abuse.

CISA Known Exploited Vulnerabilities Catalog is the right place to verify whether a vulnerability has entered the active-exploitation queue and to anchor remediation urgency to that status.

How to confirm whether your vCenter Server is exposed

The first check is simple: identify every VMware vCenter Server instance that can be reached over the network and determine whether it is internet-facing, partner-facing, or otherwise reachable by untrusted users. For this CVE, exposure is meaningful because the vulnerable Analytics service path can be reached through port 443, which is often broadly permitted in enterprise environments.

Do not limit the review to production vCenter. Clone, test, recovery, and staging systems matter because attackers often target whichever instance is easiest to reach, then use it as a bridge into administrative trust relationships and infrastructure management planes.

For authoritative product and record details, compare your inventory against the vendor and record sources, starting with the CVE Program entry and the vendor advisory before relying on internal asset labels alone.

What to do if patching must wait

If you cannot remediate immediately, treat the system as high risk and reduce exposure first. That means tightening network reachability to the vCenter management interface, restricting who can reach port 443, and removing any nonessential paths into the Analytics service. Compensating controls do not eliminate exploitation risk, but they can narrow who can trigger the flaw while you prepare the fix.

When a flaw is already known to be exploited, a delay in patching should trigger a short, explicit exception with an owner, expiry, and validation step. The question is not only whether the patch can wait, but whether the environment can tolerate the operational and credential impact of leaving a management platform exposed during an active exploitation window.

Where you need a triage model for exploited vulnerabilities, the Zero-Day and Exploited Vulnerabilities Guide provides a practical way to think about KEV-driven prioritisation, emergency mitigation, and post-patch checking.

Risk and Threat Considerations

Because vCenter Server is a high-value management plane, successful exploitation can provide an attacker with a fast path from a single network-facing flaw to broader infrastructure control. That changes the risk from one vulnerable service to potential platform-level compromise, especially where administrative access, automation, or privileged workflows are reachable from the same environment.

Failure mechanism: The vulnerability allows a user with network access to port 443 to abuse the file upload path in the Analytics service and execute code, which can turn a reachable management interface into an initial foothold.

Impact: Once code execution is possible on a vCenter Server, defenders should assume the blast radius may include virtualization management, credential exposure, lateral movement, and follow-on compromise of attached systems or administrative trust paths.

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 CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	KEV-listed exploitation requires prioritised vulnerability handling and exposure reduction.
Recommendation — Prioritise, remediate, and verify exploited vulnerabilities on affected vCenter systems.
NIST CSF 2.0	ID.RA-01 — Asset Vulnerabilities Are Identified and Documented	This question hinges on identifying exposed vulnerable instances and acting on active exploitation.
	RS.MA-1 — Incident Management Is Executed	Confirmed in-the-wild exploitation calls for containment and response, not routine patching alone.
Recommendation — Inventory vCenter exposure and document the vulnerability as an active risk signal. Trigger incident handling steps when a KEV-listed flaw is exposed in production.
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	Confirmed exploitation makes timely identification and prioritisation of the flaw operationally necessary.
	SI-2 — Flaw Remediation	The core action is remediating a known exploited software flaw on a management platform.
Recommendation — Scan for exposed vCenter instances and track remediation until exposure is removed. Apply the vendor fix or mitigation and validate that the flaw is no longer reachable.

Practitioner Guidance

What to verify: Confirm whether any vCenter Server instance is reachable from untrusted networks, then validate whether that reachability is truly required. If the platform is exposed beyond tightly controlled administrative networks, treat the issue as urgent even before you know whether abuse has occurred.

Decision rule: If the system is internet-facing or broadly reachable, prioritise containment and patching before deep forensic work. If patching is delayed, assume the attacker may be targeting the management plane itself, not just a single application service.

Practitioner takeaway: For vulnerabilities already listed in KEV, “is it exploited in the wild?” should be treated as a response trigger, not a research question, because confirmed exploitation changes both the urgency and the kind of evidence you need to collect.

Deepen Your Knowledge

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org