CVE-2021-21975: VMware Server Side Request Forgery in vRealize Operations Manager API

CVE-2021-21975 is a server-side request forgery (SSRF) weakness in the VMware vRealize Operations Manager API. An attacker who can reach that API over the network may abuse it to steal administrative credentials. CISA notes known ransomware use, so organizations running this product should treat exposure as high priority and confirm all version and fix details against the vendor advisory.

The flaw affects the vRealize Operations Manager API prior to 8.4. Because the product is commonly used to monitor and manage virtual infrastructure, successful abuse can give an attacker a path to privileged credentials and broader environment access.

How it works

This vulnerability is classified as CWE-918 (Server-Side Request Forgery). In an SSRF flaw, the application accepts a request from a client and then makes a further request to a URL or internal resource chosen or influenced by that client, without adequate validation.

According to the CISA summary, a malicious actor with network access to the vRealize Operations Manager API can perform an SSRF attack that results in theft of administrative credentials. The attacker does not necessarily need prior authentication to the management plane; network reachability to the API is the stated prerequisite. Exact request parameters and internal targets are not detailed here and must be confirmed against the vendor advisory; defenders should assume the API can be induced to contact internal services or metadata endpoints that hold or can reveal privileged credentials.

Am I affected? How to find it in your systems

vRealize Operations Manager is typically deployed in VMware environments as a management and monitoring appliance or cluster, often reachable from administrative jump hosts, monitoring networks, or broader data-center segments. Inventory every instance of vRealize Operations Manager and identify whether its API endpoint is network-accessible.

• Enumerate appliances, virtual machines, and clusters running vRealize Operations Manager; check build or version information against the vendor advisory (the CISA summary references versions prior to 8.4).
• Map network exposure: determine which subnets, VPN ranges, or partner connections can reach the API ports or reverse-proxy front ends.
• Review configuration management and CMDB records for “vROps,” “vRealize Operations,” or related management packs that may expose the same API surface.
• For exploitation signs, inspect API access logs, reverse-proxy logs, and web application firewall logs for unusual outbound request patterns originating from the vRealize Operations Manager host itself, unexpected internal destination addresses, or spikes in unauthenticated or anomalous API calls. Correlate with authentication logs for sudden use of administrative accounts after suspicious API activity. Specific indicators of compromise should be validated against vendor and CISA guidance.

How to remediate

Patch first. Apply the updates published by VMware for vRealize Operations Manager as directed in the vendor advisory and per CISA’s required action to apply updates per vendor instructions. Confirm that every instance has moved to a fixed release (the summary cites prior to 8.4 as affected; verify the exact fixed versions in the advisory).

• After patching, re-validate version strings and restart or redeploy services only as the vendor instructs.
• Rotate any administrative credentials that could have been exposed, especially service accounts and local admin passwords used by or stored for vRealize Operations Manager.
• Harden the API surface: restrict management interfaces to dedicated administrative networks, enforce strong authentication where supported, and disable any unused API features or integrations that increase attack surface for this class of flaw.
• Ensure outbound traffic from the appliance is limited to only required destinations so that even if SSRF is attempted, the blast radius is reduced.

If you can't patch immediately

Implement compensating controls until the vendor update can be applied.

• Network segmentation: place vRealize Operations Manager API endpoints behind strict firewall rules or zero-trust policies so that only a minimal set of jump hosts or management workstations can reach them. Block direct access from user VLANs, partner networks, and the internet.
• Virtual patching / WAF: if a web application firewall or reverse proxy sits in front of the API, apply rules that constrain request patterns commonly abused for SSRF (for example, blocking or alerting on attempts to supply internal or non-approved URLs). Tune carefully to avoid breaking legitimate monitoring functions; confirm rule guidance with the vendor where available.
• Disable or isolate non-essential API integrations and connectors until patched.
• Heighten monitoring: alert on anomalous outbound connections from the vRealize Operations Manager hosts, unusual API error rates, and any authentication events involving administrative accounts. Retain logs for forensic review.
• Credential hygiene: temporarily reduce the privilege level of accounts used by the product where operationally feasible, and prepare for rapid credential rotation once patching is complete.

If your data may have been exposed

Actively exploited vulnerabilities, including those with known ransomware use, frequently lead to credential theft and follow-on breaches. If your vRealize Operations Manager API was reachable by untrusted networks while unpatched, assume administrative credentials may have been targeted and proceed with incident response: isolate affected systems, rotate credentials, and hunt for lateral movement. You can also run a free exposure scan of your email addresses to check whether associated accounts appear in known breach data sets and take further action on any confirmed exposures.