CISA's required action for CVE-2022-22963 is to apply updates per vendor instructions. In practice, find every instance of VMware Tanzu Spring Cloud 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 patching CVE-2022-22963 actually means in practice
This issue is handled as a software vulnerability response, not as a one-step patch task. The practical sequence is to identify every reachable instance of VMware Tanzu Spring Cloud Function, apply the vendor update or documented mitigation, and then reduce exposure while validation is in progress. For this class of flaw, asset discovery and removal of unnecessary internet exposure are part of the fix, not separate clean-up work.
Because the vulnerability was actively exploited, treating the environment as if exploitation might already have happened is the safest working assumption. That means patching should be paired with a quick review of where the software is deployed, how it is exposed, and whether any instance can be isolated until the update is complete.
How to reduce exposure if you cannot patch immediately
If patching must wait, the priority is to narrow the attack surface rather than leaving the service fully exposed. The most defensible temporary move is to remove internet exposure, restrict access to trusted networks, or take the affected product out of service until a vendor-supported fix or mitigation can be applied. That is especially important when the application is reachable by untrusted users or sits behind infrastructure that makes internet access easy to forget.
Temporary compensating controls should be treated as a short bridge, not a substitute for remediation. For this kind of remote code execution flaw, access restriction buys time only if it is actually enforced at the edge and not bypassed through alternate routes, stale load balancer rules, or overlooked development and staging deployments.
What to check after remediation
Once updates or mitigations are in place, review logs for signs of earlier exploitation. The key question is whether the vulnerable component was reachable before it was fixed and whether any suspicious requests, command execution indicators, or unexpected process activity appeared during that window. If you find evidence of access, broaden the review to adjacent hosts, credentials, and any data the application could reach.
Post-patch validation should also confirm that the vulnerable version is no longer deployed anywhere else. In incidents like this, the common failure is not the patch itself, but missing a second copy of the same software in another environment, container image, or test system that still exposes the same flaw.
Risk and Threat Considerations
This vulnerability matters because remote code execution gives an attacker a direct path from exposure to control. Once a public-facing instance is exploitable, the attacker no longer needs a complex chain, just reachability and a working exploit.
Failure mechanism: The flaw can be abused to run attacker-controlled code on an exposed Spring Cloud Function instance before defenders have time to patch or filter requests.
Impact: Successful exploitation can lead to service compromise, follow-on lateral movement, data access, persistence, and additional tooling dropped onto the host.
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 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.AM-01 — Physical devices and systems within the organization are inventoried | Inventory affected instances to find every exposed deployment of the vulnerable product. |
| PR.PS-01 — Configuration management practices are established and applied | Applying vendor updates and documented mitigations is a configuration-remediation task. | |
| DE.CM-01 — Networks and network services are monitored to find potential cybersecurity events | Post-patch log review and exposure checks rely on monitoring for exploitation indicators. | |
| Recommendation — Inventory all Tanzu Spring Cloud Function instances before you patch or mitigate. Apply the vendor update or documented mitigation and verify the change is deployed everywhere. Monitor logs and network activity for signs of earlier exploitation. | ||
| NIST SP 800-53 Rev 5 | RA-5 — Vulnerability Monitoring and Scanning | The issue requires locating vulnerable instances and validating remediation across the estate. |
| CM-3 — Configuration Change Control | Vendor updates and mitigations must be controlled and verified as the approved change. | |
| SI-2 — Flaw Remediation | This is directly a flaw-remediation scenario requiring patching or approved mitigation. | |
| Recommendation — Scan for every vulnerable instance and track remediation to completion. Use formal change control to apply the fix or mitigation consistently. Remediate the flaw with the vendor update or an approved mitigation. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | The response depends on finding, prioritising and remediating the exploited vulnerability. |
| CIS-12 — Network Infrastructure Management | Removing internet exposure is a network-hardening step used when patching must wait. | |
| CIS-8 — Audit Log Management | Reviewing logs after remediation is essential to detect earlier exploitation. | |
| Recommendation — Prioritise and remediate the exploited vulnerability across all affected assets. Restrict exposure paths when immediate patching is not possible. Review logs for signs of pre-patch compromise after remediation. | ||
Practitioner Guidance
What to prioritise: Start with exposure inventory, not ticket closure. Find every deployed instance, confirm whether it is reachable from untrusted networks, and rank systems by business criticality and exposure before deciding where to patch first.
What to verify: After remediation, verify three things, the affected software is no longer present in reachable paths, the fix or mitigation actually matches the vendor guidance, and the logs were reviewed for pre-patch compromise signals. If any one of those is missing, treat the job as incomplete.
Decision rule: If the system cannot be updated immediately, remove internet exposure or take it out of service. If the system was exposed before remediation, assume possible compromise until log review and host inspection say otherwise.
Practitioner takeaway: For exploited RCEs, the real control is speed plus verification, patch quickly, reduce exposure if patching lags, and confirm whether the weakness was used before you declare the system clean.
Related resources from NHI Mgmt Group
- Guide: Zero-Day and Exploited Vulnerabilities Guide
- CVE-2022-22963 (VMware Tanzu Spring Cloud Function Remote Code Execution)
- How do you patch or mitigate CVE-2022-26500 (Veeam Backup & Replication Remote Code Execution)?
- How do you patch or mitigate CVE-2022-26501 (Veeam Backup & Replication Remote Code Execution)?
- How do you patch or mitigate CVE-2022-42948 (Fortra Cobalt Strike User Interface Remote Code Execution)?
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