CVE-2022-22963 is a function remote code execution vulnerability in VMware Tanzu Spring Cloud. CISA added it to the Known Exploited Vulnerabilities catalogue on 25 August 2022, which means attackers have used it in real attacks. Organisations running the affected product should apply the vendor fix or mitigation as a priority.
What this vulnerability means in a Spring Cloud Function context
This CVE matters because Spring Cloud Function is designed to take input and turn it into code execution paths inside an application. When that boundary is broken, a remote attacker can move from a crafted request to arbitrary command execution, which turns a normal integration component into a high-impact entry point.
That makes the vulnerability especially dangerous in internet-facing services and internal platforms that expose function endpoints, route untrusted input into function handlers, or rely on Spring Cloud Function as part of a larger application gateway pattern. For the canonical vulnerability record, consult the CVE Program and the NIST National Vulnerability Database for authoritative identifier and record details.
How exposure is assessed
Exposure checking starts with a simple question: where is the vulnerable Spring Cloud Function component deployed, and which services can reach it? Asset inventory matters because organisations often discover that the affected code exists inside a larger platform image, a shared service template, or an application they no longer track closely enough to patch quickly.
Internet exposure is the next filter. If the application is reachable from outside the network, or if reverse proxies, API gateways, or shared ingress paths forward attacker-controlled requests to the vulnerable function layer, the risk rises sharply. Vendor advisories, package manifests, and dependency inventories should be used together so teams can match the deployed component to the specific fix or mitigation the supplier recommends.
Remediation and compensating controls
The primary response is to apply the vendor fix or mitigation as soon as possible, because this class of flaw is not a configuration nuisance, it is an execution path. Where immediate patching is not possible, organisations should reduce reachability, block untrusted access to the affected endpoint, and remove any routing patterns that let attacker input reach the vulnerable function handler.
Compensating controls should focus on shrinking the attack surface rather than trying to “watch” the flaw away. That usually means tightening network exposure, isolating the affected service, and reviewing whether the application needs the exposed function interface at all. In practice, the safest temporary state is one where the vulnerable path is no longer externally reachable.
Detection and post-exploitation review
Detection should look for evidence that the vulnerability was already used before remediation. Because this is remote code execution, defenders should treat suspicious process creation, unusual child processes, web shell indicators, unexpected outbound connections, and changes to application files or startup behaviour as possible signs of compromise.
After patching, review the application and surrounding host for persistence, tampering, and follow-on activity. If the service used local credentials, tokens, API keys, or other secrets to reach downstream systems, those identity-bearing materials may need rotation because RCE often gives an attacker a path to steal them even when the initial exploit is only brief. For broader vulnerability prioritisation and verification workflow, the Vulnerability Management Guide is useful, and the Langflow Flodrix botnet 2025 case shows how function-level execution flaws can be abused to steal secrets and repurpose exposed systems.
Risk and Threat Considerations
Remote code execution in a function framework is dangerous because it collapses the line between normal application input and executable behaviour. Once attackers can reach that boundary, they can use the service to run commands, stage payloads, steal secrets, and pivot into adjacent systems that trust the application.
Failure mechanism: A crafted request reaches the vulnerable function path, the application processes attacker-controlled input as executable logic, and the attacker gains code execution on the host or container.
Impact: The compromise can lead to data theft, credential harvesting, lateral movement, persistence, and reuse of the affected service as a foothold for further attacks.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while OWASP ASVS, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V4 — API and Web Service Security | Spring Cloud Function endpoints are web service attack surfaces exposed to remote input. |
| Recommendation — Verify service endpoints resist remote input abuse and enforce strict request handling. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | The flaw arises when attacker-controlled input changes execution behaviour in the service. |
| SC-7 — Boundary Protection | Exposure depends on whether the vulnerable function path is reachable across trust boundaries. | |
| Recommendation — Validate and constrain external input before it reaches executable application paths. Restrict network reachability to the vulnerable service and filter untrusted traffic. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Mitigation depends on removing exposed, vulnerable service configurations and paths. |
| Recommendation — Harden the deployment and remove unnecessary exposed interfaces. | ||
| OWASP API Security Top 10 | API8 Security Misconfiguration — Security Misconfiguration | Exposed function routes and permissive deployment settings can enable exploitation. |
| Recommendation — Review deployment settings that expose the vulnerable function surface unnecessarily. | ||
Practitioner Guidance
Why practitioners should care: This is a prioritisation problem, not just a patching task. If the affected service is internet-facing or supports business-critical automation, the vulnerability deserves urgent triage because successful exploitation can change the service from a trusted component into an attacker-controlled execution surface.
What to watch for: Focus on services that expose function endpoints, carry sensitive runtime secrets, or sit behind shared ingress layers. Those are the environments where exploitation is most likely to be both reachable and consequential, and where post-compromise review should include both host integrity and secret rotation.