PatchDayAlert
Analysis · 5 min read · 982 words By Colten Anderson · Commentary

GeoServer CVE-2024-36401: The Map Nobody Owned

A CVSS 9.8 unauthenticated RCE in GeoServer sat unpatched at thousands of agencies for weeks. The bug was the easy part. The reason nobody patched it is the real story.

A government building map layer with an unpatched server icon at the center

The GIS team knew exactly where every GeoServer instance lived. The security team didn’t know GeoServer existed. An attacker found it before either of them got around to the patch.

That is the whole story of CVE-2024-36401, and it is not primarily a story about a bug. The bug is almost boring once you see it. GeoServer evaluates property name expressions from OGC filter requests by handing them to the commons-jxpath library, which appears to evaluate those strings as executable XPath-like expressions against Java objects. User-supplied values went to the evaluator unsanitized. So a single unauthenticated HTTP request, the kind that looks like every other map query the server answers all day, runs an arbitrary OS command in the context of the GeoServer process. That process runs as whatever account Tomcat uses, often a service account with more reach than anyone audited. CVSS 9.8. No login. No interaction.

A request to do it is short enough to fit in a tweet:

GET /geoserver/ows?service=WFS&version=2.0.0&request=GetPropertyValue
  &typeNames=sf:archsites
  &valueReference=exec(java.lang.Runtime.getRuntime(),new+String[]{"id"})

Same injection works through CQL_FILTER on WMS, and through OGC XML filters in a POST body. There is no clever chaining here, no auth bypass to stack on top. The endpoint that does the dangerous thing is the endpoint the product exists to serve.

The patch landed in mid-2024: GeoServer 2.23.6, 2.24.4, and the 2.25 branch (verify the exact 2.25.x release number against the GitHub advisory before you deploy). A public proof-of-concept followed within days. CISA added it to the Known Exploited Vulnerabilities catalog in July 2024, which is the federal government’s way of saying this is not theoretical, people are doing it right now. Trend Micro documented a China-nexus actor, Earth Baxia, using the flaw against government agencies across Taiwan, the Philippines, South Korea, India, and other parts of Asia-Pacific, dropping Cobalt Strike beacons and a custom backdoor they call EAGLEDOOR. Below that tier, the opportunists arrived on schedule: XMRig miners, JSP webshells, reverse shells, mass scanning confirmed by internet-scan researchers.

Here is the number that should bother you. At disclosure, research put publicly reachable GeoServer instances somewhere between 25,000 and 45,000. Weeks after the fix shipped, a lot of them were still vulnerable. Not because the patch was hard. Because no one whose job it is to apply patches was looking at these boxes.

GeoServer is open-source Java, developed under the Open Source Geospatial Foundation, deployed as a WAR file in Tomcat. It is how national mapping agencies, geological surveys, transportation authorities, utilities, county GIS departments, and military GIS teams publish spatial data to browsers and desktop clients. By design, it faces the internet. That is the use case. You stand it up so people outside your network can pull map layers.

Now follow the org chart. The person who deploys GeoServer is a GIS analyst, not a sysadmin. They downloaded it for free, so there is no purchase order, no license key, no renewal date, no vendor account rep who emails when something breaks. They gave it a routable IP because the job requires one. It never showed up in the CMDB, because nothing generated a record. Standard vulnerability scanners often don’t fingerprint it. And when the exploit traffic comes in, it rides on normal OGC request parameters, so it looks like legitimate map activity in the logs.

The advisory? It went to whoever watches the GeoServer GitHub repo or the OSGeo mailing list. Statistically, that is not the security team. It might not be anyone at your org at all.

So you have software that is internet-facing by requirement, holds some of the most sensitive geospatial data an organization owns, and lives in a blind spot that the procurement process, the asset inventory, and the scanner all share. Pipe routing. Substation coordinates. Grid topology. Cadastral records. Unclassified base logistics. Emergency services infrastructure. The data that a state actor would build an entire campaign to reach, served by a box that your security program has no record of.

This keeps happening, and the reason is structural, not careless. Commercial software gets patched because someone is paid to maintain the relationship: a renewal forces a conversation, a vendor pushes updates, an account shows up in the budget. Free software cuts that thread. There is no invoice to remind anyone it exists. The thing that makes open-source GIS accessible to a two-person county team is the same thing that makes it invisible to that county’s security review. GeoServer didn’t fall through a crack. It fell into the exact gap between “GIS owns it” and “IT patches it,” and that gap is wide enough to park 40,000 servers in.

What should you actually expect here. Expect that authentication does not save you; the vulnerable OGC endpoints take unauthenticated requests by design, so locking the admin console accomplishes nothing against this. Expect that if you can’t patch immediately, removing or renaming gt-complex-x.y.jar from WEB-INF/lib/ disables the jxpath evaluation path and holds the line, at the cost of possibly breaking complex feature types or XPath-heavy SLD styles, which most deployments don’t use. Expect to find evidence in access logs: exec(, getRuntime, or java.lang.Runtime in query strings or POST bodies to /geoserver/ows, /wfs, /wms, or /wcs. And expect that the honest first step isn’t the patch at all. It’s the question nobody asked before July 2024: do we run this, and if we do, who exactly is watching it?

That is the question PatchDayAlert is built around. We track KEV-listed bugs in exactly this category, software that holds critical data and answers to no one in particular, and we flag them in plain language before the GIS team and the security team finish arguing about whose ticket it is.

The fix for CVE-2024-36401 is two downloads and a service restart. The fix for the reason it sat unpatched while a foreign intelligence service walked through it is a lot more than that, and no version number closes it.

Share

Related field notes

Get the free CVE triage cheat sheet

Subscribe and we'll email you the one-page triage flow for fresh CVEs. Plus the weekly digest.

Subscribe