In this blog, we explore CVE-2024-36401—a security vulnerability found in GeoServer, an open-source Java-based server widely used for geospatial data manipulation and sharing. This vulnerability, which could allow RCE (remote code execution) by unauthenticated users, underscores the critical importance of patching GeoServer deployments as soon as possible.
In our latest security analysis, two OPSWAT Graduate Fellows investigate this threat by:
- Deeply examining the CVE’s attack vectors
- Identifying security gaps attackers could use to exploit GeoServer
- Simulating how attackers can compromise GeoServer deployments
We’ll also share how OPSWAT SBOM technology can detect this vulnerability, plus provide actionable steps for teams to secure their geospatial infrastructure before attackers strike.
GeoServer Overview
GeoServer is a Java-based open-source server designed for viewing, editing, and sharing geospatial data. Initially launched in 2001 by TOPP (The Open Planning Project), GeoServer was developed to improve public engagement in government and urban planning through open spatial data exchange. Over two decades later, GeoServer has matured into a robust platform capable of handling various spatial data formats and integrating with different data sources.
GeoServer provides services based on the OGC (Open Geospatial Consortium) standards, including:
- WFS (Web Feature Service) – Enables creating, modifying, and exchanging vector format geographic information using HTTP.
- WCS (Web Coverage Service) – Facilitates access to raster data (e.g., satellite imagery) for complex modeling and analysis.
- WMS (Web Map Service) – Provides a simple HTTP interface for requesting map images.
Background on CVE-2024-36401
CVE-2024-36401 affects GeoServer versions prior to 2.25.2, 2.24.4, and 2.23.6. It arises from the unsafe evaluation of property names as XPath expressions across multiple OGC request parameters. Attackers can exploit this flaw to create RCE (remote code execution) by injecting crafted inputs in a default GeoServer installation.
According to GitHub Security Advisories, this vulnerability carries a CVSS v3.1 score of 9.8 (Critical).
GeoServer’s Simple vs. Complex Features
GeoServer supports both simple and complex feature types to accommodate different geospatial data structures, from flat to intricate, nested datasets. However, the flawed handling of XPath expressions across these data types is what makes CVE-2024-36401 exploitable.
Simple Features
Simple feature types represent straightforward geospatial data in a flat format, where each row in a database corresponds to a geospatial feature; and each attribute maps directly to an XML element.
For example, a table representing companies with columns like id, name, and location can be easily converted into simple XML features.
| id | name | location |
| 1 | OPSWAT | POINT (10.769829, 106.685248) |
Complex Features
In contrast, complex feature types handle more intricate data. This feature type supports nested properties and relationships between different datasets. These complex schemas are not generated automatically, but are defined using community standards, as outlined in the GeoServer's Application Schema extension.
Example:
Under the previous companies table, we add a foreign key gu_id to describe the relationship between a company and its equivalent geologic unit:
| id | name | location | gu_id |
| 1 | OPSWAT | POINT (10.769829, 106.685248) | 12 |
The geologic unit information is stored separately in the table geologicunit:
| gu_id | urn | description |
| 12 | urn:x-demo:feature:GeologicUnit:12 | Metamorphic gneiss |
By using these tables, we can map the company to a sa:SamplingCompany, which contains a nested gsml:GeologicUnit. This setup creates a complex feature, as it involves nested types and relationships defined by community specifications rather than automatically generated schemas.
Such flexibility is essential for modeling complex real-world scenarios, but also introduces vulnerabilities due to its reliance on advanced processing techniques like JXPath evaluation to manage the nested structures effectively.
How the Vulnerability Arises
GeoServer is designed to use XPath evaluation to process complex feature types (such as those found in Application Schema data stores). But due to improper handling, it mistakenly applies XPath evaluation to simple feature types as well. This creates an attack vector because:
- GeoServer relies on the GeoTools library to evaluate property names during data retrieval.
- The
commons-jxpathlibrary, used for processing XPath expressions, lacks proper validation, which can execute arbitrary code when processing XPath expressions. - This flaw exposes all GeoServer instances to potential RCE vulnerabilities, as an attacker can craft a malicious request that exploits this unsafe XPath execution to control the server.
Exploitation Workflow Overview
- A
POSTrequest is sent to theGetPropertyValueoperation. Then GeoServer attempts to retrieve the property (orvalueReference) for a given feature. - If the requested property exists in the Feature Type Details table, GeoServer processes it normally.
- However, if the property is not listed, GeoServer falls back on the
commons-jxpathlibrary to interpret the request parameter as an XPath expression. - Since
commons-jxpathpermits executing Java code directly from XPath, this fallback mechanism potentially enables user-supplied request parameters to be exploited for remote code execution. Simply put, an attacker can inject malicious code to achieve RCE.
Vulnerability Exploitation and Analysis
JXPath and the Java Execution Bridge
The commons-jxpath library, commonly referred to as JXPath, enables navigation through Java object graphs (JavaBeans, DOM objects, etc.) using XPath syntax. For example, if you have a simple Employee object with properties like name and address, JXPath allows you to query those properties as if they were nodes in an XML document.
Exploiting Extension Functions
Beyond standard functions, JXPath also supports extension functions which act as a bridge to Java. This “bridge to Java” is crucial because it allows Java functions to be invoked directly within XPath queries, for example:
Because of the few limitations on which Java methods can be called through this bridge, an attacker can exploit the exec() function (or similar methods) to execute arbitrary commands on the server.
WFS GetPropertyValue
GeoServer’s WFS enables users to query and manipulate geospatial features. Under normal conditions, the WFS GetPropertyValue operation would simply return the requested property in an XML structure.
Workflow Analysis
- An attacker sends a POST request to /geoserver/wfs.
- GeoServer examines the outermost XML tag—
wfs:GetPropertyValue—to determine which operation to run. - GeoServer then delegates the request parameters to the corresponding method in the WFS class. In this scenario, the Dispatcher directs the request to the
GetPropertyValuemethod.
- Within the DefaultWebFeatureService20 (WFS) class, this
GetPropertyValuemethod forwards the user’s parameters to a handler of the same name. - The handler’s
run()method receives the request, including the criticalvalueReferenceparameter controlled by the user.
- During the
run()method, GeoServer retrieves thereferenceValueand invokes itsevaluate()function.
- If
valueReferencedoes not match GeoServer’s predefined properties, GeoServer defaults it to theFeaturePropertyAccessor, which interpretsvalueReferenceas an XPath expression.
- The
get()method in FeaturePropertyAccessor usescommons-jxpathto execute the XPath query. Here, the user’svalueReferenceis passed directly into the xpath parameter without validation. ThroughJXPathContext.newContext(), GeoServer initializes an environment for XPath queries, then runs them viaiteratePointers().
Since JXPath supports extension functions, attackers can inject malicious code into the XPath expression, triggering arbitrary code execution on the GeoServer instance.
This chain of events demonstrates how unsafe handling of the valueReference parameter can lead to RCE, representing a severe security threat to vulnerable GeoServer deployments.
Simulating the Attack
To simulate this exploitation in a real-world scenario, our OPSWAT Graduate Fellows deployed GeoServer on a local Windows machine. The following interface was displayed upon accessing GeoServer.
Once the server is running, an attacker can exploit the vulnerability by sending a POST request with a malicious XPath expression via valueReference to the /geoserver/wfs endpoint.
Result: After the request is sent, the malicious XPath expression executes a system command and triggers the launch of the Calculator application.
Mitigation and Recommendations
A simple exploit can escalate into a software supply chain attack, particularly in projects that rely on open-source software such as GeoServer. OPSWAT SBOM (Software Bill of Materials) technology helps identify vulnerabilities such as CVE-2024-36401 in your codebase.
This example demonstrates how OPSWAT SBOM:
- Detects the software components impacted by vulnerabilities.
- Assesses and ranks the severity of the security flaw – here, the GeoServer CVEs are flagged as “Critical.”
- Identifies the affected version.
- Recommends the fixed version so that development teams can apply patches or take remediation measures promptly.
Other Recommended Steps
- Update GeoServer: Upgrade to GeoServer versions 2.25.2, 2.24.4, or 2.23.6 (or later) where the vulnerability is patched.
- Audit Dependencies: Regularly use tools like OPSWAT SBOM to identify outdated libraries (e.g.,
commons-jxpath) in your environment. - Restrict Access: Deploy GeoServer behind firewalls or authentication layers to minimize the attack surface.
- Monitor Security Advisories: Keep an eye on official GeoServer release notes and CVE databases to stay up to date on new patches.
About OPSWAT SBOM
OPSWAT SBOM supports the most popular programming languages, providing software development teams with visibility into third-party open-source libraries, their associated dependencies, and the latest available versions to upgrade. Developers can integrate OPSWAT SBOM into their source code and container services such as GitHub, BitBucket, GitLab, Amazon ECR, DockerHub, and more. Learn more about SBOM.
Talk to an expert today to learn how to integrate OPSWAT tools and solutions with your existing infrastructure and workflows:
