CVE-2024-36401 in GeoServer: how XPath injection turns a map server into a remote shell

Why a map server belongs in your threat model

GeoServer is not an exotic application. It is the open-source map server that publishes geospatial data for cadastre portals, meteorological viewers, urban planning platforms, public-health atlases and energy dashboards in public administrations, utilities and large enterprises across Europe and Latin America. Most of these deployments are old, sit in a DMZ, or are directly exposed to the internet because the business logic assumes maps are public. That assumption is exactly what CVE-2024-36401 exploits.

On August 14, 2026, Hispasec Unaaldia reported that a critical vulnerability in GeoServer is being actively exploited and allows taking control of the server without credentials. The chain combines two ingredients: any instance publishing the OGC endpoints of WFS, WMS or WPS over HTTP, and a GeoServer version prior to the patches released in June 2024 and March 2025. The attacker needs no authentication, no user interaction and no position inside the network. The attacker only needs the GeoServer URL to be reachable from the internet, which is the default for tens of thousands of production instances.

The problem is not new. CVE-2024-36401 was disclosed in July 2024 and patches were published in June 2024 (versions 2.25.2 and 2.24.4) and March 2025 (version 2.22.6). What is new, and what motivates this article, is that two years after the patch we continue to see active exploitation, confirmed intrusions and web shells deployed on instances nobody updated.

Technical anatomy: how a malicious property becomes remote execution

The root cause lies in how the GeoTools library —used by GeoServer— handles feature property names. GeoTools delegates the evaluation of those names to the commons-jxpath library, which is capable of executing XPath expressions that invoke arbitrary Java methods. XPath, in this context, is not just a query language: it is an open door into the Java runtime.

The key detail, described by NVD and the official GeoServer advisory, is that XPath evaluation should be limited to complex features in Application Schema. However, an implementation flaw causes that evaluation to be applied to simple features as well, which are what practically every GeoServer instance uses by default. The result: any property parameter in an OGC request is evaluated as a full XPath expression, which lets an attacker inject calls to `java.lang.Runtime.getRuntime().exec()` from an external HTTP client.

The vulnerable parameters include operations that GeoServer exposes by default in its standard services:

- WFS (Web Feature Service): `GetFeature` and `GetPropertyValue` - WMS (Web Map Service): `GetMap`, `GetFeatureInfo` and `GetLegendGraphic` - WPS (Web Processing Service): `Execute`

The severity is the maximum possible for a network vulnerability: CVSS v3.1 of 9.8, with vector `AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H`. No authentication, no user interaction, low complexity and full effects on confidentiality, integrity and availability.

EPSS (Exploit Prediction Scoring System) assigns CVE-2024-36401 an exploitation probability of 94.4 %, in the 100th percentile. CISA added the vulnerability to its KEV catalog on July 18, 2024 with a remediation deadline of August 5, 2024 for US federal agencies. Almost two years later, Hispasec confirms there are still active attempts and confirmed compromises in production.

The attack chain documented by Hispasec

The incident described by Hispasec Unaaldia on August 14, 2026 is not theoretical. The chain observed in real instances follows a pattern that is recognizable to any analyst who has seen a compromised exposed web application.

The initial phase is the direct exploitation of CVE-2024-36401. The attacker sends an HTTP request crafted against one of the vulnerable OGC endpoints with a malicious property name that contains an XPath expression. The expression invokes the Java runtime to execute a command on the operating system. Within seconds, the GeoServer process —which usually runs with elevated privileges or, worse, as root inside a Docker container— executes the attacker's payload.

The second phase is persistence. Once the attacker has remote execution, the next common move is to deploy a web shell. Hispasec specifically documents the use of China Chopper, a minimalist Chinese web shell tool that fits on a single line and remains surprisingly common in intrusions against European infrastructure. The web shell is typically placed in the GeoServer working directory, where it goes unnoticed by antivirus solutions because the directory is full of legitimate `.jar`, `.xml` and `.properties` files.

The third phase is internal reconnaissance. With the web shell in place, the attacker has a persistent shell that survives service restarts. From there they enumerate the network, identify adjacent systems, look for routes to internal databases and services, and prepare lateral movement. The web shell is discreet because requests pass through the same port as GeoServer and mix their traffic with legitimate OGC queries.

The fourth phase is lateral movement. Hispasec documents use of the web shell to access shared resources, escalate privileges and compromise other internal systems. In some cases, attackers have reached Active Directory and deployed ransomware or mass exfiltration tools.

The most concerning aspect of the pattern is that it is generic. We are not facing a sophisticated threat actor with unpublished zero-days. We are facing mass exploitation of a two-year-old vulnerability that remains effective because there are tens of thousands of unpatched instances.

Why CVE-2024-36401 stays active two years after the patch

Three factors combine to keep this vulnerability in the list of the most exploited in the world.

The first factor is exposure surface. GeoServer is open-source, free and well documented. Any administrator with geospatial data installs it and publishes it. Many installations belong to hobbyists, NGOs, small town councils or academic projects that have gone years without professional maintenance. For those instances, updating is a multi-day project that requires testing, regression and validation against their own data.

The second factor is the false sense of security. A map server does not convey the urgency of an ERP or a customer database. Security leaders in many organizations see it as secondary infrastructure, with no sensitive data. That perception is wrong: an attacker with a shell on the GeoServer server sees the entire geospatial database, the metadata of internal services and, very often, the connection credentials to external databases and services.

The third factor is the public availability of PoCs. Multiple public GitHub repositories automate the exploitation of CVE-2024-36401, including Chocapikk's. An attacker with basic skills can clone the repository, point it at a GeoServer server and get a shell in minutes. This availability turns the vulnerability into a commodity for the mass scanning that ransomware groups and botnet operators perform.

DevSecOps playbook for this week

### Phase 1 — Inventory and exposure detection (hours 0 to 12)

The first move is to know what you have. Many organizations discover in this phase that they have GeoServer instances nobody remembers.

- Identify every GeoServer instance in the inventory. Include on-premises instances, public cloud, Docker containers and Kubernetes. Old Docker images are a common source of forgotten instances. - For each instance, check the exact GeoServer version and compare against the fixed versions: 2.25.2, 2.24.4 and 2.22.6 (the last published in March 2025). Any prior version is affected. - Determine whether the instance exposes OGC endpoints to the internet. The fastest way is to send an HTTP request to `https://your-instance/geoserver/ows?service=WFS&version=2.0.0&request=GetCapabilities` from an external network. If it returns capabilities XML, it is exposed. - Review GeoServer access logs for patterns that indicate exploitation attempts: property names with special characters, expressions containing `java.`, `Runtime`, `exec`, `ProcessBuilder`, or complex XPath patterns. - Search for known indicators of compromise on the server: unexpected child processes of the GeoServer Java process, outbound connections from the server to unknown destinations, `.jsp`, `.php` or unknown scripts in the GeoServer directory tree, new user accounts or recent modifications to configuration files.

### Phase 2 — Immediate containment (hours 12 to 36)

If you detect vulnerable instances exposed to the internet, the priority is to cut external access while planning the update.

- Block external access to the server through firewall rules, load balancer ACLs or, if the instance is in a DMZ, restrict access to known internal IPs. - If cutting access immediately is not feasible, implement HTTP basic authentication as a temporary mitigation. This breaks the automated exploitation chain of mass scanners. - If the instance already shows signs of compromise, isolate it from the network for forensic analysis. Do not power off the server — cold forensic analysis loses valuable artifacts. - Audit administrative accounts on the server, SSH keys and credentials stored in configuration files. Assume credential compromise if there is any sign of intrusion.

### Phase 3 — Remediation (days 2 to 7)

- Update GeoServer to the most recent fixed version of the branch you use. If you are on 2.22.x, update to 2.22.6. If you are on 2.24.x, update to 2.24.4. If you are on 2.25.x, update to 2.25.2 or later. - Before updating in production, validate the update in a test environment with the same data and configurations. GeoServer has extensions and plugins that may require additional steps. - If the instance runs as a Docker container, rebuild the base image with the patched version and redeploy. Verify that the new image does not include inherited versions of dependencies. - If you cannot update immediately due to incompatibility with extensions or proprietary data, apply the workaround documented by GeoServer: install the patched versions of GeoTools without updating GeoServer. This mitigates the vulnerability without breaking extensions. - Restart the service after the update to ensure the new version is active. Verify the version reported in the administration interface or in the `GetCapabilities` response.

### Phase 4 — Verification and monitoring (days 7 to 14)

- Re-scan the instance with an updated vulnerability scanner to confirm the fix is reported as installed. - Implement detection of exploitation attempts in logs. Configure alerts for OGC requests with property names containing special characters or complex XPath expressions. - If the instance stores credentials or connects to external databases, rotate all access credentials. Assume any credential accessible from the server during the exposure window is compromised. - Document the incident in the lessons-learned repository, including the time from disclosure to effective remediation.

Systematic mistakes teams make

Mistake one — treating GeoServer as secondary infrastructure. A compromised map server is a doorway into the internal network and into the geospatial data it protects. Treating it as low-risk infrastructure is a threat-model error.

Mistake two — relying on the DMZ as a sufficient barrier. A GeoServer instance exposed to the internet in a DMZ is reachable by any attacker with a scanner. The DMZ does not mitigate CVE-2024-36401; it only changes who can attempt to exploit the vulnerability.

Mistake three — forgetting instances in production. Many organizations have GeoServer instances deployed by project teams that no longer exist, maintained by people who have moved on to other roles, or running as sidecars of applications that have already been deprecated. Those instances are the first to appear in mass scans.

Mistake four — ignoring the GeoTools commit history. CVE-2024-36401 is the visible tip. The root cause is in GeoTools, the library GeoServer uses to process geospatial data. Similar vulnerabilities may exist in other components of the stack that have not yet been patched.

The paragraph for leadership

If you need the paragraph for a security committee: CVE-2024-36401 is a remote code execution vulnerability in GeoServer, with CVSS 9.8, exploitable at scale since July 2024 and actively exploited in 2026 per Hispasec. It allows an unauthenticated remote attacker to take control of the server through a single malicious HTTP request against standard OGC endpoints. It affects any GeoServer version prior to 2.22.6, 2.24.4 and 2.25.2. Mitigation requires updating affected instances, validating the absence of compromise, and blocking external access to instances that cannot be updated immediately. Typical exposure includes cartographic portals in public administrations, utilities and urban-planning platforms that have gone years without professional maintenance.

Structural changes after this incident

Change one — GeoServer as a critical asset in the threat model. If your inventory treats GeoServer as a low-risk platform, this incident invalidates that assumption. Any platform with an active unauthenticated RCE CVE and EPSS above 90 % deserves critical-asset treatment.

Change two — quarterly version review of open-source platforms. A scheduled procedure that verifies the versions of all deployed open-source platforms against known vulnerability databases. The right metric is "percentage of instances on supported versions," not "I install it when I have time."

Change three — early warning on public PoCs. Once a functional PoC for a vulnerability in your stack appears on GitHub, the clock starts ticking. Integrate public PoC feeds into the patch-prioritization flow.

Change four — segmentation of map servers. GeoServer servers that serve public data do not need access to internal databases or corporate networks. Network segmentation reduces the blast radius of a compromise.

Verified sources

- Hispasec Unaaldia, "Una vulnerabilidad crítica en GeoServer se explota activamente y permite tomar el control del servidor", August 14, 2026. https://unaaldia.hispasec.com/una-vulnerabilidad-critica-en-geoserver-se-explota-activamente-y-permite-tomar-el-control-del-servidor-2/ - NVD, "CVE-2024-36401 Detail". https://nvd.nist.gov/vuln/detail/cve-2024-36401 - GeoServer Project, "CVE-2024-36401 Remote Code Execution (RCE) vulnerability in evaluating property name expressions", September 12, 2024. https://geoserver.org/vulnerability/2024/09/12/cve-2024-36401.html - SecPod, "GeoServer Critical RCE Flaw Actively Exploited, Warns CISA", July 2024. https://www.secpod.com/learn/security-research/geoserver-critical-rce-flaw-actively-exploited-warns-cisa - turingpoint, "CVE-2024-36401 - OSGeo GeoServer GeoTools Eval Injection Vulnerability". https://turingpoint.de/en/cve/CVE-2024-36401 - Chocapikk, "CVE-2024-36401: GeoServer Remote Code Execution", GitHub. https://github.com/Chocapikk/CVE-2024-36401

Closing recommendations

Apply the June 2024 or March 2025 patches to every GeoServer instance in production. If an instance cannot be updated immediately, deploy the GeoServer-documented workaround based on patched GeoTools or block it from the internet. Audit logs for exploitation patterns compatible with CVE-2024-36401. If you detect indicators of compromise, assume credential stuffing on every secret accessible from the server. Treat it as a critical asset in your threat model, not secondary infrastructure. The difference between those two frameworks is what separates teams that contain the incident from those that discover the web shell when it is already too late.