CVE-2025-30220 is a critical (CVSS 9.9) XML external entity flaw in the GeoTools library, which affects GeoServer and GeoNetwork. Fixes are in GeoTools 33.1, 32.3, 31.7 and 28.6.1, GeoServer 2.27.1, 2.26.3 and 2.25.7, and GeoNetwork 4.4.8 and 4.2.13. Check which of these products you run, including copies inside other software.
What's affected
The record lists fixes in GeoTools 33.1, 32.3, 31.7 and 28.6.1, GeoServer 2.27.1, 2.26.3 and 2.25.7, and GeoNetwork 4.4.8 and 4.2.13.
The GeoServer advisory lists affected versions as 2.27.0, 2.26.0 through 2.26.2, and 2.25.6 and earlier. The GeoNetwork advisory lists 4.4.0 through 4.4.7 and 4.2.0 through 4.2.12 as affected.
The risk applies to anyone who exposes XML processing that involves gt-xsd-core, when documents carry a reference to an external XML schema. It also affects users of the gt-wfs-ng data store where the ENTITY_RESOLVER connection parameter did not work as intended. GeoNetwork's advisory adds a workaround: remove the gn-wfsfeature-harvester and gn-camelPeriodicProducer jars, which disables WFS Index functionality.
How to check if you're exposed
Check which of the three products you run, and which GeoTools version they use.
- For GeoServer, open the About page in the web admin and read the version. Compare with 2.27.1, 2.26.3 and 2.25.7.
- For GeoNetwork, check the version in the admin console, and compare with 4.4.8 and 4.2.13.
- For Java applications that embed GeoTools, run mvn dependency:tree -Dincludes=org.geotools and look for gt-xsd-core and gt-wfs-ng.
Safeguard's free in-browser dependency scan at gold.safeguard.sh/scan can show whether a project's dependency list includes an affected component, and the Gold directory lets you look up the CVE and its related weaknesses.
What to do now
- Inventory GeoServer, GeoNetwork and any application that embeds GeoTools.
- Upgrade to a fixed version: GeoServer 2.27.1, 2.26.3 or 2.25.7, GeoNetwork 4.4.8 or 4.2.13, or GeoTools 33.1, 32.3, 31.7 or 28.6.1.
- Apply the GeoServer production guidance on external entities in the docs linked below.
- If you cannot patch GeoNetwork right away, use the advisory's workaround of removing the two jars named above.
- Limit outbound network access from these servers so they cannot reach internal services or the internet unless required.
Why it matters
The record maps the flaw to CWE-611 (XML External Entity Reference) and CWE-918 (Server-Side Request Forgery). The GeoTools schema handling class did not use the entity resolver configured by the parser, so a document referencing an external schema could make the parser fetch things that the safe configuration was meant to block.
The GeoServer advisory says the outcome can be out-of-band exfiltration of local files readable by the GeoServer process, and server-side request forgery. GeoNetwork's advisory calls the issue especially severe because the REST endpoint involved was not secured, which could let unauthenticated attackers read sensitive files.
Geospatial servers often sit on the internet by design and run with access to data stores and configuration. That combination explains the 9.9 score. The lasting lesson is to configure XML parsers to reject external entities everywhere, and to test that the configuration is used.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Which product do I patch?
Whichever you run: GeoServer, GeoNetwork, or the GeoTools library inside your own application. Use the fixed versions listed above.
Is there a workaround for GeoNetwork?
Yes. The advisory says to remove the gn-wfsfeature-harvester and gn-camelPeriodicProducer jars, which disables the WFS Index functionality.
Sources
Last reviewed: 19 October 2026.
