CVE-2024-36404

What it actually does

The vulnerability allows remote code execution when an application uses vulnerable GeoTools functionality to evaluate XPath expressions derived from user-controlled input. In affected configurations, malicious XPath/property expressions can escape the intended geospatial query context and invoke Java functionality on the server, potentially allowing arbitrary command execution under the privileges of the Java application process. The issue is especially relevant to applications and services built on GeoTools components, including deployments that expose geospatial query features such as complex feature handling, application schema data stores, or WFS-style query interfaces. Successful exploitation can lead to full confidentiality, integrity, and availability compromise of the affected application host.

Why it matters to the business

This is a critical, remotely exploitable flaw with weaponized exploitation and a high EPSS likelihood, meaning internet-facing geospatial services using affected GeoTools functionality are at material risk of compromise. A successful attack can result in service outage, data theft, tampering with geospatial datasets, deployment of malware, lateral movement, or use of the server as a foothold into broader infrastructure. Although it is not currently listed in CISA KEV and is not marked as ransomware-associated, reported exploitation campaigns include activity against government environments and named campaigns such as StrikeShark, so organizations should treat exposed systems as urgent remediation candidates.

How an attack unfolds

An attacker first identifies an application or service that exposes GeoTools-backed geospatial query functionality, commonly through web-accessible endpoints that accept feature queries, filters, property names, or XPath-like expressions. The attacker then sends a crafted request containing a malicious XPath expression in a user-controllable parameter. On vulnerable versions, the application passes that expression into GeoTools evaluation logic without sufficient restriction, causing the Java runtime to evaluate attacker-influenced behavior. The attacker uses this primitive to execute commands, download payloads, establish persistence, read sensitive files, or pivot from the Java application context to the underlying host. Public exploit activity and weaponized techniques have focused heavily on GeoServer-style GeoTools usage patterns, but the underlying risk applies to any application embedding affected GeoTools functionality and accepting untrusted XPath expressions.

How to fix it

Upgrade GeoTools to a fixed release: 31.2, 30.4, or 29.6 or later, depending on the maintained branch in use. For Debian 13 packages, apply the vendor-fixed package version listed as fixed in 6.8.9-1 where applicable. If an immediate upgrade is not possible, remove the `gt-complex` JAR from the application to disable the affected complex feature/XPath functionality, understanding that this may break application schema datastore and complex content query features. For older GeoTools branches, the project also provided drop-in replacement JARs via SourceForge for versions 31.1, 30.3, 30.2, 29.2, 28.2, 27.5, 27.4, 26.7, 26.4, 25.2, and 24.0; these are intended as rapid mitigations where full dependency upgrades are not immediately feasible and should be validated carefully before production use. In addition, restrict public access to geospatial query endpoints, place them behind authentication where possible, enforce strict input validation for query parameters, disable unnecessary WFS/complex feature functionality, and run the Java service with least-privilege operating-system permissions.

How to confirm the fix worked

Confirm that all deployed applications and packaged services no longer include vulnerable GeoTools versions prior to 31.2, 30.4, or 29.6. Review application dependency manifests, built artifacts, container images, and runtime classpaths for `gt-complex` and GeoTools JAR versions. For Debian-based deployments, verify the installed fixed package version is at least the vendor-fixed 6.8.9-1 package where applicable. After patching, restart affected services and confirm the runtime process is loading the updated JARs rather than older bundled copies. Validate that complex feature/XPath functionality still behaves as expected or is intentionally disabled. Exposure can be checked by inventorying externally reachable geospatial endpoints and confirming they do not accept unauthenticated XPath/property expressions that are evaluated by GeoTools. Where safe and authorized, use non-destructive test payloads that only confirm blocked expression evaluation rather than attempting command execution.

Typical attack path

1. Scan for internet-facing geospatial services or applications that expose GeoTools-backed query functionality.
2. Fingerprint candidate services by probing common geospatial endpoints and observing WFS, feature query, or GeoTools/GeoServer behavior.
3. Submit a crafted query containing a malicious XPath or property expression through a user-controllable request parameter.
4. Trigger vulnerable GeoTools expression evaluation and execute commands in the context of the Java application process.
5. Run reconnaissance commands such as user, host, network, and environment discovery.
6. Download or stage additional payloads, web shells, reverse shells, miners, or remote access tooling.
7. Attempt persistence, credential access, data exfiltration, or lateral movement depending on the privileges and network reachability of the compromised service.

How to detect it

Look for evidence in web server access logs, reverse proxy logs, application logs, Java exception logs, WAF telemetry, EDR process telemetry, DNS logs, and outbound network logs. Focus on requests to geospatial service endpoints that include suspicious XPath, Java class, command execution, or scripting strings in parameters such as `propertyName`, `valueReference`, `filter`, `CQL_FILTER`, `typeName`, `request=GetFeature`, or XML filter bodies. Review logs for URL-encoded payloads and repeated probing of WFS or feature query endpoints. In application logs, look for errors involving XPath evaluation, expression parsing, GeoTools complex feature handling, `gt-complex`, or Java reflection. In host telemetry, investigate Java parent processes spawning shell or system utilities, which is abnormal for most geospatial services. Also check for post-exploitation activity such as downloads from the Java process, outbound connections to unknown IPs, creation of files in temporary directories, web-accessible dropped files, cron/systemd persistence, new users, SSH key changes, cryptocurrency miner processes, or reverse shell behavior. Because reported exploitation campaigns include GeoServer-focused activity and named campaigns such as StrikeShark, correlate suspicious geospatial requests with any subsequent process execution, external callbacks, or credential-access behavior from the same host.

• /geoserver/wfs
• /geoserver/ows
• service=WFS
• request=GetFeature
• propertyName=
• valueReference=
• CQL_FILTER=
• gt-complex
• org.geotools
• org.geotools.xsd
• org.geotools.filter
• org.geotools.data.complex
• java.lang.Runtime
• Runtime.getRuntime
• ProcessBuilder
• getRuntime().exec
• javax.script.ScriptEngineManager
• java.lang.ProcessBuilder
• /bin/sh
• /bin/bash
• cmd.exe
• powershell
• curl
• wget
• bash -c
• sh -c
• nc -e
• ncat -e
• python -c
• perl -e
• /tmp/
• /var/tmp/
• XPathException
• XPathExpressionException
• Failed to evaluate XPath
• Error evaluating XPath
• Invalid propertyName
• Invalid valueReference

What your security team should do

• Prioritize internet-facing GeoTools, GeoServer, or geospatial query services for immediate inventory and remediation because exploitation is weaponized and EPSS is high.
• Upgrade affected GeoTools dependencies to 31.2, 30.4, 29.6, or later; apply Debian 13 fixed package version 6.8.9-1 where relevant.
• If upgrades cannot be completed immediately, remove `gt-complex` or deploy the official drop-in replacement JAR appropriate for the in-use GeoTools branch, then plan a full upgrade.
• Restrict public access to WFS, feature query, and complex feature endpoints using authentication, network allowlists, reverse proxy rules, or service segmentation.
• Search historical logs for exploit attempts, especially requests containing Java execution primitives in query parameters such as `propertyName`, `valueReference`, `filter`, `CQL_FILTER`, or XML filter bodies.
• Treat any confirmed exploitation as host compromise: isolate the system, preserve logs and memory/disk evidence, rotate credentials accessible to the service, and hunt for payloads or persistence.
• Monitor for threat actor tradecraft associated with reported GeoServer/GeoTools exploitation campaigns, including StrikeShark and campaigns targeting government agencies.
• Add dependency scanning and software composition analysis checks to detect vulnerable GeoTools versions inside application builds, containers, and shaded Java archives.