CISA's required action for CVE-2022-22965 is to apply updates per vendor instructions. In practice, find every instance of VMware Spring Framework 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 you need to find before you patch
The first step is confirming every deployment of the vulnerable Spring Framework components, not just the application you already know about. For this kind of internet-facing RCE, inventory matters as much as the fix: hidden test hosts, forgotten containers, and embedded copies in older apps are often where exposure persists. NHIMG’s Vulnerability Management Guide is useful here because it frames the same problem as an asset-scope and prioritisation exercise, not a single-ticket patch event.
The practical goal is to reduce the exploitable window quickly. CISA’s KEV catalogue is the right external triage source for confirmed exploitation, while the vendor advisory is the source of truth for the exact update or mitigation path. If the affected component is embedded in a product or platform you do not directly own, treat that as a dependency-management problem and get the owning team involved immediately.
How to patch or mitigate safely
When a vendor update is available, apply it on the fastest path that still preserves service stability. If the product has documented mitigations rather than a clean patch-only answer, use the vendor instruction set exactly as written, because temporary mitigations for Spring-style RCE flaws are usually aimed at removing the dangerous request path, not at “hardening” the application in the abstract. A general zero-day response playbook such as NHIMG’s Zero-Day and Exploited Vulnerabilities Guide is relevant because it pairs emergency patching with compensating controls and post-patch verification.
If you cannot patch immediately, the safest temporary choice is to remove internet exposure or take the vulnerable service out of production use until the fix is in place. A WAF rule or generic perimeter filter may buy time, but it should be treated as a short-lived compensating control, not a substitute for remediation. When the application is business-critical, isolate it, restrict who can reach it, and make the exception time-bound with an explicit owner.
For teams dealing with Java exploitation patterns more broadly, understand why this class of issue is so dangerous: once an attacker can reach the vulnerable path, the result can be code execution on the server, which turns a patching problem into an integrity and containment problem. That is why NHIMG’s Insecure Deserialisation Guide is a useful adjacent reference for the execution mechanics behind similar Java exploitation paths.
How to check for compromise after remediation
After patching or mitigation, review logs for evidence of exploitation before the fix landed. Look for unexpected command execution, unusual web request patterns, new processes spawned by the application runtime, or outbound connections that do not belong to the service. Because exploitation was observed in the wild, post-fix review is not optional, it is part of the remediation itself.
If the server handled sensitive credentials, session material, or administrative interfaces, assume the blast radius may extend beyond the original flaw. In that case, rotate any secrets the application could have exposed, invalidate suspicious sessions, and re-check adjacent systems that might have been reachable from the compromised host. NIST’s vulnerability catalogue and CISA’s KEV listing both help justify why you should close the loop with hunting, not just patching.
Risk and Threat Considerations
This flaw matters because internet-exposed RCE bugs are attractive to both opportunistic mass exploitation and targeted follow-on access. The immediate danger is arbitrary code execution, but the operational danger is wider, a compromised application server can become a foothold for persistence, credential capture, or lateral movement if the host is trusted by other internal services.
Failure mechanism: The attacker sends requests that trigger the vulnerable Spring code path, obtains server-side execution, and then uses that execution to deploy tooling, stage payloads, or harvest local access material before defenders finish remediation.
Impact: Successful exploitation can lead to full application compromise, data exposure, service interruption, and secondary compromise of systems that trust the affected 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 — Asset Inventory | Find every exposed Spring deployment before remediation. |
| PR.IP-12 — Vulnerability Management | The question is about patching and compensating for a known exploited vulnerability. | |
| Recommendation — Maintain an accurate inventory of vulnerable assets and dependencies. Prioritise remediation of known exploited vulnerabilities and verify completion. | ||
| NIST SP 800-53 Rev 5 | SI-2 — Flaw Remediation | This control directly governs applying vendor updates and mitigations for a software flaw. |
| RA-5 — Vulnerability Monitoring and Scanning | Post-patch validation and exposure discovery depend on vulnerability detection. | |
| Recommendation — Apply vendor fixes and approved mitigations for the vulnerable component. Scan for the vulnerable software and confirm remediation state across the environment. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | The response requires prioritising, patching, and verifying an exploited CVE. |
| Recommendation — Track, prioritise, and remediate exploited vulnerabilities on a short SLA. | ||
Practitioner Guidance
What to prioritise: Patch the most exposed instance first, especially anything reachable from the internet or serving production traffic. If you have multiple Spring-based applications, rank them by exposure and business criticality rather than by team ownership.
What to verify: Confirm the vendor fix or mitigation is actually applied, then verify the vulnerable endpoint is no longer reachable in the intended way. If you rely on a compensating control, test it against the real request pattern, not just a lab example.
Decision rule: If you cannot patch within the required window, remove exposure or suspend use of the affected service until you can. Do not leave a known exploited RCE open while relying on a future maintenance slot.
Practitioner takeaway: For an actively exploited RCE, remediation is complete only when patching, exposure reduction, and compromise review have all happened, because the fix without hunting leaves uncertainty behind.
Related resources from NHI Mgmt Group
- How do you patch or mitigate CVE-2022-22963 (VMware Tanzu Spring Cloud Function Remote Code Execution)?
- CVE-2022-22965 (Spring Framework JDK 9+ 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)?
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