The GeoServer team are happy to announce GeoServer 2.19.5 release is available for download (zip and war) along with docs and extensions.

This GeoServer 2.19.5 release was produced in conjunction with GeoTools 25.5 and GeoWebCache 1.19.2, this is a maintenance release recommended for production systems.

Thanks to everyone who contributed, and to Ian Turton (Astun Technology) for making this release.

Security Considerations

This release includes several security enhancements and is a recommended update for production systems.

This release includes two improvements limiting Server-side request forgery (SSRF) opportunities:

• GEOS-10389 Introduce ENTITY_RESOLUTION_ALLOWLIST parameter to further restrict external entity resolution.

  See the user guide on external entities resolution for instructions on use. Keep in mind that the application schema plugin requires external entity resolution to local files be available. The global setting required by application schema has been renamed to Unrestricted XML External Entity Resolution.

• GEOS-10384 Change GetMap to URIKvpParser.

  This improvement is used in conjunction with WMS dynamic styling setting disabling of SLD and SLD_BODY parameters. By handling SLD and SLD_BODY as URI values we can avoid a well-known java side-effect when comparing URL values.

We would like to thank GeoCat for addressing these two issues on behalf of Fisheries and Oceans Canada. If you wish to report a security vulnerability, please visit our website for instructions on responsible reporting.

Improvements and Fixes

Fixes:

• GEOS-9785 Invalid argument type=null when trying to use gs:Download WPS identifier
• GEOS-9770 Cascading WMS server sets invalid I and J when using EPSG:3006 on GetFeatureInfo calls

About GeoServer 2.19

Additional information on GeoServer 2.19 series:

• Log4J2 zero day vulnerability assessment
• WMS GetFeatureInfo includes labels from ColorMap
• Promote WMTS multidim to extension
• Promote WPS-Download to extension
• Promote params-extractor to extension
• Promote GWC-S3 to extension
• Promote WPS-JDBC to extension status
• Promote MapML to extension status
• GeoServer repository transition to main branch

Release notes ( 2.19.5 | 2.19.4 | 2.19.3 | 2.19.2| 2.19.1 | 2.19.0 | 2.19-RC )

We are happy to announce GeoServer 2.20.2 release is available with downloads (bin, war, windows), along with docs and extensions.

This is a stable release of the 2.20.x series recommended for production systems. This release was made in conjunction with GeoTools 26.2 and GeoWebCache 1.20.1.

Security Considerations

This release includes several security enhancements and is a recommended upgrade for production systems:

• GeoServer uses the earlier log4j1 library and is not subject to the Log4j2 remote code execution vulnerabilities reported worldwide. For a detailed discussion please read GeoServer Log4J2 zero day vulnerability assessment.

  The release of GeoServer includes a patched version of log4j1 which does not include any remote loggers or socket communication.

If you wish to report a security vulnerability, please visit our website for instructions on responsible reporting.

Mark Factory Precedence

When rendering maps with lots of individual graphics, looking up the correct implementation (known as a MarkFactory) can be time consuming.

WMS Settings have new capability to filter out any mark factories not being used, and provide an order to prioritise the ones being used.

For more information see WMS Web Administration (user guide).

Source Code

For developers building from source, we have committed a .gitattributes file to help preserve consistent line encoding across our repository.

With this change it is no longer necessary to set your global configuration to core.autocrlf=input.

Use git reset as outlined below if encounter difficulty updating your checkout:

git pull --rebase
git reset --hard

Improvements and Fixes

• WMS rendering preserves region of interest when clipping working with palette based images
• Importer improvements to better report failed imports and clean up stale importer contents
• WCS return coverages whose native BBOX are slightly outside of the dateline
• Reduce the CPU load of returning Server Status information using OSHI on windows

For more information see 2.20.2 release notes.

About GeoServer 2.20

Additional information on GeoServer 2.20 series:

• Log4J2 zero day vulnerability assessment
• Internationalization of title and abstract
• State of GeoServer 2.20 edition
• Windows Installer

Release notes: ( 2.20.2 | 2.20.1 | 2.20.0 | 2.20-RC )

While GeoServer is not vulnerable to Log4J2 Log4Shell vulnerability, we would like to thank everyone who has reached out with offers of concern and assistance.

The Log4J 1.2 library used by GeoServer has a number of smaller vulnerabilities which we would like to address. While the GeoServer default configuration is not vulnerable it is time to upgrade or replace this library. If you are at all concerned, locate WEB-INF/lib/log4j-1.2.17.jar and replace with our custom log4j-1.2.17.norce.jar, and restart GeoServer.

The GeoSever Project Steering Committee invites:

• Proposals for updating or replacing the Log4J1 library used by GeoServer.

  Successful proposals should consider changes required to GeoTools logging (which bridges from java utility logging to selected logging library), integration with GeoWebCache (uses apache-commons-logging to delegate to selected logging library), and GeoServer (which allows users to select different logging profiles without restarting the application).

• Sponsors interested in funding this activity as a security concern.

  Organizations running GeoServer in a cloud environment are also encouraged to fund this activity. The leading contenders (log4j2,logback,java util logging) provide better integration with cloud logging services than the log4j1 library presently used.

This is a time sensitive activity as we would like to select a good proposal and see the result implemented for the upcoming GeoServer 2.21-RC Release Candidate in March.

Thanks to activity sponsors for your support:

• opengeogroep.nl
• www.terrestris.de
• how2map.com
• www.geonovation.nl
• Add your name here via OSGeo GitHub Sponsorship (monthly donation), PayPal (one time donation), or OSGeo sponsorship (direct invoice).

For more information visit updating or replacing the Log4J1 wiki page.

The GeoServer team are happy to announce GeoServer 2.19.4 release is available for download (zip and war) along with docs and extensions.

This GeoServer 2.19.4 release was produced in conjunction with GeoTools 25.4 and GeoWebCache 1.19.2, this is a maintenance release recommended for production systems.

Thanks to everyone who contributed, and to Andrea Aime (GeoSolutions) for making this release.

Security Considerations

This release includes several security enhancements and is a recommended upgrade for production systems:

• GeoServer uses the earlier log4j1 library and is not subject to the Log4j2 remote code execution vulnerabilities reported worldwide. For a detailed discussion please read GeoServer Log4J2 zero day vulnerability assessment.

  The release of GeoServer includes a patched version of log4j1 which does not include any remote loggers or socket communication.

If you wish to report a security vulnerability, please visit our website for instructions on responsible reporting.

Improvements and Fixes

Bug

• GEOS-10337 Harden importer against failed imports, make failures more evident

• GEOS-10322 JDBCConfig community module does not deal with stale connections to the database

• GEOS-10300 The map preview logs errors when using AUTO codes

• GEOS-10299 The reprojection console does not work with AUTO codes

• GEOS-10292 Changing worker pool size in raster access is not actually applied (silent error)

• GEOS-10289 GeoServer busy for 1 hour on reloading a 50000 shapefiles Directory datastore

• GEOS-10281 GeoServer log level not picked up with Catalog reload

• GEOS-10249 GWC produce NPE when it comes to race condition

Improvement

• GEOS-10328 Expire completed and stale importer contexts

• GEOS-10321 WCS 2.0 might fail to return coverages whose native BBOX goes slighly outside of the dateline

• GEOS-10315 Features Templating - Allow injecting JSON-LD output in HTML

• GEOS-10314 Features Templating - allow specifying root @type in the JSON-LD output and a different name for features array

GEOS-9904 GeoFence backend DBMS dependencies

Task

• GEOS-10335 Update GeoServer to a log4j version that does not support RCEs

• GEOS-10269 Overriding JSON Object while Merging Feature Templates

• GEOS-10268 Null Support in Features Templating

About GeoServer 2.19

Additional information on GeoServer 2.19 series:

• Log4J2 zero day vulnerability assessment
• WMS GetFeatureInfo includes labels from ColorMap
• Promote WMTS multidim to extension
• Promote WPS-Download to extension
• Promote params-extractor to extension
• Promote GWC-S3 to extension
• Promote WPS-JDBC to extension status
• Promote MapML to extension status
• GeoServer repository transition to main branch

Release notes ( 2.19.3 | 2.19.2| 2.19.1 | 2.19.0 | 2.19-RC )

The Java world has been taken by storm, last week, by the Log4J2 Log4Shell vulnerability, code CVE-2021-44228, which allows remote code execution by simply making API calls to the vulnerable servers. The understanding of the vulnerability is still evolving and the reports are being updated, we are monitoring them closely and adapting as needed. The following information is based on our current understanding of the vulnerability and will be updated as new information is released.

Let us state this clearly: GeoServer, following our own investigation, as well as our understanding of the reported vulnerability, is not vulnerable to CVE-2021-44228 since it does not use Log4J2!

In more detail, GeoServer uses Log4J 1.2.17 and it is crucial to understand that Log4J and Log4J2 are not the same library: the 2 is in the name, it is not just a version number, Log4J2 is a full rewrite of Log4J. As a consequence GeoServer is not vulnerable in the same way reported in CVE-2021-44228: our current understanding is that it cannot be made to perform a remote code execution by simply crafting an appropriate HTTP request.

However, Log4J 1.2 has smaller vulnerabilities, which may trigger when loading the configuration files. It happens if the attacker manages to:

• Get write access to the GeoServer log configuration files.
• Set up in them a new JMSAppender configuration, in which the TopicConnectionFactoryBindingName or TopicBindingName point to a remote server providing malicious classes.
• Force GeoServer to reload the logging configuration.

Log4J 1.2.17 is also vulnerable to CVE-2019-17571. This is even narrower than the issue above, as the SocketServer class needs to be run from the command line explicitly.

That said, It is important to note that GeoServer default configuration is not vulnerable to these and the attacker would need to go and modify the logging configuration files in order to trigger it.

Checking for vulnerabilities

How to check if your server is vulnerable:

• Check the log configuration files, make sure there is no JMSAppender.
• Make sure that no one outside of your organization can get write access to the logging configuration files, e.g.:
  • No one outside your organization has admin access to GeoServer. The REST API allows writing in the data directory using the resource endpoint, and if the web resource extension is installed, admins will also be allowed to edit the files via the GUI.
  • No one outside your organization has console access to the server (e.g, SSH, terminal services), and if they do, they don’t have write permission to the GeoServer configuration files.

Threat elimination

The GeoServer project has released a sanitized version of the Log4J 1.2.17 library, which simply does not include the classes involved in vulnerabilities CVE-2021-44228 and CVE-2019-17571. This library is also usable with older versions of GeoServer.

The file is available in our Nexus repository. Simply remove the existing log4j-1.2.17.jar and drop in the new log4j-1.2.17.norce.jar in the geoserver/webapps/WEB-INF/lib folder, and then restart tomcat.

We are also aware that Log4J 1.2.17 is an “End Of Life” (EOL) project, and are actively looking for funding to perform an upgrade to more recent versions of them. All new logging libraries have a different API and a different configuration file layout, with potential backwards compatibility issues, so this will be likely done on newer versions of GeoServer (2.21.x).