CVE-2021-22054

What it actually does

This is an unauthenticated server-side request forgery vulnerability in VMware Workspace ONE UEM console. An attacker with network access to the UEM console can cause the server to send crafted HTTP requests on the attacker’s behalf without authenticating. Because those requests originate from the trusted UEM server, they may reach internal services, cloud metadata endpoints, loopback interfaces, administrative APIs, or other network locations that are not directly reachable by the attacker. The primary technical consequence is high-impact information disclosure; the CVSS vector indicates no direct integrity or availability impact, but exposed credentials, tokens, configuration data, or internal service responses can enable follow-on compromise.

Why it matters to the business

Successful exploitation can expose sensitive operational data from a device-management platform that often has broad visibility into enterprise endpoints, users, certificates, enrollment settings, and integrations. If secrets or internal service data are retrieved, attackers may use them to pivot into adjacent systems or cloud services. The vulnerability is listed in CISA KEV with a remediation due date of 2026-03-23 and has very high EPSS likelihood with active in-the-wild exploitation, so internet-facing or broadly reachable UEM consoles should be treated as urgent remediation priorities even though the issue is older.

How an attack unfolds

An attacker first identifies a reachable VMware Workspace ONE UEM console running an affected build. Because the flaw does not require authentication, the attacker sends a specially crafted request to a vulnerable server-side fetch or proxy-like function exposed by the console. The UEM server processes the attacker-controlled destination and initiates outbound requests from the server’s own network context. The attacker then uses the responses, timing behavior, or error differences to enumerate reachable internal addresses and retrieve sensitive information from internal web services, cloud metadata endpoints, localhost-only services, or administrative APIs. If credentials, tokens, certificates, or configuration secrets are exposed, the attacker can use them outside the original SSRF path for broader access. Public reporting and KEV status indicate this vulnerability has been exploited in the wild, including activity tracked around Omnissa/Workspace ONE SSRF exploitation.

How to fix it

Upgrade VMware Workspace ONE UEM console to a fixed build or later: 20.0.8 must be upgraded to 20.0.8.37 or later, 20.11.0 to 20.11.0.40 or later, 21.2.0 to 21.2.0.27 or later, and 21.5.0 to 21.5.0.37 or later. Where the listed Maven BOM packages are present in downstream software inventories, update com.liferay.portal/release.dxp.bom to 7.2.10.fp13 or 7.3.10.fp2 or later, and com.liferay.portal/release.portal.bom to 7.4.2-ga3 or later. If immediate upgrade is not possible, restrict network access to the UEM console to trusted administrative networks or VPN, block unauthenticated internet access, enforce WAF or reverse-proxy filtering for suspicious server-side fetch patterns, and restrict egress from the UEM server to only required destinations. Add network-level controls to prevent the UEM server from reaching cloud metadata services, loopback-only administrative services, and unnecessary internal address ranges. Rotate any credentials, API tokens, or certificates that may have been exposed if exploitation is suspected.

How to confirm the fix worked

Confirm the running Workspace ONE UEM console version and build number is at or above the fixed release for the deployed branch. Validate from asset inventory, vendor console version pages, package manifests, and change-management records rather than relying only on external banners. For Maven-tracked components, verify dependency resolution with dependency-tree or software composition analysis output and confirm the fixed BOM versions are in use. Conduct an authorized SSRF validation using a benign canary/collaborator URL to confirm the console no longer makes attacker-controlled outbound requests. Review firewall or egress logs to verify the UEM server cannot reach unnecessary internal ranges, localhost-equivalent destinations, or cloud metadata endpoints. Finally, rescan externally exposed assets and confirm the UEM console is not reachable from untrusted networks unless explicitly required and protected.

Typical attack path

1. Scan for exposed VMware Workspace ONE UEM console instances and fingerprint affected versions or behavior.
2. Send unauthenticated crafted requests that cause the UEM server to initiate outbound server-side HTTP requests.
3. Probe loopback, RFC1918/private IP ranges, cloud metadata addresses, and internal service ports from the UEM server’s network position.
4. Extract sensitive responses such as tokens, service metadata, configuration data, certificates, or internal API output where accessible.
5. Use any retrieved credentials or internal knowledge to pivot to cloud services, management APIs, identity systems, or other internal applications.
6. Cover tracks by blending requests with normal web traffic or using varied destination hosts and timing.

How to detect it

To determine whether exploitation already occurred, correlate inbound UEM console access logs, reverse-proxy logs, WAF events, application logs, outbound firewall/proxy logs, DNS logs, and cloud audit logs. Look for unauthenticated requests to the UEM console that are immediately followed by outbound connections from the UEM server to unusual destinations such as 169.254.169.254, localhost/127.0.0.1, ::1, RFC1918 private IPs, link-local addresses, internal hostnames, administrative ports, or cloud metadata hostnames. Investigate repeated 400/403/500 responses, timeouts, URL parsing errors, redirect chains, or requests containing full URLs as parameter values. Review outbound proxy logs for the UEM server accessing destinations that are not part of normal Workspace ONE integrations. If cloud metadata endpoints or internal secret/configuration services were contacted, inspect cloud IAM, API gateway, identity provider, and management-plane logs for subsequent use of newly exposed tokens or credentials. Because no unique public exploit path is provided in the supplied intelligence, detections should combine SSRF destination indicators with the source being the UEM server and the timing of suspicious unauthenticated inbound requests.

• 169.254.169.254
• metadata.google.internal
• metadata.azure.com
• 100.100.100.200
• 127.0.0.1
• localhost
• ::1
• 0.0.0.0
• [::]
• file://
• gopher://
• dict://
• ftp://
• http://169.254.169.254/latest/meta-data/
• http://169.254.169.254/metadata/instance
• /latest/meta-data/iam/security-credentials/
• Metadata-Flavor: Google
• Metadata: true

What your security team should do

• Treat this as a high-priority remediation item because it is in CISA KEV, has active in-the-wild exploitation, and has a very high EPSS probability.
• Patch all affected Workspace ONE UEM console branches to the fixed builds or later, prioritizing internet-facing and partner-accessible deployments.
• Restrict access to UEM administrative interfaces to trusted networks and enforce strong reverse-proxy, VPN, or zero-trust access controls.
• Implement tight egress controls from UEM servers, including blocks for cloud metadata endpoints, loopback targets, link-local ranges, and unnecessary RFC1918 destinations.
• Hunt historical UEM, proxy, WAF, DNS, and firewall logs for SSRF behavior and suspicious server-originated requests around and after the publication date.
• Rotate potentially exposed secrets if logs show suspicious access to metadata services, internal admin endpoints, or configuration APIs.
• Add detections for unauthenticated requests to UEM followed by unusual outbound connections from the UEM server to internal or metadata destinations.
• Track vendor advisories for Workspace ONE/Omnissa and ensure vulnerability-management records reflect the exact fixed build, not just the major release.