CVE-2021-21975

What it actually does

CVE-2021-21975 is a server-side request forgery vulnerability in the VMware vRealize Operations Manager API prior to version 8.4. An unauthenticated attacker with network access to the API can cause the server to make crafted outbound requests on the attacker’s behalf. Because those requests originate from the vRealize Operations Manager appliance, they may reach internal-only services or metadata endpoints that the attacker cannot access directly. The primary technical consequence is exposure of sensitive information, including administrative credentials, tokens, or internal service responses accessible from the server context.

Why it matters to the business

Successful exploitation can expose administrative credentials for VMware management infrastructure, giving attackers a path to compromise virtualization monitoring and management environments. Because VMware management platforms often have broad visibility into critical infrastructure, stolen credentials may enable follow-on access to privileged systems, service accounts, and operational data. This vulnerability is listed in CISA’s Known Exploited Vulnerabilities catalog, has been used in ransomware-related activity, and has a high EPSS score, so unpatched internet-accessible or broadly reachable deployments should be treated as high-priority remediation targets despite the vulnerability’s age.

How an attack unfolds

An attacker first identifies an exposed or reachable vRealize Operations Manager API endpoint running a vulnerable version prior to 8.4. They then send a crafted API request that abuses the SSRF flaw to instruct the appliance to connect to an internal URL or sensitive endpoint from the server side. Because the request is made by the appliance, network controls may allow access to resources that are not externally reachable. The attacker uses the server’s response to retrieve sensitive data, with the most concerning outcome being theft of administrative credentials. Those credentials can then be reused to authenticate to VMware management services, pivot deeper into the environment, alter monitoring visibility, or support ransomware staging and lateral movement.

How to fix it

Upgrade affected VMware products to fixed versions that include the vRealize Operations Manager 8.4 remediation or later supported releases. For VMware Cloud Foundation and vRealize Suite Lifecycle Manager deployments, apply the corresponding VMware-recommended updates or bundles that remediate the embedded or managed vRealize Operations Manager component. If immediate upgrade is not possible, restrict network access to the vRealize Operations Manager API to trusted administrative networks only, block internet exposure, enforce firewall allowlists, and monitor or block unexpected outbound connections from the appliance to internal metadata services and sensitive management endpoints. Rotate any administrative credentials, service account passwords, and API tokens that may have been exposed from vulnerable systems, especially where exploitation is suspected. Because this issue is in the KEV catalog and associated with ransomware activity, compensating controls should be considered temporary only.

How to confirm the fix worked

Confirm all vRealize Operations Manager instances are running version 8.4 or later, or a vendor-supported fixed release included in VMware Cloud Foundation or vRealize Suite Lifecycle Manager updates. Validate that the API is not reachable from untrusted networks by performing external and internal network exposure checks. Review firewall and proxy policy to ensure only approved administrative sources can reach the service and that the appliance cannot freely access sensitive internal endpoints unless required. Where available, use VMware product inventory, appliance build information, and vulnerability scanners with authenticated checks to verify remediation. After patching, test that known SSRF request patterns are rejected or no longer cause server-side fetches, and confirm no unexpected outbound requests are generated by the appliance during validation.

Typical attack path

1. Discover a VMware vRealize Operations Manager, vRealize Suite Lifecycle Manager, or VMware Cloud Foundation deployment exposing the vRealize Operations Manager API.
2. Confirm the target is running a vulnerable version prior to vRealize Operations Manager 8.4 or is part of an unpatched bundled VMware stack.
3. Send crafted unauthenticated API requests that cause the server to fetch attacker-specified internal URLs.
4. Use SSRF responses to access internal-only services, credential stores, metadata endpoints, or administrative interfaces reachable from the appliance.
5. Extract administrative credentials, tokens, or sensitive internal service responses.
6. Use stolen credentials for follow-on access to VMware management infrastructure or other privileged systems.
7. Perform post-exploitation actions such as reconnaissance, persistence, lateral movement, data theft, or ransomware deployment.

How to detect it

Investigate both inbound API access to vRealize Operations Manager and outbound connections initiated by the appliance. Review vRealize Operations Manager application/API logs, web access logs, reverse proxy logs, WAF events, firewall logs, DNS logs, EDR telemetry, and outbound proxy records. Look for unauthenticated or unusual API calls followed by the appliance making HTTP or HTTPS requests to internal-only addresses, loopback addresses, link-local metadata addresses, cloud metadata services, or sensitive management endpoints. Pay particular attention to requests containing full URLs, encoded URLs, host override parameters, redirects, or references to 127.0.0.1, localhost, 169.254.169.254, RFC1918 address ranges, or unusual internal ports. Because the vulnerability can result in credential theft, correlate suspicious SSRF activity with subsequent successful administrative logins, new sessions from unusual source IPs, new API tokens, password changes, configuration exports, failed authentication bursts, and access to VMware management interfaces. In environments where exploitation is suspected, preserve appliance logs and network telemetry, rotate credentials, and hunt for follow-on activity consistent with ransomware staging, lateral movement, or privilege escalation.

• 169.254.169.254
• metadata.google.internal
• metadata/instance
• latest/meta-data
• 127.0.0.1
• localhost
• http://127.0.0.1
• https://127.0.0.1
• http://localhost
• https://localhost
• http://169.254.169.254
• https://169.254.169.254
• file://
• gopher://
• dict://
• ftp://
• @127.0.0.1
• @localhost
• %31%32%37%2e%30%2e%30%2e%31
• %6c%6f%63%61%6c%68%6f%73%74
• %31%36%39%2e%32%35%34%2e%31%36%39%2e%32%35%34

What your security team should do

• Immediately inventory VMware vRealize Operations Manager, VMware Cloud Foundation, and vRealize Suite Lifecycle Manager deployments and identify any instances running vRealize Operations Manager prior to 8.4.
• Prioritize remediation for internet-facing, partner-accessible, VPN-accessible, or broadly internally reachable API endpoints.
• Upgrade to vRealize Operations Manager 8.4 or later, or the applicable fixed VMware bundle for Cloud Foundation and vRealize Suite Lifecycle Manager.
• Restrict vRealize Operations Manager API access to trusted administrative networks and enforce firewall allowlisting.
• Review historical access logs, reverse proxy logs, WAF logs, and outbound network telemetry for SSRF-like requests and unusual appliance-initiated connections.
• Rotate administrative credentials, service account passwords, and API tokens associated with affected deployments if exposure or exploitation cannot be ruled out.
• Add detections for suspicious outbound HTTP/HTTPS requests originating from vRealize Operations Manager appliances to internal metadata, loopback, link-local, and management addresses.
• Treat confirmed exploitation as a credential compromise event and perform incident response across VMware management infrastructure and dependent systems.
• Track this vulnerability under KEV-driven remediation governance; CISA’s remediation due date was 2022-02-01 and the issue remains actively exploited in the wild.