CVE-2025-58360: GeoServer XXE file-disclosure flaw, in CISA KEV
The short version: GeoServer — the open-source geospatial data server — has an XML External Entity (XXE) flaw in its WMS GetMap endpoint (CVE-2025-58360) that an unauthenticated attacker can use to read files off the server and probe internal systems. It's listed in CISA's Known Exploited Vulnerabilities catalog. Patch to a fixed release and confirm whether you run an exposed instance. Steady hands — but move.
At a glance
| Fact | Detail |
|---|---|
| Our severity take | High — in practice (see below) |
| CVSS v3.1 (NVD) | 9.8 — Critical · AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H |
| CVSS (vendor / GitHub CNA) | 8.2 — High (reflects the information-disclosure impact) |
| EPSS | ~67.36% · 99th percentile (2026-07-17) |
| In CISA KEV? | Yes — remediate by 2026-01-01 |
| Known exploited? | Yes — listed in CISA KEV |
| Vulnerability type | CWE-611 improper restriction of XML external entity reference → local file disclosure / SSRF |
| Requires authenticated session? | No — pre-authentication |
| Affected | GeoServer before 2.25.6, and the 2.26.x series before 2.26.3 |
| Fixed in | 2.25.6 · 2.26.3 · 2.27.0 |
What you need to know
GeoServer accepts XML input through the /geoserver/wms GetMap operation. Because that input isn't sufficiently restricted, an attacker can define external entities inside the request — the classic XXE pattern. The server then resolves those entities, which can pull the contents of local files back to the attacker and, depending on configuration, make outbound requests to internal systems (SSRF).
A few reasons to prioritize it:
- It's pre-authentication and network-reachable. GeoServer instances are frequently exposed so that maps and geospatial layers can be consumed by other applications.
- It's already on CISA's KEV list. The theoretical is now operational, with a federal remediation deadline that has passed.
One honest caveat on testing: exploiting this flaw can crash the service if the attacker requests a file that doesn't exist on the target — so it's not a vulnerability we (or anyone) can safely prove by exploitation without risking availability.
How serious we see it
High — in practice.
The NVD scores it 9.8, while GitHub (the CNA) scored it 8.2 to reflect that the core impact is file disclosure and SSRF rather than clean code execution. We land at High: it's unauthenticated, internet-reachable, KEV-listed, and an XXE that reads arbitrary files can hand over credentials and configuration that enable the next step. The bounded, reassuring part is that it affects specific GeoServer versions, the fixes are published, and you can determine your exposure quickly.
Recommendations
Straight from the GeoServer advisory and CISA:
- Patch now. Upgrade to 2.25.6, 2.26.3, or 2.27.0 (or later).
- Restrict exposure until you patch. Limit access to the GeoServer instance to trusted IP addresses, and keep it off the open internet where you can.
- Hunt. Review access logs for anomalous
GetMaprequests to/geoserver/wmscarrying XML payloads. - Confirm your exposure first. Verify whether you run an internet-facing GeoServer at all, and which version.
How BreachRisk sees it
BreachRisk starts from the outside, the way an attacker does. From little more than your domain it discovers internet-facing GeoServer instances, fingerprints the version from the application's responses, and flags exposure tied to this CVE — pushed to the top of your results because it's in CISA's KEV catalog. We detect and flag the exposed, affected version; we don't exploit this one, precisely because exploitation risks crashing the service.
That continuous, outside-in view means an exposed GeoServer is already mapped when a flaw like this surfaces — so you go straight to patch-and-verify instead of starting from an inventory hunt.