CISA's required action for CVE-2022-22954 is to apply updates per vendor instructions. In practice, find every instance of VMware Workspace ONE Access and Identity Manager 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 CVE-2022-22954 Means Operationally
CVE-2022-22954 is not just a patch item, it is an exposed entry point into a perimeter-facing identity product. Treat it as an asset discovery and exposure problem first, because the right fix depends on whether the vulnerable service is reachable, internet-exposed, or already part of a larger access path.
Start by locating every VMware Workspace ONE Access and Identity Manager instance, then confirm whether each one is actually reachable from untrusted networks. For internet-facing deployments, the immediate question is whether you can safely reduce exposure before or while applying the vendor update.
Because the flaw is server-side template injection, the practical concern is arbitrary server-side execution or data access through the application layer. That means the remediation task is not only “apply a patch,” but also “remove the conditions that let a payload reach the template engine.”
How to Patch or Mitigate It Safely
The primary fix is to apply the vendor security update or documented mitigation exactly as directed. For this class of issue, the vendor advisory should drive the version decision, while the CISA Known Exploited Vulnerabilities catalog confirms the urgency and required action.
If patching is delayed, the best short-term mitigation is to remove internet exposure or take the product out of service until you can update it. That is the correct trade-off when a service is externally reachable and the exploit path is already known to be used in the wild.
Do not rely on partial hardening as a substitute for remediation. A network filter or reverse proxy can reduce risk, but if the application remains reachable, the safer posture is to combine exposure reduction with the vendor fix rather than treat one as equivalent to the other.
After the update, validate the service rather than assuming the change was enough. Confirm the product is running the expected patched state, the mitigation is still in place if you used one, and normal administrative and user flows continue to work without reintroducing the exposed interface.
What to Check After Exposure Has Been Reduced
Once the patch or mitigation is in place, review logs for signs of earlier exploitation. For a server-side template injection issue, that review should focus on unusual requests, unexpected template syntax, abnormal server responses, and any follow-on activity that suggests the application was used as an execution path.
Also check for secondary access effects. If the product handled authentication, sessions, tokens, or administrative workflows during the exposure window, assume the incident may have created broader compromise potential than the vulnerable endpoint itself.
That is why post-remediation validation should include both compromise hunting and access review. If there are signs the system was abused, the response may need to expand from vulnerability remediation into credential rotation, session invalidation, and broader containment.
Risk and Threat Considerations
This vulnerability matters because it sits in a product that often sits close to identity and access flows, which makes exploitation more valuable than a simple application bug. If the service is exposed to the internet, attackers can target it as an initial foothold and then use the application trust boundary to reach internal resources.
Failure mechanism: A malicious request can reach server-side template processing and turn the application into an execution or data-access path, especially where the service is reachable from untrusted networks and no compensating control blocks the request path.
Impact: The result can include compromise of the application host, theft of sensitive data, or use of the system as a stepping stone into adjacent identity and administrative functions. If exploitation occurred before patching, post-incident access paths may remain active even after the software is updated.
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 CSF 2.0 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 | This CVE requires asset discovery, patching, and verification across the estate. |
| Recommendation — Scan assets, prioritise exploited exposures, and verify remediation completion. | ||
| NIST CSF 2.0 | PR.IP-12 — Vulnerability management plan is implemented | The response depends on coordinated patching, mitigation, and follow-up validation. |
| Recommendation — Execute the vulnerability response process and track remediation to closure. | ||
| NIST SP 800-53 Rev 5 | RA-5 — Vulnerability Monitoring and Scanning | This flaw requires identification, tracking, remediation, and verification of vulnerable instances. |
| SI-2 — Flaw Remediation | The core action is applying vendor updates or mitigations for the server-side injection flaw. | |
| Recommendation — Identify vulnerable systems, remediate them, and confirm the fix with follow-up scanning. Apply the vendor fix or approved mitigation and document the remediation outcome. | ||
Practitioner Guidance
What to prioritise: Inventory every Workspace ONE Access and Identity Manager instance first, then rank them by exposure. Internet-facing systems should be remediated before internally reachable ones because they carry the highest likelihood of active exploitation.
What to verify: Confirm the vendor update or documented mitigation is actually applied, then verify that the vulnerable service is no longer externally reachable if you used exposure reduction as the interim control. Validation should include log review, not just version checking.
Decision rule: If you cannot patch immediately, remove the service from internet access or take it offline rather than leaving a known exploited flaw exposed while “monitoring” it. For this CVE, delay is only defensible when the attack surface has been materially reduced.
Practitioner takeaway: Treat this as a patch plus exposure problem, not a patch-only problem, and assume any delayed remediation requires a real compromise check before you declare the system clean.
Related resources from NHI Mgmt Group
- Guide: Zero-Day and Exploited Vulnerabilities Guide
- Is CVE-2022-22954 (VMware Workspace ONE Access and Identity Manager Server-Side Template Injection) being exploited in the wild?
- CVE-2022-22954 (VMware Workspace ONE Access and Identity Manager Server-Side Template Injection)
- How do you patch or mitigate CVE-2019-11581 (Atlassian Jira Server and Data Center Server-Side Template Injection)?
- How do you patch or mitigate CVE-2021-21975 (VMware Server Side Request Forgery in vRealize Operations Manager API)?
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