Why this vulnerability matters
CVE-2025-58360 is a recently disclosed XML External Entity (XXE) vulnerability in OSGeo GeoServer that has now been added to the CISA Known Exploited Vulnerabilities (KEV) catalog, signaling confirmed in-the-wild exploitation and elevating it to a must-fix issue for any environment running GeoServer.
Because GeoServer often fronts geospatial data for critical infrastructure, government, and enterprise GIS deployments, a remotely exploitable XXE in a core web service endpoint represents a high-impact path to data exposure and internal network pivoting.
Technical overview of CVE-2025-58360
CVE-2025-58360 is classified as an Improper Restriction of XML External Entity Reference in the Web Map Service (WMS) GetMap operation of GeoServer, where user-supplied XML is parsed without safely disabling external entity resolution.
An unauthenticated attacker can submit a crafted WMS request that causes the GeoServer process to dereference local files or remote resources, enabling file disclosure, server-side request forgery (SSRF), and potentially denial-of-service conditions.
Affected versions include multiple 2.25.x and 2.26.x branches, with vendor guidance pointing to fixed releases such as 2.25.6 and 2.26.2/2.26.3 and later streams where XXE handling has been hardened.
Public exploit and scanner signatures now label this as a GeoServer WMS XXE, and security testing platforms already include checks against exposed /geoserver/wms endpoints, further lowering the barrier to exploitation.
CISA KEV listing and real-world exploitation
CISA’s decision to add CVE-2025-58360 to the KEV catalog means federal agencies are mandated to remediate it within defined timelines and that exploit activity has been observed rather than merely theorized.
Security practitioners and enterprises that track KEV as a de facto exploitation barometer should interpret this listing as a strong prioritization signal, placing vulnerable GeoServer instances into the “patch or isolate immediately” bucket rather than “routine patch cycle.”
Threat intel reporting and community posts indicate active scanning and exploitation attempts against internet-exposed GeoServer services, including honeypots specifically targeted via WMS XXE payloads mapped to this CVE.
Given the typical deployment pattern of GeoServer behind GIS portals and mapping apps, successful exploitation could quietly expose sensitive configuration files, credential stores, and internal service metadata that support further intrusions.
Risk and impact for enterprise environments
From a risk perspective, the combination of unauthenticated remote reachability, data exfiltration via XXE, and KEV-confirmed exploitation places CVE-2025-58360 firmly in the “high” to “critical” category for most organizations running GeoServer.
Attackers can abuse XXE to read local files such as configuration archives, keystores, or credential files, and to probe internal HTTP(S) services reachable from the GeoServer host, effectively using the server as an SSRF proxy into otherwise non-internet-facing systems.
Environments using GeoServer as part of critical mapping or operational dashboards—such as utilities, smart cities, logistics, or government GIS—face heightened business impact if compromise of the GeoServer host enables lateral movement into OT networks or sensitive backend systems.
Moreover, because WMS endpoints are often embedded in third-party applications and iframes, teams may underestimate their external exposure, leading to internet-facing attack surface that is not accurately reflected in CMDBs and asset inventories.
Typical attack path
- Reconnaissance: Adversaries identify GeoServer instances using search engines, internet-wide scanners, or WMS-specific fingerprints such as characteristic response headers and paths like
/geoserver/wms. - Exploitation: Crafted XXE payloads are issued in WMS requests to force GeoServer to retrieve local files (for example, configuration or credentials) or reach internal HTTP endpoints from the server’s network context.
- Post-exploitation: Stolen secrets enable follow-on access to databases, application servers, or management interfaces, while SSRF-style attacks can map and attack otherwise internal-only services.
Detection strategies
Defenders should start by inventorying all GeoServer instances, focusing on external attack surface and any system where /geoserver/wms or related WMS endpoints are reachable from the internet or partner networks.
Log analysis for unusual or malformed WMS requests, particularly those containing explicit XML entities, references to file:// URIs, or unexpected remote URLs, can help identify exploitation attempts or successful XXE payloads.
Network-based controls such as IDS/IPS and WAFs can be tuned to flag or block suspicious XML in WMS requests, especially payloads attempting to access local file schemes or internal IP address ranges.
Security teams should also correlate incoming GeoServer requests with outbound connections from the GeoServer host, looking for egress to unusual domains or internal endpoints that are not part of normal WMS workflows.
Remediation and hardening guidance
The primary remediation for CVE-2025-58360 is to upgrade GeoServer to a vendor-designated fixed release, such as 2.25.6 or 2.26.2/2.26.3 or later, where XXE processing is appropriately restricted in the WMS GetMap pipeline.
Organizations should align patching with KEV-driven timelines where applicable, treating GeoServer hosts as high-priority assets for emergency change windows rather than deferring to regular patch schedules.
Until patching is complete, compensating controls can significantly reduce risk, including:
- Restricting external access to GeoServer via VPN or IP allowlists so that WMS endpoints are not directly internet-facing.
- Deploying or tuning a WAF rule set to detect and block XXE-style payloads in WMS requests, focusing on entity declarations and external URI schemes.
- Increasing logging verbosity on GeoServer and upstream proxies to capture full request details for security monitoring and possible incident response.
From a longer-term perspective, teams should treat GeoServer as a Tier-1 internet-facing application with appropriate security hygiene: regular vulnerability scanning with CPE-based detection for cpe:2.3:a:geoserver:geoserver:*, integration into ASM/attack surface management workflows, and continuous monitoring for new CVEs and KEV additions.
Embedding GeoServer into SSO, central logging, and hardened OS baselines, and isolating it within carefully segmented network zones, further reduces the blast radius of any future vulnerabilities that reach KEV status.
