A Remote Code Execution Vulnerability in GeoServer

February 26, 2025

4

Introduction

We recently observed a critical vulnerability CVE-2024-36401 in GeoServer that poses severe security risks. GeoServer is an open-source server written in Java designed for sharing, processing, and editing geospatial data. It is interoperable with other geospatial software and services, supporting a wide range of OGC (Open Geospatial Consortium) standards and protocols, such as Web Feature Service (WFS), Web Map Service (WMS), Web Coverage Service (WCS), and Web Map Tile Service (WMTS).

CVE-2024-24816 allows remote, unauthenticated attackers to execute arbitrary code by exploiting improperly handled feature type attributes passed to the commons-jxpath library. The vulnerability is rated a high CVSS v3 score of 9.8 due to its severe impact and exploitation potential. It is added to the CISA Known Exploited Vulnerabilities (KEV) list as it has been actively exploited in the wild. In this article, we will delve into the technical details of this vulnerability and demonstrate how it can be exploited.

Understanding the Vulnerability

CVE-2024-36401 is a critical vulnerability affecting GeoServer versions prior to 2.25.2, 2.24.4 and 2.23.6. The vulnerability arises from the unsafe evaluation of XPath expressions within the GeoTools library, utilized by GeoServer. The core of the vulnerability lies in how GeoServer processes user-supplied input using XPath, a language designed for querying XML documents. GeoServer employs the commons-jxpath library to handle these XPath expressions. However, the evaluation of these expressions, which should be confined to complex feature types (like Application Schema data stores), is erroneously applied to both complex and simple feature types. This creates a significant security risk, as it opens the possibility for arbitrary code execution when processing maliciously crafted input, making all GeoServer instances vulnerable.

In GeoServer, the GeoTools library is responsible for processing the property names of feature types. Feature types define the schema for features in a geospatial dataset, specifying the properties that each feature can have – analogous to columns in a database table. This schema is critical in managing geospatial data, but the improper handling of feature type attributes during XPath evaluation makes the system vulnerable.

The vulnerability can be exploited through various OGC (Open Geospatial Consortium) request parameters such as WFS GetPropertyValue, WFS GetFeature, WMS GetMap, WMS GetFeatureInfo, WMS GetLegendGraphic, and WPS Execute. An attacker can craft a request using these parameters, which when processed by the vulnerable GeoServer instance, could lead to the execution of arbitrary code. This means that a remote, unauthenticated attacker could potentially gain control of the server, leading to a full server compromise.

A sample payload in an XML request could look like:

Figure 1: Sample payload

In the application code, the flaw arises from the way the JXPathContext was created directly from a document object and namespaces. This approach was unsafe because it did not incorporate any additional safety checks, leaving the application exposed to the evaluation of untrusted XPath expressions. The fix implemented by the developers involved replacing the direct creation of JXPathContext with a call to JXPathUtils.newSafeContext. This method encapsulates the context creation process, ensuring that the initialization is conducted securely, thereby mitigating the risk of code execution attacks.. This method encapsulates the context creation process, ensuring that the initialization is conducted securely, thereby mitigating the risk of code execution attacks.

Setting Up the Vulnerable Environment

To exploit the vulnerability, we utilized a Docker instance of the vulnerable GeoServer version kartoza/geoserver:2.25.1. The following command was used to start the Docker instance, where we specified the admin username and password:

sudo docker run -e GEOSERVER_ADMIN_USER=admin -e GEOSERVER_ADMIN_PASSWORD=geoserver -p 8080:8080 -d kartoza/geoserver:2.25.1

The vulnerable package can also be downloaded from GeoServer’s official archive downloads page for manual setup.

The GeoServer web interface can then be accessed via http://<target_ip>:8080/geoserver.

Then we need to login using the specified credentials username admin and password geoserver to proceed with further configurations:

A screenshot of a computer Description automatically generated

Figure 2: Logging into GeoServer

Next, we need to create a new workspace. To do this, we need to navigate to the Workspaces menu and select Add new workspace. Then, we need to fill out the form with a name and a Namespace URI (e.g., “workspace”) and submit it.

Figure 3: Creating a New Workspace

Then, we proceed to add a data source. To do this, we navigate to Stores and click on Add new Store. For simplicity, we select Shapefile as the data source type. We need to provide a name for the data source, such as “datasource.” For this example, we will use the sample data provided by GeoServer, located at “/usr/local/tomcat/data/data/shapefiles/states.shp”

states.shp is the data source, and we will use it to create a feature type that describes the data’s schema and properties in GeoServer.

Figure 4: Adding a Data Source

Next, we need to navigate to the Layers menu and add a new layer named states. To do this, we have to click on Publish.

Figure 5: Adding a Layer

Then we need to fill in the “Bounding Boxes” section of the form by selecting Compute from data. Finally, we click Save to create the layer.

Figure 6: Configuring the Bounding Box

A specific feature type is composed of two elements concatenated in the format: namespace:featuretype. In our case, based on the layer we created, it is workspace:states. We need to provide this in the payload, in the typeNames parameter where namespace:featuretype is required.

The machine is now configured to be vulnerable to CVE-2024-4577.

Figure 7: Successfully Created a Layer

Triggering the Vulnerability

We can exploit the vulnerability by sending the following curl request.

Figure 8: Sending the exploit payload with curl

Here, we have sent a POST request to http://localhost:8080/geoserver/wfs, targeting GeoServer’s Web Feature Service (WFS) endpoint. The XML payload includes a wfs:GetPropertyValue request, where we specify the feature type “workspace:states”. The critical part of the payload is the valueReference element, which attempts to execute arbitrary code on the server using the Runtime.getRuntime() method. In this example, it runs the “touch /tmp/success1” command, which creates a file to demonstrate successful exploitation.

Upon verification, we observe that the file was successfully created on the affected server.

Figure 9: Verification of successful exploitation

A similar payload can also be sent using a GET request, as shown below:

A screen shot of a computer screen Description automatically generated

Figure 10: Exploiting the vulnerability with a GET request

In the GET request, URL parameters are used to define the WFS service, version, request type, and feature type, with the valueReference parameter containing the malicious code. This leads to the arbitrary code execution on the server. The response includes a ClassCastException, which highlights an issue with how the server handled or interpreted the result of the command execution. This error suggests that, while the command was executed, the server encountered difficulties when processing or returning the results. This shows that the exploit was effective in executing commands.

The following screenshot demonstrates the exploitation, showing that the file success2 has been created. A similar exploit could also be used by malicious actors to remotely execute commands.

A close-up of a computer code Description automatically generated

Figure 10: GET request exploit verification—file success2 created

CONCLUSION

To protect against these vulnerabilities, it is crucial to update to the latest GeoServer releases. Leveraging threat detection solutions can further strengthen your defences against emerging threats and ensure the continued integrity of your systems. You can also use the Keysight test platforms with ATI subscription to safeguard your network against such attacks.

LEVERAGE SUBSCRIPTION SERVICE TO STAY AHEAD OF ATTACKS

Keysight’s Application and Threat Intelligence (ATI) Subscription provides daily malware and bi-weekly updates of the latest application protocols and vulnerabilities for use with Keysight test platforms. The ATI Research Center continuously monitors threats as they appear in the wild and has just released a strike for this CVE as part of BreakingPoint System’s recent update 2024-15 to help keep your network secure. More information is present here.

The following image shows a screenshot of this CVE as a strike in BreakingPoint System: