The U.S. Cybersecurity and Infrastructure Security Agency (CISA) has issued a directive concerning CVE-2025-58360, a critical unauthenticated XML External Entity (XXE) injection vulnerability in OSGeo GeoServer. With a CVSS score ranging from 8.2 to 9.8, the flaw is being actively exploited in the wild. This has prompted CISA to add it to its Known Exploited Vulnerabilities (KEV) catalog, requiring federal agencies to apply patches by January 1, 2026. The vulnerability allows remote, unauthenticated attackers to exfiltrate sensitive files, pivot to internal networks via Server-Side Request Forgery (SSRF), or cause a denial of service. Given GeoServer's widespread use for sharing geospatial data, all organizations utilizing this software are at significant risk and should prioritize remediation.
The vulnerability exists in the /geoserver/wms endpoint during GetMap operations. GeoServer fails to properly sanitize user-supplied XML input, allowing an attacker to submit a crafted XML payload containing external entity declarations.
An attacker can exploit this flaw in several ways:
/etc/passwd, configuration files with credentials) in the XML payload, an attacker can exfiltrate their contents.CISA has confirmed that CVE-2025-58360 is being actively exploited in the wild. While specific details about the threat actors or their targets have not been released, the inclusion in the KEV catalog indicates observed, real-world attacks. Unauthenticated, high-impact vulnerabilities like this are prime targets for both opportunistic cybercriminals and state-sponsored actors for initial access and data theft.
T1190 - Exploit Public-Facing Application: The primary technique used to gain initial access.T1530 - Data from Local System: The XXE vulnerability is used to read and collect local files.T1599 - Compromise Infrastructure: The SSRF capability allows attackers to probe and potentially compromise other internal systems.T1499 - Endpoint Denial of Service: The DoS aspect of the vulnerability can be used to disrupt services.Successful exploitation of this vulnerability can have severe consequences. The exfiltration of configuration files could expose database credentials, API keys, or other secrets, leading to a full system compromise. The SSRF capability transforms a public-facing server into a pivot point, bypassing perimeter defenses and allowing attackers to map and attack the internal network. For government agencies and companies that rely on GeoServer for critical mapping and location-based services, a DoS attack could disrupt essential operations. The addition to the KEV catalog signifies a clear and present danger to all unpatched systems.
Security teams can hunt for signs of exploitation by reviewing web server logs for suspicious requests.
| Type | Value | Description |
|---|---|---|
url_pattern |
*/geoserver/wms* |
Focus hunting on requests to the vulnerable WMS endpoint. |
network_traffic_pattern |
requests containing "<!ENTITY" |
In the body of POST requests to the WMS endpoint, look for XML payloads that declare external entities. |
log_source |
Web Server Access Logs |
Look for GetMap requests that result in unusual error messages or response sizes, which could indicate a failed or successful exploitation attempt. |
network_traffic_pattern |
Outbound connections from GeoServer to internal IPs |
Monitor for network connections originating from the GeoServer host to other internal systems, which could be indicative of an SSRF attack. |
/geoserver/wms endpoint that contain common XXE payloads or keywords like ENTITY, SYSTEM, or PUBLIC. This aligns with D3FEND File Analysis (D3-FA) on inbound request bodies.<!ENTITY in the body, providing a virtual patch.Upgrading to a patched version of GeoServer is the most effective way to remediate this vulnerability.
Running GeoServer in a containerized or isolated environment can help limit the impact of a successful SSRF attack.
Using a WAF to filter malicious XML payloads and implementing egress filtering to block SSRF attempts are key mitigations.
If the WMS service is not required for business operations, disabling it entirely removes the attack surface.
The definitive countermeasure for CVE-2025-58360 is to apply the security patches released by the OSGeo project. Organizations must immediately upgrade their GeoServer instances to version 2.26.2, 2.25.6, or newer. Given that this is an unauthenticated, remotely exploitable vulnerability on the CISA KEV list, it should be treated as an emergency change. Asset management systems should be used to identify all instances of GeoServer in the environment, including those in development and staging, as they can also be exploited for pivoting. Patching not only fixes the XXE vulnerability but also protects against the associated risks of data exfiltration, SSRF, and DoS. After patching, it is crucial to verify the update was successful by checking the application's version number.
For organizations unable to immediately patch, Inbound Traffic Filtering via a Web Application Firewall (WAF) can serve as a critical compensating control (virtual patch). The WAF should be configured with rules specifically designed to detect and block XXE attack patterns. A rule should be created to inspect the body of POST requests to the /geoserver/wms endpoint. This rule should block any request containing the string <!ENTITY, which is fundamental to XXE payloads. While attackers may attempt to obfuscate this, a well-configured WAF can detect many variations. This approach prevents the malicious payload from ever reaching the vulnerable GeoServer application. While highly effective as a short-term mitigation, it should not be considered a permanent replacement for applying the official software update, as sophisticated attackers may eventually find ways to bypass WAF rules.
To mitigate the impact of a successful SSRF attack through CVE-2025-58360, strict Outbound Traffic Filtering should be implemented on the host running GeoServer. The server's firewall or cloud security group should be configured with a default-deny policy for all egress traffic. Explicit allow rules should then be created only for the specific connections required for the server's operation (e.g., to a specific database server on its designated port, to known external APIs). Critically, this policy should block all outbound connections from the GeoServer host to the internal network (e.g., RFC1918 IP space), except for those explicitly required. This would prevent an attacker from using the SSRF vulnerability to scan the internal network, connect to other services, or pivot deeper into the environment, effectively containing the breach to the compromised server.

Cybersecurity professional with over 10 years of specialized experience in security operations, threat intelligence, incident response, and security automation. Expertise spans SOAR/XSOAR orchestration, threat intelligence platforms, SIEM/UEBA analytics, and building cyber fusion centers. Background includes technical enablement, solution architecture for enterprise and government clients, and implementing security automation workflows across IR, TIP, and SOC use cases.
Help others stay informed about cybersecurity threats