CVE-2025-30220

What it actually does

This is an XML External Entity (XXE) vulnerability in GeoServer Web Feature Service processing through GeoTools XML parsing. A crafted WFS XML request can cause the server-side parser to resolve external DTDs or entities despite expected resolver protections. Successful exploitation can trigger outbound network requests from the GeoServer process, enabling out-of-band data exfiltration of files readable by that process and server-side request forgery against internal or cloud metadata services. The impact is high because the attack can be performed remotely against exposed WFS endpoints and may disclose sensitive configuration, credentials, tokens, or internal network information.

Why it matters to the business

An exposed vulnerable GeoServer or dependent application can be used as a foothold to steal sensitive local files or make trusted internal network requests from the server. This can lead to credential exposure, cloud token theft, data leakage, regulatory reporting obligations, and disruption of geospatial services. Although this vulnerability is not currently listed in CISA KEV, it has a high severity score, a high EPSS likelihood, is described as weaponized, and has been public for over a year, so internet-facing systems should be treated as urgent remediation targets.

How an attack unfolds

An attacker identifies an internet-accessible GeoServer or application using vulnerable GeoTools WFS XML parsing. They send a crafted XML request to a WFS endpoint that declares an external DTD or entity. The vulnerable parser resolves the external reference and initiates an outbound request to attacker-controlled infrastructure or to an internal address. The attacker uses this behavior to confirm exploitability through DNS or HTTP callbacks, then attempts to read local files accessible to the GeoServer process or force requests to internal services such as cloud metadata endpoints. Any retrieved data can be exfiltrated through out-of-band callbacks, potentially exposing secrets that enable follow-on compromise.

How to fix it

Upgrade affected software to a fixed version or vendor release that includes the relevant fix. For source-based deployments, ensure GeoTools includes commit 4f5e91f481b5779b63e3bcecb3bf25389bca0ca9, GeoServer includes commit 4a7a6881894a879f097ca2f04d62733fcdaa2937, and GeoNetwork includes commit d8dfca59671ac916b9860b2281104fc3c1323414. For Android downstream packages listed as affected, ensure the platform/packages/modules/Bluetooth component is at the 2025-03-01 fixed level for Android 15 or 15-next where applicable. If immediate upgrade is not possible, restrict access to WFS endpoints to trusted networks, disable unnecessary WFS functionality, block XML external entity and external DTD resolution at the parser/application layer, and enforce strict egress filtering so GeoServer cannot reach arbitrary internet destinations, loopback-only services, internal management networks, or cloud metadata endpoints.

How to confirm the fix worked

Confirm deployed versions or build provenance show the fixed GeoTools, GeoServer, and GeoNetwork commits or vendor releases containing them. Review dependency trees for bundled GeoTools versions because vulnerable parsing may be inherited by downstream applications. Validate configuration to ensure XML external entity and external DTD resolution are disabled. Perform a controlled non-sensitive test using a canary external DTD or entity URL monitored by the defender; a fixed system should not make outbound DNS or HTTP requests as a result of parsing the XML. Verify network controls block egress from the application process to unapproved external destinations and to sensitive internal ranges such as cloud metadata services. Re-scan exposed endpoints after patching to ensure WFS services are not publicly reachable unless explicitly required.

Typical attack path

1. Discover exposed GeoServer, GeoNetwork, or other GeoTools-based services with WFS enabled.
2. Fingerprint WFS endpoints such as /geoserver/wfs and confirm XML request handling.
3. Send a crafted XML payload containing an external DTD or external entity reference.
4. Observe whether the server performs outbound DNS or HTTP requests to attacker-controlled infrastructure.
5. Use the XXE behavior to attempt local file disclosure from paths readable by the application process.
6. Use SSRF behavior to probe internal services, loopback addresses, or cloud metadata endpoints.
7. Exfiltrate discovered secrets or configuration data through out-of-band callbacks.
8. Use exposed credentials, tokens, or internal service access for lateral movement or further compromise.

How to detect it

Investigate both inbound exploit attempts and outbound callbacks. Review reverse proxy, load balancer, WAF, servlet container, and GeoServer application logs for POST requests to WFS endpoints containing XML declarations, DOCTYPE definitions, ENTITY declarations, SYSTEM or PUBLIC external identifiers, file:// references, or unusual protocol references. Correlate timestamps with DNS resolver logs, proxy logs, firewall logs, and EDR telemetry for outbound connections from Java, Tomcat, Jetty, or GeoServer processes to unknown domains, newly registered domains, IP literals, paste/collaboration servers, or cloud metadata addresses. Look for requests from the application host to 169.254.169.254, localhost, RFC1918 addresses, or unexpected ports shortly after WFS requests. Examine application logs for XML parser errors mentioning DTD, entity resolution, external entity, SAXParseException, or blocked external access. If suspected exploitation occurred, inspect whether sensitive files commonly readable by the service account may have been accessed or exfiltrated, including application configuration, keystores, environment files, cloud credential files, and service account tokens.

• /geoserver/wfs
• service=WFS
• <!DOCTYPE
• <!ENTITY
• SYSTEM
• PUBLIC
• file://
• file:///etc/passwd
• file:///proc/self/environ
• file:///proc/self/cmdline
• file:///var/lib/geoserver
• file:///opt/geoserver
• file:///usr/share/geoserver
• jar:file:
• http://169.254.169.254
• https://169.254.169.254
• 169.254.169.254/latest/meta-data
• metadata.google.internal
• 169.254.169.254/metadata/instance
• 169.254.170.2
• SAXParseException
• External Entity
• external entity
• DOCTYPE is disallowed
• accessExternalDTD
• disallow-doctype-decl

What your security team should do

• Prioritize patching internet-facing GeoServer, GeoNetwork, and other GeoTools-based services because exploitation is weaponized and EPSS is high.
• Inventory all applications that embed GeoTools, not only standalone GeoServer deployments, and map them to fixed releases or commits.
• Restrict WFS endpoints to authenticated and trusted clients; remove public exposure where not business-critical.
• Implement egress controls for GeoServer/application hosts, especially blocking access to 169.254.169.254, localhost-only services, internal management networks, and arbitrary outbound HTTP, HTTPS, DNS, FTP, and LDAP destinations.
• Hunt historical web, application, DNS, proxy, and firewall logs for XML payloads containing DOCTYPE, ENTITY, external DTD, file://, and metadata-service references.
• Rotate credentials, API keys, cloud tokens, and database secrets stored in files readable by the GeoServer process if exploitation is suspected.
• Add SIEM detections for WFS requests containing XML external entity syntax and for unusual outbound connections initiated by Java application processes.
• Monitor vendor advisories and downstream package releases to ensure all bundled GeoTools components receive the fix.