Vulnerabilities

GeoTools' Schema classes (gt-xsd-core) use the Eclipse XSD library to represent schema data structures but do not apply the EntityResolver configured on the ParserHandler, leaving XML parsing vulnerable to XML External Entity (XXE) injection when a submitted document references an external XML schema. Any deployment that exposes XML processing through gt-xsd-core is impacted, including GeoServer's XML/WFS handling and users of the gt-wfs-ng DataStore, where the ENTITY_RESOLVER connection parameter was not applied as intended; a remote, unauthenticated attacker can trigger it by sending crafted XML referencing external entities. Successful exploitation can disclose local files (high confidentiality impact per the 9.1 CVSS), enable SSRF (CWE-918) toward internal networks, and exhaust resources (high availability impact). Affected users are GeoServer deployments prior to 2.25.7/2.26.3/2.27.1, GeoNetwork deployments prior to 4.4.8/4.2.13, and any application embedding affected GeoTools versions. There is no CISA KEV listing or confirmed in-the-wild exploitation in the available data, but a public advisory exists and EPSS assigns a 46.1% probability of exploitation within 30 days (99th percentile), signaling high near-term risk.

Do: Upgrade GeoServer to 2.27.1, 2.26.3, or 2.25.7; GeoNetwork to 4.4.8 or 4.2.13; and GeoTools to 33.1, 32.3, 31.7, or 28.6.1 as applicable. Until patched, restrict or disable XML endpoints that accept documents referencing external XML schemas (e.g., WFS/XML inputs) and apply WAF or egress controls to block external entity resolution to internal or remote hosts. Audit any gt-wfs-ng DataStore connections to verify the ENTITY_RESOLVER connection parameter is set as intended.

OSGeo GeoServer ships the GeoTools library, which evaluates feature property names directly as XPath expressions without proper neutralization (CWE-95), so attacker-supplied input is executed as code rather than treated as data. A remote, unauthenticated attacker triggers the flaw by sending specially crafted requests to a GeoServer service, causing the injected expression to be evaluated in the server's context. Successful exploitation results in remote code execution on the host running GeoServer, giving the attacker control over the mapping server and any data or credentials it can reach. Any organization running GeoServer is affected, and the underlying GeoTools flaw also extends to dependent applications such as GeoNetwork, which shipped its own fix for an unauthenticated RCE chain affecting government geoportal backends. The flaw is being actively exploited: it was added to CISA KEV on 2024-07-15, and EPSS assigns a 99.8% probability of exploitation within 30 days.

Do: Upgrade GeoServer to the fixed releases identified in the OSGeo advisory (2.23.6, 2.24.4 or 2.25.2, or later); where upgrading is not immediately possible, restrict access to GeoServer's public endpoints per vendor mitigations or discontinue use of the product per the KEV required action. Organizations running GeoNetwork or other GeoTools-based applications should apply those vendors' fixes as well. Given active exploitation, hunt for signs of compromise such as unexpected child processes spawned by the GeoServer Java process, new files or services on the host, and unusual map/feature service request patterns.

GeoTools is an open source Java library that provides tools for geospatial data. GeoTools includes support for OGC Filter expression language parsing, encoding and execution against a range of datastore. SQL Injection Vulnerabilities have been found when executing OGC Filters with JDBCDataStore implementations. Users are advised to upgrade to either version 27.4 or to 28.2 to resolve this issue. Users unable to upgrade may disable `encode functions` for PostGIS DataStores or enable `prepared statements` for JDBCDataStores as a partial mitigation.

GeoTools is an open source Java library that provides tools for geospatial data. The GeoTools library has a number of data sources that can perform unchecked JNDI lookups, which in turn can be used to perform class deserialization and result in arbitrary code execution. Similar to the Log4J case, the vulnerability can be triggered if the JNDI names are user-provided, but requires admin-level login to be triggered. The lookups are now restricted in GeoTools 26.4, GeoTools 25.6, and GeoTools 24.6. Users unable to upgrade should ensure that any downstream application should not allow usage of remotely provided JNDI strings.