Join our Newsletter — 33% off our NHI Course
Home› FAQ› Threats, Abuse & Incident Response› Is CVE-2021-21973 (VMware vCenter Server and Cloud Foundation…
Threats, Abuse & Incident Response

Is CVE-2021-21973 (VMware vCenter Server and Cloud Foundation Server Side Request Forgery (SSRF)) being exploited in the wild?

← Back to all FAQ
By NHI Mgmt Group Editorial Team Updated October 19, 2026 Domain: Threats, Abuse & Incident Response

Yes. CISA added CVE-2021-21973 to its Known Exploited Vulnerabilities catalogue on 7 March 2022, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. VMware vCenter Server and Cloud Foundation Server contain a SSRF vulnerability due to improper validation of URLs in a vCenter Server plugin.

How to interpret active exploitation for CVE-2021-21973

For a practitioner, the key point is that KEV inclusion changes the question from “is this a vulnerability?” to “have we confirmed whether our environment is exposed and still reachable?” For vCenter Server and Cloud Foundation, SSRF can be more than a generic web flaw because it may be used as an internal pivot into trusted services, metadata endpoints, or adjacent management surfaces.

When a vulnerability is being exploited in the wild, exposure checks matter as much as patch status. Use the vendor advisory and the CISA Known Exploited Vulnerabilities Catalog to confirm whether any internet-facing, partner-facing, or internally reachable vCenter instance is in scope, then treat any positive finding as an incident-priority item rather than a routine maintenance task.

SSRF is especially relevant here because the flaw sits in a product that often has high trust and broad network reach. If an attacker can cause the server to make requests on their behalf, the real risk is not just the initial request, but what internal destinations, tokens, or metadata services may become reachable through that trusted path.

What this means for vCenter exposure and containment

The immediate question is whether the affected platform can reach sensitive internal resources from the vulnerable component. For VMware management planes, that can include management network segments, internal APIs, and in some deployments cloud metadata or other privileged endpoints that were never meant to be reachable from an application plugin.

Containment should focus on reducing the value of the SSRF path even before patching is complete. The practical objective is to narrow egress, block obvious metadata destinations, and verify that the vulnerable interface is not exposed beyond the smallest necessary admin boundary.

Because vCenter is a control-plane asset, the blast radius is often larger than the application itself. A successful SSRF condition can turn a single request into broad visibility into internal topology, service responses, or downstream authenticated requests that the attacker would not otherwise be able to make.

What to do if patching must wait

When patching cannot happen immediately, use compensating controls that reduce both exploitability and reach. A secure temporary posture is one where the vulnerable service is reachable only from trusted administration paths, outbound requests are restricted as tightly as operationally possible, and no unnecessary internal services are reachable from the affected component.

At the same time, review logs for signs that the platform made unusual outbound requests, accessed unexpected hostnames, or interacted with local or cloud metadata endpoints. For SSRF issues, compromise assessment should look for more than web traffic anomalies, because the attacker’s goal is often to use the server as a proxy into something more sensitive.

If the environment uses the vulnerable system to access other assets with privileged trust, consider whether those downstream sessions or tokens should be rotated after remediation. That is especially important when the flaw may have exposed short-lived credentials, internal service responses, or management-plane tokens.

Standards & Framework Alignment

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

MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
CIS Controls v8CIS-7 — Continuous Vulnerability ManagementActive exploitation makes rapid prioritisation and remediation central to this CVE.
Recommendation — Prioritise and remediate KEV-listed vulnerabilities immediately on exposed systems.
NIST SP 800-53 Rev 5SI-2 — Flaw RemediationThe answer depends on timely remediation of a known exploitable flaw.
SC-7 — Boundary ProtectionSSRF risk is driven by control over internal and external request paths.
Recommendation — Remediate the vulnerability promptly and track exceptions until closure. Restrict outbound and boundary traffic from the vulnerable service to approved destinations.
OWASP ASVSV4 — API and Web Service SecuritySSRF is a web-service attack pattern against server-side request handling.
Recommendation — Validate server-side request targets and block unsafe outbound requests.
MITRE ATT&CKT1190 — Exploit Public-Facing ApplicationCVE-2021-21973 is an exploited server-side application weakness that can be used for initial access.
Recommendation — Hunt for exploit attempts against the public-facing service and associated logs.

Practitioner Guidance

What to prioritise: Treat KEV-listed exposure as a triage driver. First confirm where the vulnerable VMware components are reachable, then decide whether the bigger risk is internet exposure, lateral movement from a trusted segment, or downstream access to management-plane resources.

What to verify: Confirm that the vulnerable path cannot be used to reach internal-only destinations, metadata services, or other privileged request targets. If you can only verify patching but not request containment, you do not yet have a complete risk picture.

Decision rule: If the system can make outbound requests to sensitive internal endpoints, prioritise containment and post-exploitation review alongside remediation. If it cannot, the operational urgency is still high because active exploitation evidence means exploit attempts are already happening in the wild.

Practitioner takeaway: For exploited SSRF in a control-plane product, the important question is not whether the CVE exists, but whether the trusted server path can still be used to reach something more privileged than the attacker should ever see.

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