Yes. CISA added CVE-2021-22054 to its Known Exploited Vulnerabilities catalogue on 9 March 2026, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Any organisation running the affected product should treat remediation as urgent. Check exposure first, then patch or mitigate, then review logs for signs of earlier compromise.
What “exploited in the wild” means for this CVE
For this question, the key point is not whether the flaw is theoretically dangerous, but whether there is credible evidence of active abuse. CISA’s KEV listing is the strongest operational signal that exploitation is happening, so the right working assumption is that this vulnerability should be handled as a live exposure until you prove otherwise.
That changes the response timeline. Treat the issue as an urgent asset-discovery and remediation problem, not as a routine patch-cycle item. Start by confirming whether any internet-facing or internally reachable Omnissa Workspace ONE instances are present, then verify whether they are affected, and only then decide whether patching, isolation, or temporary mitigation is the fastest safe path.
Because the vulnerability is server-side request forgery, the security concern is not just service disruption. SSRF often becomes a path to internal service reach, metadata access, or trust-boundary abuse, so the practical question is what the application can reach if an attacker can steer its outbound requests. SSRF prevention guidance is relevant here because it explains why outbound allowlisting, URL validation, and metadata-service protections matter when SSRF is the initial entry point.
How to confirm exposure and reduce risk fast
The first decision is whether you have the vulnerable product anywhere in scope, including older deployments, shadow instances, and systems that are no longer actively managed. If the answer is yes, treat the environment as exposed until proven otherwise. Prioritise external reachability, exposed administration surfaces, and any instance that can make arbitrary outbound requests to internal networks or cloud services.
If patching is delayed, the best temporary mitigation is to reduce the exploit path rather than waiting for perfect certainty. Restrict inbound access, limit outbound network destinations, harden any proxy or URL-fetch features, and review whether the application can reach sensitive internal endpoints. For broader triage discipline, Zero-Day and Exploited Vulnerabilities Guide is useful because it frames KEV-style response as emergency prioritisation, not ordinary backlog handling.
Where the product is used as a management or access platform, the blast radius can be larger than the initial flaw suggests. A compromised management server can expose credentials, session material, or internal administrative pathways. That is why teams should not stop at patch status alone, they should also assess what the server could have reached before remediation. Vulnerability Management Guide supports that workflow because it ties prioritisation to verification, exceptions, and post-remediation validation.
What to check after remediation
Once the vulnerable instance is isolated or fixed, check for signs that the flaw was used before you responded. Focus on unusual outbound connections, unexpected URL fetch activity, access to internal or link-local endpoints, suspicious admin actions, new accounts or sessions, and any evidence that the server was used as a pivot point. If logs are incomplete, treat that as a detection gap, not as proof that nothing happened.
If you find evidence of exposure, review adjacent systems that may have been reachable through the server, especially anything holding privileged sessions, API material, or internal service credentials. In SSRF cases, post-compromise review matters because the initial flaw often exists only to open the door to a broader trust-boundary violation. A concrete example of that attack pattern is documented in Capital One breach 2019, which remains relevant as a reminder that SSRF can expose high-value downstream trust material.
Risk and Threat Considerations
SSRF is dangerous because it lets an attacker make the vulnerable server act as a proxy into systems that were never meant to be directly reachable. In a management platform, that can mean internal APIs, metadata services, or administrative interfaces. The practical risk is not only data exposure, but also expansion of access into systems the attacker could not otherwise contact.
Failure mechanism: The attacker supplies or influences a request target, and the server performs the outbound request on their behalf, crossing an internal trust boundary.
Impact: That can expose internal services, harvest credentials or tokens from reachable endpoints, and create a pivot into broader environment compromise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST SP 800-53 Rev 5, OWASP ASVS and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.RA-01 — Asset Vulnerability Identification | The question requires confirming exposure to a known exploited vulnerability. |
| PR.PS-02 — Vulnerability Management | The response centers on urgent patching or mitigation for an actively exploited flaw. | |
| DE.CM-01 — Network and Environment Monitoring | Post-remediation review depends on detecting suspicious outbound and pivot activity. | |
| Recommendation — Identify exposed instances and rank them for urgent remediation. Apply emergency remediation or compensating controls for the affected system. Monitor logs and network telemetry for signs of exploitation. | ||
| NIST SP 800-53 Rev 5 | SI-2 — Flaw Remediation | An actively exploited CVE requires prompt remediation and verification. |
| AU-6 — Audit Record Review, Analysis, and Reporting | The answer explicitly advises reviewing logs for earlier compromise. | |
| SC-7 — Boundary Protection | SSRF exploitation abuses trust boundaries and outbound reachability. | |
| Recommendation — Remediate the flaw promptly and validate the fix on affected systems. Review audit records for suspicious activity around the exposure window. Restrict outbound and boundary traffic to reduce SSRF blast radius. | ||
| OWASP ASVS | V4 — API and Web Service | SSRF is a web service abuse condition that depends on unsafe server-side request handling. |
| V13 — Configuration | Temporary mitigation often depends on hardening network and service configuration. | |
| Recommendation — Validate and constrain server-side requests to trusted destinations. Harden request handling and network configuration around the vulnerable service. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | The subject is an actively exploited vulnerability that needs urgent prioritization. |
| CIS-13 — Network Monitoring and Defense | Detecting exploitation requires network and log visibility into suspicious request patterns. | |
| Recommendation — Prioritise, remediate, and verify exposed vulnerabilities quickly. Use telemetry to detect abnormal outbound requests and internal reach attempts. | ||
Practitioner Guidance
What to prioritise: Treat confirmed KEV status as a trigger for emergency handling. Confirm whether the product is present, whether it is internet-facing, and whether it can reach sensitive internal destinations before you spend time on low-value analysis.
What to verify: After mitigation, verify not just that the product is patched or isolated, but that logs cover the period when exploitation may have occurred. If logging is weak, compensate with network telemetry, authentication review, and checks on adjacent systems.
Practitioner takeaway: For an exploited SSRF CVE, the real work is proving blast radius and compromise history, because patching alone does not answer what the vulnerable server may already have exposed.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org