KEV Catalog: VMware Spring Cloud Gateway Code Injection Vulnerability (CVE-2022-22947)

VMware Spring Cloud Gateway Code Injection Vulnerability (CVE-2022-22947)

The CISA Known Exploited Vulnerabilities (KEV) Catalog lists cybersecurity vulnerabilities known to be actively exploited and helps prioritize vulnerability management. CISA includes a due date to remediate the vulnerability, typically two to three weeks from its submission. Actively monitoring the KEV catalog and understanding how these vulnerabilities can be exploited helps security teams recognize each vulnerability’s risk and threat to their network environments. Subscribe to CISA’s KEV Catalog Update Bulletin to stay up to date on new KEV Catalog vulnerabilities.

Date Added to KEV Catalog: May 16, 2022

CISA Due Date for Remediation: June 6, 2022


Introduction to Spring Cloud Gateway 

Spring Cloud Gateway is an API gateway which aims to provide a simple way to route to microservices. An external client can access these microservices through the application gateway. This external client could be a mobile application, desktop application or a third party application. Spring describes how the Cloud Gateway works: “Clients make requests to Spring Cloud Gateway. If the Gateway Handler Mapping determines that a request matches a route, it is sent to the Gateway Web Handler. This handler runs the request through a filter chain that is specific to the request. The reason the filters are divided by the dotted line is that filters can run logic both before and after the proxy request is sent. All “pre” filter logic is executed. Then the proxy request is made. After the proxy request is made, the “post” filter logic is run.” 

Vulnerability Description 

Wyatt Dahlenburg found this Expression Language injection vulnerability.  Applications using Spring Cloud Gateway are vulnerable to a code injection attack when the Gateway Actuator endpoint is enabled, exposed and unsecured. A remote attacker could make a maliciously crafted request that could allow arbitrary remote execution on the remote host. The maliciously crafted request uses Spring Expression Language (SpEL).

Systems Affected and Detection

Spring Cloud Gateway 

  • 3.1.0 
  • 3.0.0 to 3.0.6 
  • Older, unsupported versions are also affected 


Wyatt Dahlenburg describes in two blog posts how to create a route and execute commands using the Actuator endpoint and SpEL.  

There are three clear methods to exploit this vulnerability: manually through POST requests on Burp Suite, running a publicly available python exploit, or using a Metasploit module.  

Manual exploitation through Burp Suite 

Spring documentation outlines how to create and delete routes via the /actuator/gateway endpoint:

The above documentation shows how to view all listed routes with a GET request of /actuator/gateway/routes and a create new route with a POST request of /actuator/gateway/routes/{id}. In the below example, a route is added following the example shown on Github vulhub’s exploitation steps. 

Confirm Spring Cloud Gateway is running via Linux command line:  

ps aux | grep java

If running a vulnerable environment a sample test page is typically shown on port 8080:

Manual exploitation involves:

  1. Using a POST request to add a new route to the Spring Cloud Gateway actuator endpoint. The example below is “hacktest”: /actuactor/gateway/routes/hacktest. This added route will also include a SpEL expression value that defines the RCE. The example command is “id“.
  2. Send a GET request and POST request to refresh and confirm the new route
  3. Send a GET request to the new route, which will run the “id” command, shown in a HTTP response

Add a route “hacktest” with a POST request (/actuator/gateway/routes/hacktest) and the SpEL value (#{ ….”id” }).

The 201 HTTP response confirms the route is created. 

Refresh the route with a refresh request. All new routes need a follow on request to make the application recognize the new route. The 200 HTTP response confirms the new route was successful added.  

Send another GET request to the new “hacktest” route to run the malicious SpEL injection. In this casethe “id” command executedThe Burp Suite Response panel shows the root user:

An attacker could then attempt to get to use this RCE to attain a reverse shell.

 Public Python Exploit

ExploitDB shows only one exploit under “spring cloud gateway”:  

Spring Cloud Gateway 3.1.0 – Remote Code Execution (RCE)

Kali Linux users, with an updated ExploitDB database, can find the exploit through the searchsploit command and located here:

File Path: /usr/share/exploitdb/exploits/java/webapps/ 

This python exploit is also on Github and works on Vulhub’s vulnerable environment. Note: always read through and understand public exploits before running. The ExploitDB exploit is technically not listed as verified.  

Metasploit Exploit Module 

Another exploit option is using Metasploit and the module: exploit/linux/http/spring_cloud_gateway_rce 


VMware Tanzu released the following mitigation notice:  

Users of affected versions should apply the following remediation. 3.1.x users should upgrade to 3.1.1+. 3.0.x users should upgrade to 3.0.7+. If the Gateway actuator endpoint is not needed it should be disabled via management.endpoint.gateway.enabled: false. If the actuator is required it should be secured using Spring Security, see how to secure endpoints here.

Releases that have fixed this issue include: Spring Cloud Gateway 3.0.7+ and 3.1.1+.