Is CVE-2022-22963 (VMware Tanzu Spring Cloud Function Remote Code Execution) being exploited in the wild?

By NHI Mgmt Group Editorial Team Updated October 19, 2026 Domain: Threats, Abuse & Incident Response

Yes. CISA added CVE-2022-22963 to its Known Exploited Vulnerabilities catalogue on 25 August 2022, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. When using routing functionality in VMware Tanzu's Spring Cloud Function, it is possible for a user to provide a specially crafted SpEL as a routing-expression that may result in remote code execution and access to local resources.

What active exploitation means for CVE-2022-22963

For this CVE, “being exploited in the wild” means more than theoretical proof-of-concept activity. CISA’s KEV listing indicates verified exploitation evidence, so the practical question shifts from “can this be attacked?” to “is any instance still exposed or already compromised?” That is why exploiting status should drive immediate triage, not routine patch scheduling.

When a vulnerability reaches the KEV catalogue, it should be treated as an actively exploited vulnerability until exposure is proven absent. The operational concern is not the abstract flaw itself, but whether routing inputs, application reachability, and internet-facing deployment conditions make exploitation feasible in your environment.

Spring Cloud Function is particularly sensitive here because the vulnerable path is part of request handling and expression processing. If that path is reachable, a maliciously crafted routing expression can become a code execution mechanism rather than a harmless configuration input, which changes the issue from a product bug into an execution-risk problem.

How to confirm exposure and decide whether to patch first

The first decision is whether any deployed system still uses the affected component and whether the vulnerable routing functionality is exposed to untrusted input. Inventory matters because exploitation is only relevant where the vulnerable code path exists. If you cannot quickly prove absence, assume exposure and move to mitigation, patching, or containment.

Use the official CVE Program record for identifier fidelity, the NIST National Vulnerability Database for reference data, and CISA’s Known Exploited Vulnerabilities Catalog for prioritisation. For KEV-listed issues, the practical priority is to find exposed assets first, then verify whether the vendor fix or an approved mitigation is already in place.

If patching is delayed, reduce attack surface immediately. That usually means removing or restricting the vulnerable route, limiting reachability to trusted callers, and blocking the inputs that can drive expression injection. Where the affected service sits behind an API gateway or ingress tier, treat any broad external access as a temporary risk multiplier.

What to check after containment or patching

Once exposure is reduced, check for signs that the instance was already used before you contained it. For remote code execution cases, that means looking for unexpected process launches, new files, unusual outbound connections, suspicious configuration changes, and any evidence that the application identity was used to reach local resources it should not normally access.

If the system handled secrets, tokens, session material, or service credentials, rotate what may have been reachable from the compromised process. The safest assumption after RCE is that the runtime can read more than it should, even if the original attacker intent was only to execute a command. Compromise assessment is therefore part of the response, not a separate later task.

In practice, teams should pair patch validation with focused hunting. A vulnerability that enabled code execution can also enable persistence, credential theft, and lateral movement, so the absence of a crash or obvious outage does not prove the absence of compromise.

Risk and Threat Considerations

Remote code execution in a widely deployed framework component creates a direct path from malformed input to arbitrary command execution. That is why exploited-in-the-wild status matters: the main risk is not just service disruption, but attacker-controlled execution on a reachable application host.

Failure mechanism: An attacker supplies a crafted routing expression that is interpreted in a dangerous context, allowing code execution and possible access to local resources, secrets, or adjacent services reachable from the runtime.

Impact: Successful exploitation can lead to full application compromise, secret theft, lateral movement, and the need for incident response rather than simple patch management.

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	DE.CM-01 — Networks and network services are monitored to find potentially adverse events	Active exploitation requires monitoring for suspicious host and network activity.
Recommendation — Monitor network and host activity for signs of exploitation and post-compromise behavior.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	The question is about a vulnerability being exploited and needing remediation priority.
	AU-6 — Audit Record Review, Analysis, and Reporting	Post-exploitation checks depend on reviewing logs and audit evidence.
	IR-4 — Incident Handling	Active exploitation can require compromise assessment and incident response.
Recommendation — Remediate the flaw quickly and validate the fix on all exposed systems. Review audit logs for exploitation indicators and suspicious post-compromise activity. Escalate to incident handling when exploitation or compromise is suspected.
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	KEV-listed exploitation drives urgent vulnerability triage and remediation.
Recommendation — Prioritize and remediate KEV-listed vulnerabilities on exposed assets first.

Practitioner Guidance

What to prioritise: Treat KEV-listed exploitation as an exposure-management event, not a theoretical vulnerability review. Confirm whether any Internet-reachable or partner-reachable instance still has the vulnerable code path exposed before spending time on broad fleet-wide analysis.

What to verify: After remediation, verify both that the vulnerable component is no longer reachable and that the host shows no indicators of post-exploitation activity. If the application can access credentials, tokens, or internal resources, validate rotation and access review before declaring the issue closed.

Practitioner takeaway: For an actively exploited RCE, the right order is exposure confirmation, containment or patching, and then compromise assessment, because a clean patch does not by itself prove a clean system.

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.

NHIMG Editorial Note
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