How do you patch or mitigate CVE-2021-22054 (Omnissa Workspace ONE Server-Side Request Forgery)?

CISA’s required action for CVE-2021-22054 is to apply mitigations per vendor instructions, follow applicable BOD 22-01 guidance for cloud services, or discontinue use of the product if mitigations are unavailable. In practice, find every instance of Omnissa Workspace One UEM 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.

What CVE-2021-22054 means for your response plan

This is a server-side request forgery issue in Omnissa Workspace ONE UEM, so the practical question is not just whether the CVE exists, but whether the vulnerable service is reachable and what it can reach on your behalf. Treat it as an exposure problem first: identify every deployed instance, confirm whether the service can make outbound requests to internal or cloud metadata targets, and decide whether the product can stay online safely while you remediate.

For a published vulnerability like this, the key operational distinction is between systems that are merely installed and systems that are actually exposed to untrusted input or reachable from the internet. That is why emergency handling should start with scope and reachability, then move to the vendor fix or documented mitigation. The SSRF Prevention Guide is useful here because the same controls that block classic SSRF, such as request allowlisting and egress filtering, are also the ones that limit blast radius if patching is delayed.

How to mitigate while keeping the service under control

The safest path is to apply the vendor security update or the documented vendor mitigation as soon as you confirm exposure. If you cannot patch immediately, reduce the reachable attack surface: remove internet exposure, restrict ingress to trusted administration paths, and prevent the affected component from making arbitrary outbound requests to internal services. Where the product is part of a wider web stack, pair the fix with an inventory check so you do not leave a second exposed deployment behind.

When you are deciding whether a temporary workaround is enough, use the same standard you would use for any actively exploited or high-risk web flaw. The Zero-Day and Exploited Vulnerabilities Guide gives the right triage model for emergency mitigation, while the Vulnerability Management Guide helps you turn that decision into an asset-scoped remediation workflow with verification and exception handling.

If the vendor fix or mitigation cannot be applied in time, discontinuing use of the product is the correct fallback, especially when the instance is internet-facing or cannot be adequately segmented. In practice, that means disabling or isolating the service before you accept open-ended risk, rather than keeping a vulnerable deployment online and hoping the attack path is obscure.

What to check after patching or containment

Patch or mitigation does not end the job. Because SSRF often turns into internal reachability abuse, you should check for signs that the vulnerable service was used to probe metadata services, internal admin panels, or other non-public endpoints before the fix. Review proxy, web, and application logs for unusual outbound request patterns, unexpected destination hosts, and spikes in requests that originated from the Workspace ONE component.

For deeper validation, compare the service’s observed behaviour before and after the change and confirm that the mitigation actually blocks the relevant request path rather than only the known proof of concept. The Capital One breach 2019 is a useful reminder that SSRF can become a credential or metadata exposure issue, so post-fix review should include any cloud or internal credentials that might have been reachable through the vulnerable path.

If you find evidence that the system was used for reconnaissance or credential access, treat the event as a possible compromise investigation, not just a patching ticket. That is the point at which log review, containment, and any necessary credential or session rotation become part of the response, not an optional follow-up.

Risk and Threat Considerations

SSRF matters because it can convert a public-facing application into a proxy for reaching internal services that were never meant to be internet-accessible. In a product that sits near identity, device, or cloud administration flows, that can create a path to sensitive internal endpoints, metadata services, or privileged control planes if the vulnerable component can be induced to fetch attacker-chosen URLs.

Failure mechanism: An attacker sends a crafted request that causes the Workspace ONE server to make an outbound request on the attacker’s behalf, then uses that internal reachability to enumerate services, access metadata, or harvest trust material that should not be exposed externally.

Impact: The result can range from internal service discovery to credential exposure, lateral movement, and broader environment compromise, especially if the application is allowed to reach management networks or cloud metadata endpoints.

Standards & Framework Alignment

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

CIS Controls v8, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	This CVE requires rapid identification and remediation of exposed instances.
Recommendation — Prioritise, patch, and verify remediation of exposed Workspace ONE instances.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	The question is about patching or mitigating a known software flaw.
	SC-7 — Boundary Protection	SSRF mitigation depends on restricting outbound and cross-boundary requests.
	AU-6 — Audit Record Review, Analysis, and Reporting	Post-fix validation requires checking logs for exploitation or probing.
Recommendation — Apply vendor remediation promptly and confirm the flaw is removed or contained. Restrict egress and isolate the service from internal and metadata targets. Review logs for outbound request abuse and signs of pre-patch compromise.
OWASP ASVS	V4 — API and Web Service	SSRF is a web-service abuse pattern that depends on server-side request handling.
Recommendation — Validate server-side request controls and block attacker-influenced destinations.

Practitioner Guidance

What to verify: Confirm whether each deployed Workspace ONE instance is internet-facing, whether the vendor fix or mitigation is actually applied, and whether outbound access from the service is still broader than it needs to be. If you cannot verify all three, treat the deployment as still at risk.

Decision rule: If patching is available, patch first and then validate blocked request paths; if patching is delayed, remove exposure or isolate the service before accepting business continuity risk. Do not keep an unpatched SSRF-affected service publicly reachable just because the exploitation path is not yet observed.

Practitioner takeaway: The real control objective is not merely installing a fix, but making sure the vulnerable service cannot be used as a bridge from untrusted input to internal trust boundaries.