Join our Newsletter — 33% off our NHI Course

How do you patch or mitigate CVE-2021-21975 (VMware Server Side Request Forgery in vRealize Operations Manager API)?

CISA’s required action for CVE-2021-21975 is to apply updates per vendor instructions. In practice, find every instance of VMware vRealize Operations Manager API in your estate, apply the vendor security update or documented mitigation, and if no fix can be applied, remove internet exposure or take the product out of service. After patching, review logs for signs of earlier exploitation, because attackers used this flaw in the wild.

What to do first when CVE-2021-21975 is in your environment

The first step is exposure confirmation, not broad patching by assumption. Identify every VMware vRealize Operations Manager API instance, confirm whether it is reachable from untrusted networks, and determine whether the vendor update or documented mitigation can be applied cleanly in each case. For exploited vulnerabilities, speed matters more than perfect sequencing.

Use the vendor advisory as the source of truth for the exact update path, then verify that the affected API surface is no longer reachable in the exposed configuration. If the fix cannot be applied immediately, reduce exposure by removing internet access, restricting the network path, or taking the product out of service until the supported remedy is in place.

How to reduce the chance of recurrence after mitigation

Once the immediate exposure is closed, treat this as an asset inventory and patch governance problem as much as a vulnerability event. Confirm that vRealize Operations Manager API deployments are tracked in your inventory, that emergency changes are recorded, and that future updates can be deployed quickly enough to keep pace with known exploited vulnerabilities. The practical control is not just patch availability, but repeatable reachability and upgrade decisions.

Where the product has business-critical dependencies, decide in advance which systems can be isolated, which can be temporarily disabled, and who has authority to accept downtime in exchange for stopping a known exploit path. That decision should be documented before the next emergency, not during it.

What to check for signs of earlier exploitation

Because this issue was used in the wild, post-mitigation review should focus on evidence of access rather than only on successful patch completion. Review relevant logs for suspicious API requests, unusual outbound connections, unexpected administrative activity, and any follow-on access that could indicate the SSRF primitive was used to reach internal services or metadata endpoints. If logs are incomplete, treat that as a visibility gap, not as reassurance.

When review findings are ambiguous, prioritize the systems reachable from the vulnerable API and any downstream assets that could have been accessed through it. If you cannot prove the absence of abuse, narrow the blast radius by rotating any exposed credentials, sessions, or service access material that may have been reachable through the vulnerable path.

Risk and Threat Considerations

SSRF flaws are dangerous because they let an attacker make the server talk to resources the attacker should not directly reach. In a management plane product, that can turn an externally reachable API into a pivot point for internal network access, metadata retrieval, or other trusted-request abuse.

Failure mechanism: The vulnerable API accepts attacker-controlled requests and relays them to internal or otherwise protected destinations, which can bypass network segmentation and trust assumptions.

Impact: The result can be internal reconnaissance, credential exposure, lateral movement, or further compromise of management infrastructure, especially when the product sits close to privileged 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
CIS Controls v8 CIS-7 — Continuous Vulnerability Management CVE patching and mitigation are classic vulnerability management work.
Recommendation — Track, prioritize, and remediate the exposed VMware instance quickly.
NIST SP 800-53 Rev 5 RA-5 — Vulnerability Monitoring and Scanning The answer hinges on finding exposed instances and validating remediation.
SI-2 — Flaw Remediation This CVE requires vendor-directed updates or documented mitigations.
SC-7 — Boundary Protection Removing internet exposure is a direct mitigation when patching must wait.
Recommendation — Scan for every vRealize Operations Manager API instance and confirm remediation. Apply the vendor update or approved mitigation without delay. Restrict or isolate the exposed API until remediation is complete.
OWASP API Security Top 10 API7 — Server Side Request Forgery The vulnerability is an API SSRF condition, so SSRF defenses are central.
Recommendation — Block server-side fetches to untrusted destinations and validate outbound targets.

Practitioner Guidance

What to prioritise: Patch or mitigate the exposed management interface before spending time on deeper root-cause analysis. If the system is internet-facing, assume the exploit window is already material and close that path first.

What to verify: Confirm the product is either updated per the vendor instruction or genuinely isolated from untrusted access. Also verify that logging is sufficient to support a retrospective check, because weak visibility can leave compromise status unresolved.

Decision rule: If you cannot apply the fix immediately, do not leave the service in a partially trusted state. Restrict access aggressively, or remove the product from service until the supported remediation is complete.

Practitioner takeaway: For exploited SSRF vulnerabilities, the right sequence is exposure removal, supported remediation, then compromise assessment, because delaying the first two steps only preserves the attacker’s best access path.