Is CVE-2021-21975 (VMware Server Side Request Forgery in vRealize Operations Manager API) being exploited in the wild?

Yes. CISA added CVE-2021-21975 to its Known Exploited Vulnerabilities catalogue on 18 January 2022, which it does only when there is reliable evidence of active exploitation. CISA lists it as known to be used in ransomware campaigns. Server Side Request Forgery (SSRF) in vRealize Operations Manager API prior to 8.4 may allow a malicious actor with network access to the vRealize Operations Manager API to perform a SSRF attack to steal administrative credentials.

What the KEV Listing Means for This CVE

CISA’s KEV listing is the practical signal that matters here: it indicates a vulnerability is not just theoretically exploitable, but has credible evidence of active abuse. For operators, that changes the question from “should we patch eventually?” to “have we confirmed exposure and removed the attack path yet?” The right source of truth for status is the CISA KEV catalogue, alongside the vendor advisory for product-specific remediation.

Because this flaw is in an API surface, the first operational task is to identify every reachable vRealize Operations Manager instance and verify whether any deployment still matches the vulnerable product family described in the advisory. If you only inventory the central platform and not exposed management endpoints, you can miss the system an attacker would actually target.

For background and triage context, see the CISA Known Exploited Vulnerabilities Catalog and the CVE Program.

Why SSRF in an Admin API Becomes a Practical Intrusion Path

server side request forgery is dangerous when the vulnerable service can reach internal endpoints or trusted metadata services that an external actor cannot contact directly. In this case, the direct answer notes the potential theft of administrative credentials, which is the key operational consequence: SSRF can convert a web request into an internal trust bypass and then into authenticated access.

The usual failure mode is that the service is allowed to make requests on behalf of the caller without sufficiently restricting destinations, schemes, or headers. Once that happens, the attacker is no longer limited to the original API surface and can pivot toward internal-only resources, management interfaces, or credential-bearing endpoints.

This is why SSRF in infrastructure and management products is often treated as a trust-boundary issue, not just an input-validation bug. A management plane that can be made to fetch arbitrary URLs can become a bridge into the environment it is supposed to protect.

See the SSRF Prevention Guide for the defensive controls most relevant to this attack pattern.

For a closely related real-world example of SSRF leading to credential exposure, review Capital One breach 2019.

What to Confirm, Fix, and Hunt for if Patching Has Not Happened Yet

Confirm whether any instance is internet-facing or reachable from untrusted networks, then verify whether the vendor’s fixed release or mitigation has actually been applied everywhere. If patching is delayed, treat exposure as active risk: restrict network access, block risky outbound destinations where possible, and reduce the service’s ability to reach internal addresses that should never be user-controlled.

Because the direct answer indicates administrative credentials may be stealable, look for signs that those credentials were already used elsewhere. That includes unusual login times, new admin sessions, unexpected configuration changes, and access from source networks that do not match normal operator behavior.

If your environment uses credential stores, session tokens, or shared admin accounts around this platform, rotate anything that could plausibly have been exposed through the management interface. The point is to remove attacker value from the compromise path, not only to close the vulnerability itself.

For broader vulnerability triage and post-patch verification workflow, the Zero-Day and Exploited Vulnerabilities Guide and Vulnerability Management Guide are the most useful internal references. For a practitioner framework on SSRF abuse across application classes, see the Web Application Attacks Guide.

Risk and Threat Considerations

KEV inclusion means the risk is not hypothetical. An attacker who can reach the API may use SSRF to reach internal services, harvest administrative credentials, and then move into management functions that were never meant to be exposed externally.

Failure mechanism: The vulnerable API accepts attacker-controlled request targets and relays those requests from a trusted network position, which can expose internal endpoints or credential-bearing resources to abuse.

Impact: A successful exploit can result in administrative compromise, unauthorized configuration changes, broader environment access, and in some cases follow-on ransomware activity if the compromised credentials unlock more systems.

Standards & Framework Alignment

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

OWASP API Security Top 10 addresses the attack and risk surface, while CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP API Security Top 10	API7 — Server Side Request Forgery	The subject is an exploited API SSRF vulnerability.
Recommendation — Harden API request handling to block attacker-controlled outbound fetches.
CIS Controls v8	CIS-4 — Secure Configuration of Enterprise Assets and Software	Exploitation depends on exposed, misconfigured management endpoints.
Recommendation — Restrict exposure and harden the affected platform configuration.
NIST SP 800-53 Rev 5	SI-10 — Information Input Validation	SSRF is enabled by insufficient validation of request targets.
	AC-4 — Information Flow Enforcement	SSRF abuses unintended flows from a trusted service to internal resources.
	IA-5 — Authenticator Management	The exploit may expose administrative credentials that need lifecycle control.
Recommendation — Validate and constrain external request inputs before the server issues them. Enforce information flow restrictions on outbound and internal request paths. Rotate exposed authenticators and revoke any suspicious sessions promptly.

Practitioner Guidance

What to prioritise: Treat exposed instances as high urgency until you have confirmed patch status, network restriction, and compromise assessment. If the platform is reachable from untrusted networks, prioritise containment before long investigation cycles.

What to verify: Validate whether administrative credentials, sessions, or service access linked to the platform were reused elsewhere after the KEV date. A clean patch without credential review can leave the attacker’s original access path intact.

Practitioner takeaway: For KEV-listed SSRF in a management API, the operational question is not only whether the bug is fixed, but whether the trust boundary and any exposed credentials have been fully retired.