GeoTools has XML External Entity (XXE) Processing Vulnerability in XSD schema handlingGHSA-826p-4gcg-35vw
CRITICALGHSA-826p-4gcg-35vw is a critical-severity (CVSS 9.9) vulnerability in org.geotools:gt-xsd-core. A fix is available for org.geotools:gt-xsd-core — see the affected versions and patch details below.
Real-World Exposure
org.geotools:gt-xsd-core☕org.geotools:gt-xsd-core☕org.geotools:gt-xsd-core☕org.geotools:gt-wfs-ng☕org.geotools:gt-wfs-ng☕org.geotools:gt-wfs-ng☕org.geotools:gt-xsd-core☕org.geotools:gt-wfs-ngReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Maven packages — download data is not available via public APIs for these ecosystems.
Description
Summary
GeoTools Schema class use of Eclipse XSD library to represent schema data structure is vulnerable to XML External Entity (XXE) exploit.
Impact
This impacts whoever exposes XML processing with gt-xsd-core involved in parsing, when the documents carry a reference to an external XML schema. The gt-xsd-core Schemas class is not using the EntityResolver provided by the ParserHandler (if any was configured).
This also impacts users of gt-wfs-ng DataStore where the ENTITY_RESOLVER connection parameter was not being used as intended.
Resolution
GeoTools API change allows EntityResolver to be supplied to the following methods:
Schemas.parse( location, locators, resolvers, uriHandlers, entityResolver);
Schemas.findSchemas(Configuration configuration, EntityResolver entityResolver);
With this API change the gt-wfs-ng WFS DataStore ENTITY_RESOLVER parameter is now used.
Reference
-
GHSA-jj54-8f66-c5pc: Describes the impact of the
gt-xsd-corevulnerability on the GeoServer WFS protocol, resulting in both Service Side Request Forgery (SSRF) and Out-of-Band (OOB) data exfiltration of local files. -
GHSA-2p76-gc46-5fvc: Describes the impact of the
gt-wfs-ngandgt-xsd-corevulnerability on the GeoNetwork WFS Index functionality.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| ☕Maven | org.geotools:gt-xsd-core | ≥ 33.0&&< 33.1 | 33.1org.geotools:gt-xsd-core:33.1 |
| ☕Maven | org.geotools:gt-xsd-core | ≥ 32.0&&< 32.3 | 32.3org.geotools:gt-xsd-core:32.3 |
| ☕Maven | org.geotools:gt-xsd-core | ≥ 29.0&&< 31.7 | 31.7org.geotools:gt-xsd-core:31.7 |
| ☕Maven | org.geotools:gt-wfs-ng | ≥ 33.0&&< 33.1 | 33.1org.geotools:gt-wfs-ng:33.1 |
| ☕Maven | org.geotools:gt-wfs-ng | ≥ 32.0&&< 32.3 | 32.3org.geotools:gt-wfs-ng:32.3 |
| ☕Maven | org.geotools:gt-wfs-ng | ≥ 29.0&&< 31.7 | 31.7org.geotools:gt-wfs-ng:31.7 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for org.geotools:gt-xsd-core, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update org.geotools:gt-xsd-core to 33.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-826p-4gcg-35vw is resolved across your whole dependency graph.
Workarounds
Restrict outbound requests from the affected component to an allowlist of hosts, block access to link-local and internal address ranges at the network layer, and require authentication on internal services so a forged request cannot reach them unauthenticated.
Frequently Asked Questions
Is GHSA-826p-4gcg-35vw in your dependencies?
Find it across Maven, including transitive dependencies.