CVE-2025-58360

What it actually does

This is an XML External Entity (XXE) flaw in XML processing for the GeoServer WMS GetMap operation at /geoserver/wms. A vulnerable XML parser accepts attacker-controlled document type definitions and external entity references, allowing the server to resolve local file paths or make outbound network requests from the GeoServer host. Depending on parser behavior, network egress, filesystem permissions, and response handling, exploitation can result in arbitrary local file disclosure, server-side request forgery (SSRF) against internal services, cloud metadata access, internal port scanning, or denial of service through resource exhaustion.

Why it matters to the business

A successful attack can expose sensitive configuration files, credentials, geospatial data, service tokens, or internal network details and can also disrupt mapping/GIS services through denial of service. Because this issue is listed in CISA KEV, has active in-the-wild exploitation, and has a high EPSS score, internet-facing GeoServer instances should be treated as high-priority remediation targets. Organizations relying on affected SUSE OpenStack-related python-PyKMIP packages or GeoServer builds should prioritize upgrades before the KEV due date of 2026-01-01 or sooner where exposed to untrusted users.

How an attack unfolds

An attacker first identifies a reachable GeoServer WMS endpoint, usually by probing for /geoserver/wms and supported GetMap operations. They then submit a crafted XML request containing a document type declaration and external entity definition. If the XML parser is configured insecurely, the server resolves the external entity from the local filesystem or from an attacker-specified URL. For file disclosure, the attacker causes the parser to read local files that the GeoServer process can access and attempts to have the contents reflected in an error, response body, callback, or secondary request. For SSRF, the attacker points the external entity at internal addresses, metadata services, or private administrative endpoints and observes timing, errors, response differences, or outbound callbacks. For denial of service, the attacker abuses XML expansion or external resource resolution to consume CPU, memory, file handles, or network resources. Public exploitation activity has been observed against OSGeo GeoServer deployments, so exposed endpoints should be reviewed for both patch status and historical signs of malicious XML input.

How to fix it

Upgrade affected products to fixed versions. For GeoServer source builds, use a version containing commit dab1947ce0d1a46418ae690734be5ccc5252057b or a later vendor-supported release. For SUSE packages, update python-PyKMIP on HPE Helion OpenStack 8, OpenStack Cloud 8, and OpenStack Cloud Crowbar 8 to 0.6.0-3.3.1 or later. In addition to patching, disable DTD processing and external entity resolution in XML parsers, block XInclude where not required, enforce strict XML schema validation, and reject requests containing DOCTYPE or ENTITY declarations if those constructs are not expected. Restrict access to /geoserver/wms to trusted clients where possible, place the service behind authentication or a WAF/reverse proxy, limit outbound network egress from GeoServer hosts, block access to cloud metadata IPs and internal administrative networks, and run the service with least-privilege filesystem permissions.

How to confirm the fix worked

Confirm installed package or build versions match the fixed versions: python-PyKMIP 0.6.0-3.3.1 or later for the listed SUSE products, and GeoServer builds containing commit dab1947ce0d1a46418ae690734be5ccc5252057b or later. Review release notes or dependency manifests to verify the XML parser configuration disables external entity resolution and DTD processing. Test non-destructively by submitting a benign XML request containing a DOCTYPE declaration to /geoserver/wms GetMap and confirm it is rejected, ignored, or processed without resolving external resources. Monitor outbound network telemetry during testing to verify the server does not initiate connections based on XML entity references. Validate compensating controls by confirming WAF/reverse-proxy rules block suspicious XML constructs and that host/network egress policies prevent connections to loopback, RFC1918, link-local, and cloud metadata addresses unless explicitly required.

Typical attack path

1. Discover a GeoServer instance or WMS endpoint exposed to the internet or an untrusted network.
2. Confirm that /geoserver/wms accepts requests using the GetMap operation and XML input.
3. Send crafted XML containing a DOCTYPE declaration and external entity reference.
4. Force the vulnerable XML parser to resolve a local file path or an internal network URL.
5. Extract file contents through application responses, errors, or outbound callbacks, or infer internal service exposure from timing and response differences.
6. Use disclosed configuration, credentials, or network knowledge to expand access, or repeatedly trigger XML parsing behavior to degrade service availability.

How to detect it

Investigate web server, reverse proxy, WAF, GeoServer application, Java application server, DNS, firewall, proxy, EDR, and cloud metadata access logs. Focus on requests to /geoserver/wms using GetMap that contain XML document type declarations, entity definitions, external URLs, local file URI references, or encoded variants of those strings. Look for HTTP 400/500 errors, stack traces, unusual XML parsing errors, large request bodies, repeated GetMap failures, or spikes in CPU and memory after XML requests. Correlate inbound suspicious requests with outbound connections from the GeoServer host or Java process to unfamiliar domains, attacker-controlled infrastructure, internal RFC1918 addresses, loopback addresses, link-local 169.254.169.254, or nonstandard ports. For suspected file disclosure, review whether the same source IP attempted to reference sensitive paths such as /etc/passwd, /proc/self/environ, application configuration files, credential stores, SSH keys, or cloud metadata endpoints. Because exploitation has been observed in the wild, conduct a lookback from at least the publication date and extend based on log retention and any prior anomalous WMS activity.

• /geoserver/wms
• GetMap
• <!DOCTYPE
• %3C!DOCTYPE
• <!ENTITY
• %3C!ENTITY
• SYSTEM
• PUBLIC
• SYSTEM "file:
• SYSTEM 'file:
• file:///etc/passwd
• file:/etc/passwd
• /etc/shadow
• /etc/hosts
• /proc/self/environ
• /proc/self/cmdline
• /proc/version
• /root/.ssh/id_rsa
• WEB-INF/web.xml
• geoserver_data_dir
• security/masterpw.info
• security/users.properties
• security/role/default/roles.xml
• 169.254.169.254
• http://169.254.169.254
• latest/meta-data
• metadata.google.internal
• 169.254.169.254/latest/meta-data/iam/security-credentials
• http://localhost
• http://127.0.0.1
• http://[::1]
• gopher://
• jar:
• netdoc:
• expect://
• java.net.ConnectException
• SAXParseException
• DOCTYPE is disallowed
• External Entity
• EntityResolver
• java.io.FileNotFoundException

What your security team should do

• Immediately inventory GeoServer and affected SUSE OpenStack-related python-PyKMIP deployments, prioritizing internet-facing or partner-facing systems.
• Patch or upgrade to the fixed versions as the primary control; do not rely solely on WAF signatures for a KEV-listed, actively exploited vulnerability.
• Restrict access to /geoserver/wms and other XML-processing endpoints to trusted networks or authenticated users where business requirements allow.
• Disable XML DTDs, external entities, and XInclude in application and framework XML parser configurations.
• Implement egress filtering from application hosts to prevent SSRF to internal networks, cloud metadata services, loopback, and administrative interfaces.
• Search historical web, application, WAF, proxy, DNS, and egress logs for XXE indicators, especially requests to /geoserver/wms containing DOCTYPE, ENTITY, SYSTEM, PUBLIC, file:, or unusual callback URLs.
• Review GeoServer service account permissions and remove unnecessary filesystem read access to secrets, configuration backups, SSH keys, and cloud credentials.
• Rotate credentials or tokens stored on affected servers if logs suggest successful file disclosure or suspicious outbound callbacks.
• Add SIEM detections for malicious XML constructs in WMS requests and for unexpected outbound connections initiated by GeoServer or Java application processes.
• Track the CISA KEV deadline of 2026-01-01 as the latest acceptable remediation date, but remediate sooner for externally reachable deployments.