GeoServer Blog
CVE-2024-36401 Remote Code Execution (RCE) vulnerability in evaluating property name expressions
The GeoServer community has been under considerable strain responding to CVE-2024-36401. This vulnerability stems from GeoTools library CVE-2024-36404.
This vulnerability, in the handling of XPath expressions, affords a “remote code execution” attack that is under active exploit. A remote code execution (RCE) attack allows an attacker to run malicious code on your computer or network.
For more information:
- GeoServer 2.25.2 Release (Jun 18, 2024)
- GeoServer 2.24.4 Release (Jun 18, 2024)
- CVE-2024-36401 (July 1, 2024)
- CISA Warns of Actively Exploited RCE Flaw in GeoServer GeoTools Software (The Hacker News, July 18, 2024)
- GeoServer Vulnerability Targeted by Hackers to Deliver Backdoors and Botnet Malware (The Hacker News, September 6, 2024)
Q: Why have I been directed to this post?
You are responsible for running a GeoServer instance that has not been updated.
-
CVE-2024-36401 provides mitigation instructions which you should perform immediately.
Please stop reading and do this now.
-
Update your instance: Upgrading existing versions (User Guide)
The instructions include notes on upgrading specific versions. Please read carefully to see if any manual changes are required.
Q: Do I have to update or is a patch available?
With such a serious issue several service providers have stepped forward to make fixes available for prior releases.
Full release:
- GeoServer 2.23.6 Release (GeoCat)
Patch provided with CVE-2024-36401 report:
- GeoServer 2.25.1 (GeoSolutions)
- GeoServer 2.24.3 (GeoSolutions)
- GeoServer 2.24.2 (GeoSolutions)
- GeoServer 2.23.2 (GeoSolutions)
- GeoServer 2.22.2 (GeoSolutions)
- GeoServer 2.21.5 (GeoSolutions)
- GeoServer 2.21.4 (GeoSolutions)
- GeoServer 2.20.7 (GeoSolutions)
- GeoServer 2.20.4 (GeoSolutions)
- GeoServer 2.19.2 (GeoSolutions)
- GeoServer 2.18.0 (GeoSolutions)
Free software is a participation sport - to create a patch for a prior release volunteer with community development.
Q: How often should I upgrade GeoServer?
GeoServer operates with a time boxed release cycle, maintaining “stable” and “maintenance” releases, over the course of a year.
-
Upgrade GeoServer twice a year as new stable releases are made.
-
Once the release you are using has entered “maintenance” it is a good idea to upgrade (before the release is no longer supported).
-
GeoServer security policy provides one year of support. You may also contact our service providers for extended support beyond this timeframe.
Q: Notification of security vulnerabilities?
Stay up to date:
-
Please monitor release announcements for the heading “Security Considerations”.
Security Considerations
This release addresses security vulnerabilities and is considered an essential upgrade for production systems.
- CVE-2024-36401 Critical
You can review the release announcement, and in this case with a “Critical” vulnerability decide to update.
-
When everyone has had an opportunity to update the details of the vulnerability are announced.
Security Considerations
This release addresses security vulnerabilities and is considered an essential upgrade for production systems.
- CVE-2024-36401 Remote Code Execution (RCE) vulnerability in evaluating property name expression (Critical)
-
As GeoServer has now adopted use CVEs for publication you may also have success with vulnerability scanning tools.
These tools function when the vulnerability is published, and do not provide any advance notice.
Q: Notification of security reports?
As security reports contain sensitive information they are only shared with representatives of the geoserver-security email list.
Participation in geoserver-security, like commit access, is volunteer based and reflects trust.
Please review GeoServer Security Policy if you are in a position to help out.
GeoServer 3 Call for Crowdfunding
GeoServer is at a critical turning point and it needs your help to continue its journey as the leading free and open-source platform for geospatial data. With GeoServer 3 we are transforming the way you interact with geospatial data—making it faster, more intuitive, and more secure.
This major upgrade, led by Camptocamp, GeoSolutions, and GeoCat, will deliver:
-
Future-Proof Performance: A modernized core for compatibility with the latest data management and deployment technologies.
-
Enhanced Image Processing: Faster, smoother handling of spatial imagery and larger datasets.
-
Improved Security and Compliance: Meet regulatory standards and protect your data with the latest security enhancements.
-
Streamlined User Experience: Easier navigation, integrating new services, and empowering users at all levels.
The scope of this work is beyond routine updates or maintenance since the transition to GeoServer 3 requires extensive redevelopment of core systems as well as implementing modern security practices and also thorough testing and validation across all GeoServer extensions.
The consortium members - Camptocamp, GeoSolutions, and GeoCat- have a long-standing history of supporting and contributing to GeoServer and are fully committed to the success of this migration. However, this is a major effort that cannot be completed without community support.
By supporting this crowdfunding campaign, you are investing in the future of GeoServer and helping to sustain the innovative, open-source geospatial community.
Why GeoServer 3
As the digital landscape evolves, staying up-to-date with the latest technology is no longer optional — it’s essential. GeoServer 3 is being developed to address crucial challenges and ensure that GeoServer remains a reliable and secure platform for the future. Several key factors make this upgrade critical right now:
-
Regulatory Compliance: New regulations, including the CISA known exploited vulnerabilities list, demand that systems be fully patched to ensure operational readiness. Without the latest updates, GeoServer risks falling short of these standards, which is why migrating to Spring 6 is essential.
-
End of Support for Spring 5: By January 2025, Spring 5 will no longer receive security updates, leaving systems vulnerable. As GeoServer operates as middleware between web services and essential data layers, this upgrade to Spring 6 is crucial to maintaining secure connections and protecting data from potential breaches.
-
Security Enhancements: Upgrading to Spring 6 enables OAuth2 protocols for secure authentication, especially critical for large-scale or enterprise-level use. These advancements will help organizations meet evolving security requirements and protect sensitive geospatial data.
-
Switching to JDK 17: This upgrade also marks GeoServer’s transition to JDK 17, which brings improvements in performance, security, and long-term support. Keeping GeoServer aligned with the latest Java versions ensures compatibility with modern deployment technologies Tomcat 10 and Jakarta and future-proofs the platform.
-
Improved Image Processing: GeoServer 3 will replace the outdated Java Advanced Imaging (JAI) library with the more modern and flexible ImageN toolkit. This switch will significantly enhance image processing capabilities, enabling faster handling of large spatial datasets and improving Java compatibility.
-
Future-Proof Technology Stack: With the migration to Spring 6 and the shift to JDK 17, GeoServer 3 ensures long-term viability. Addressing the entire GeoServer stack, including enterprise components GeoFence and Cloud Native GeoServer, allows organizations to seamlessly adopt modern infrastructure and deployment models without compromising performance or security.
With this work, GeoServer is moving into a more secure, high-performing future—ready to tackle the evolving needs of the geospatial community.
About the Crowdfunding campaign
While our consortium is fully committed to this effort, the size of the task means that we need additional financial support to make it happen. This is where you come in. By contributing to this crowdfunding campaign, you are directly supporting the developers and engineers who will carry out the upgrade, ensuring the continued success of GeoServer.
Your support, whether as an individual, a public institution, or a service provider, is vital. By contributing to this crowdfunding campaign, you’re investing in the future of open-source geospatial technology. The crowdfunding will be structured in two phases to ensure success:
-
Commitment Phase: Sponsors and community members will pledge their financial support during this phase, but no funds will be collected. The goal is to reach a predefined target that covers the full scope of work necessary for the migration.
-
Funding Activation: Once the target is reached, the crowdfunding will be activated, and sponsors will be invoiced for their pledged amounts. This ensures there is enough financial backing to complete the migration without risking underfunding.
This structured approach ensures that GeoServer 3 is fully funded before any work begins, preventing the risk of an incomplete migration. This guarantees that the project will have the necessary resources to be completed in its entirety.
How to participate
GeoServer is trusted by thousands of organizations worldwide. Now is the time to step forward and join this community of supporters.
By donating, you’ll help secure GeoServer’s future as a high-performance, open-source platform. Every contribution counts.
Ready to support GeoServer 3? Contact us at gs3-funding@googlegroups.com to express your interest or pledge your support.
Together, we can secure the future of GeoServer for years to come.
Using Value Comparison Operators in GeoServer Filters
GeoSpatial Techno is a startup focused on geospatial information that is providing e-learning courses to enhance the knowledge of geospatial information users, students, and other startups. The main approach of this startup is providing quality, valid specialized training in the field of geospatial information.
( YouTube | LinkedIn | Facebook | X )
Value Comparison Operators in GeoServer Filters
In this session, we want to talk about the various types of filters, with a particular focus on “Value comparison operators in GeoServer” comprehensively. If you want to access the complete tutorial, click on the link.
Introduction
Filtering allows the selection of features that satisfy a specific set of conditions. Filters can be used in several contexts in GeoServer:
- In WMS requests, select which features should be displayed on a map
- In WFS requests, specify the features to be returned
- In SLD documents, apply different symbolizations to features on a thematic map
Note. This video was recorded on GeoServer 2.22.4, which is not the most up-to-date version. Currently, versions 2.24.x and 2.25.x are supported. To ensure you have the latest release, please visit this link and avoid using older versions of GeoServer.
Comparison operators
In GeoServer, the Web Feature Service (WFS) filtering utilizes a set of comparison operators to facilitate the querying of geospatial features. These operators allow users to create precise filters based on attribute values, enabling robust spatial queries. The main comparison operators available include: Binary comparison operators and Value comparison operators.
The value comparison operators are:
- PropertyIsLike
- PropertyIsNull
- PropertyIsBetween
PropertyIsLike
The PropertyIsLike operator is used to compare a string property value with a text pattern. It includes the
These characters are defined by the attributes of the
- WildCard: It specifies the pattern character that matches any sequence of zero or more string characters
- SingleChar: It specifies the pattern character that matches any single string character
- EscapeChar: It specifies the escape character which can be used to escape the pattern character
Geoserver supports the PropertyIsLike operator within filter expressions for querying spatial data. Here are some examples of how you can use this filter in an XML request to filter the States
layer by the State_Name
attribute:
- Navigate to the Demos page, then select Demo requests.
- From the Request section, select the WFS_getFeature1.0.xml request.
- The address will be filled in automatically, in the URL section.
Use the following block codes to replace line 26:
<PropertyIsLike wildCard="*" singleChar="_" escapeChar="\">
<PropertyName>STATE_NAME</PropertyName>
<Literal>North*</Literal>
</PropertyIsLike>
- Now, we will explain some elements:
- The first fifteen lines include explanations in the form of comments.
- Line 16 describes the XML version and the GetFeature operation of the WFS service being used.
- Line 17 specifies the default output format for the WFS service as “gml2.” Additionally, GeoServer supports several other commonly used formats such as “gml3, shapefile, geojson, and csv.”
- Lines 18 to 23 define the start of the XML request and declare the namespaces used in the request.
- Line 24 specifies the type name of the feature to be queried. In this case, it requests features of the “topp:states”.
- Lines 25 to 30 define the filter criteria for the query. On these lines, we use the PropertyIsLike filter, to retrieve all states that start with the word
North
.
-
Press the Submit button to see the implemented changes.
- Note. For GeoServer 2.25.2 the Demo Request page has been improved to show response Headers, and provide the option to pretty print XML output.
Now, we are looking for the States with four-letter names, where the letter o
appears at both the beginning and the end. This requires using a singleChar as a different mode of the “LIKE” operator that you see on the screen:
<ogc:Filter>
<PropertyIsLike wildCard="*" singleChar="_" escapeChar="\">
<PropertyName>STATE_NAME</PropertyName>
<Literal>O__o</Literal>
</PropertyIsLike>
</ogc:Filter>
Press the Submit button to see the implemented changes. As you can see, a state called Ohio
was found that meets the conditions in this example.
To show the escapeChar mode, modify the names ‘Montana’ and ‘Minnesota’ to Monta*na
and Minnesota*
in QGIS. This will allow you to filter out special characters, such as asterisks or underscores, that you have used. Now, use the codes displayed on the screen:
<ogc:Filter>
<PropertyIsLike wildCard="*" singleChar="_" escapeChar="\">
<PropertyName>STATE_NAME</PropertyName>
<Literal>*ta\**</Literal>
</PropertyIsLike>
</ogc:Filter>
Press the Submit button to see the implemented changes. Note that, If the escapeChar is not used, the correct result may not be visible in the output; because the underscore is a special character.
You have the flexibility to modify the wildCard, singleChar, and escapeChar attributes based on your requirements. This allows for a more proper filtering experience. So, feel free to customize them and make the most of your filtering capabilities!
PropertyIsNull
This operator, allows you to query for features where a specific property or attribute, has a null value. In other words, it is used to filter the features based on the absence of a value in a particular property.
In this example, the query is looking for features in the topp:states
layer, where the STATE_NAME attribute is null.
As an example of using this filter in a WFS getFeature request, use the following block codes to replace lines 26 to 29:
<PropertyIsNull>
<PropertyName>STATE_NAME</PropertyName>
</PropertyIsNull>
Press the Submit button. As you can see, there is no value returned in the output as a null value.
PropertyIsBetween
The PropertyIsBetween operator is a helpful tool that allows you to determine whether a particular property of a feature, is within a defined range of values. As an example of using this operator, select the WFS_getFeatureBetween1.1.xml request from the Request section.
Now the filters block code is as follows:
<ogc:Filter>
<ogc:PropertyIsBetween>
<ogc:PropertyName>topp:LAND_KM</ogc:PropertyName>
<ogc:LowerBoundary><ogc:Literal>100000</ogc:Literal></ogc:LowerBoundary>
<ogc:UpperBoundary><ogc:Literal>150000</ogc:Literal></ogc:UpperBoundary>
</ogc:PropertyIsBetween>
</ogc:Filter>
Press the Submit button.
Remember that PropertyIsBetween like other operators, is case-sensitive and the property name is specified as the first parameter to the operator. The minimum and maximum values of the range are specified as the second and third parameters, respectively.
In this session, we took a brief journey through the various types of filters, with a particular focus on “Value comparison operators in GeoServer”. If you want to access the complete tutorial, click on the link.
GeoServer 2.24.5 Release
GeoServer 2.24.5 release is now available with downloads (bin, war, windows), along with docs and extensions.
This is a maintenance release of GeoServer providing existing installations with minor updates and bug fixes. GeoServer 2.24.5 is made in conjunction with GeoTools 30.5, and GeoWebCache 1.24.5.
Thanks to Andrea Aime for making this release.
Release notes
Improvement:
- GEOS-11336 security-keycloak: upgrade keycloak version
- GEOS-11443 REST API does not take effect immediately due to 10 minute authentication cache
- GEOS-11463 WMS vector dimension validation should query only one feature and only for dimension attribute
- GEOS-11502 Permit resize on user/group/role palette textbox to allow for extra long role names
Bug:
- GEOS-11446 [INSPIRE] Incorrect behavior for unsupported languages
- GEOS-11453 Failure to look-up default value of custom dimensions on vector layers
- GEOS-11462 500 error thrown when double adding a user to a group via REST with JDBC user/group services
- GEOS-11484 DirectRasterRenderer is not respecting advancedProjectionHandling and continuosMapWrapping format_options
- GEOS-11493 Azure blob store may not get environment parameters from property file
Task:
- GEOS-11464 Update Jackson 2 libs from 2.17.1 to 2.17.2
For the complete list see 2.24.5 release notes.
Community Updates
Community module development:
- GEOS-11111 Open search for EO community module: STAC search page has wrong self link
Community modules are shared as source code to encourage collaboration. If a topic being explored is of interest to you, please contact the module developer to offer assistance.
About GeoServer 2.24 Series
Additional information on GeoServer 2.24 series:
- GeoServer 2.24 User Manual
- Control remote HTTP requests sent by GeoTools/GeoServer
- State of GeoServer 2.24.1 (foss4g-asia presentation)
- Multiple CRS authority support, planetary CRS
- Extensive GeoServer Printing improvements
- Upgraded security policy
Release notes: ( 2.24.5 | 2.24.4 | 2.24.3 | 2.24.2 | 2.24.1 | 2.24.0 | 2.24-RC )
Using Binary Comparison Operators in GeoServer Filters
GeoSpatial Techno is a startup focused on geospatial information that is providing e-learning courses to enhance the knowledge of geospatial information users, students, and other startups. The main approach of this startup is providing quality, valid specialized training in the field of geospatial information.
( YouTube | LinkedIn | Facebook | X )
Binary Comparison Operators in GeoServer Filters
In this session, we want to talk about the various types of filters, with a particular focus on “Binary comparison operators in GeoServer” comprehensively. If you want to access the complete tutorial, click on the link.
Introduction
Filtering allows the selection of features that satisfy a specific set of conditions. Filters can be used in several contexts in GeoServer:
- In WMS requests, select which features should be displayed on a map
- In WFS requests, specify the features to be returned
- In SLD documents, apply different symbolizations to features on a thematic map
Note. This video was recorded on GeoServer 2.22.4, which is not the most up-to-date version. Currently, versions 2.24.x and 2.25.x are supported. To ensure you have the latest release, please visit this link and avoid using older versions of GeoServer.
Supported filter languages
Data filtering in GeoServer follows the OGC Filter Encoding Specification, which provides a standard XML schema for encoding spatial, attribute, and temporal filters in GIS. This allows for customized queries to retrieve specific data from databases and web services while ensuring interoperability among GIS applications. GeoServer supports filters in both Filter Encoding Language and Common Query Language.
Filter Encoding Language
The Filter Encoding language, defined by OGC standards, utilizes an XML-based syntax to select specific features, similar to the “WHERE” clause in SQL. A filter consists of a condition formed by Predicate elements and Logical operators, employing comparison and spatial operators to evaluate relationships between feature properties. In this session, we will explore various types of binary comparison operators, while the next sessions will cover spatial operators.
Common Query Language
Common Query Language (CQL) is a Text-based language used in GeoServer for constructing filters and queries on geospatial data. It provides flexible and powerful options for filtering and retrieving specific subsets of data from GeoServer layers. In the upcoming sessions, we will dive into a detailed exploration of CQL/ECQL, covering its various operations and practical usage.
Comparison operators
These operators are part of Filter Encoding operators and are used in attribute-based queries to filter and retrieve specific features or data, based on their non-spatial attributes. The comparison operators include: binary comparison operators and value comparison operators.
The binary comparison operators are:
- PropertyIsEqualTo
- PropertyIsNotEqualTo
- PropertyIsLessThan
- PropertyIsLessThanOrEqualTo
- PropertyIsGreaterThan
- PropertyIsGreaterThanOrEqualTo
These operators contain two filter expressions to be compared. The first operand is often a <PropertyName>
, but both operands may be any expression, function or literal value. Binary comparison operator elements may include an optional matchCase attribute, with the true or false value. The default value is true, but the comparisons do not check the case if the attribute has a false value.
Note. String comparison operators are case-sensitive.
PropertyIsEqualTo
PropertyIsNotEqualTo is a common type of filter used in GeoServer, which allows you to retrieve features from a data source based on the values of one or more properties. As an example of using this filter in WFS getFeature request:
- Navigate to the Demos page, then select Demo requests.
- From the Request section, select the WFS_getFeature1.0.xml request.
- The address will be filled in automatically, in the URL section.
Use the following block codes to replace line 26:
<PropertyIsEqualTo>
<PropertyName>STATE_NAME</PropertyName>
<Literal>Delaware</Literal>
</PropertyIsEqualTo>
- Now, we will explain some elements:
- The first fifteen lines include explanations in the form of comments.
- Line 16 describes the XML version and the GetFeature operation of the WFS service being used.
- Line 17 specifies the default output format for the WFS service as “gml2.” Additionally, GeoServer supports several other commonly used formats such as “gml3, shapefile, geojson, and csv.”
- Lines 18 to 23 define the start of the XML request and declare the namespaces used in the request.
- Line 24 specifies the type name of the feature to be queried. In this case, it requests features of the “topp:states”.
- Lines 25 to 30 define the filter criteria for the query. On these lines, we use the PropertyIsEqualTo filter, to retrieve all features where the state name attribute is equal to
Delaware
.
-
Press the Submit button to see the implemented changes.
- Note. For GeoServer 2.25.2 the Demo Request page has been improved to show response Headers, and provide the option to pretty print XML output.
PropertyIsNotEqualTo
PropertyIsNotEqualTo is another common type of filter used in GeoServer, which allows you to retrieve features from a data source based on properties that don’t match a specified value. As an example of using this filter in a WFS getFeature request, use the following block codes to replace lines 26 to 29:
<PropertyIsNotEqualTo matchCase="false">
<PropertyName>STATE_NAME</PropertyName>
<Literal>delAwarE</Literal>
</PropertyIsNotEqualTo>
Note. The matchCase attribute in WFS_getFeature 1.1 and 2.0 versions, can be set to “false” to specify a case-insensitive comparison.
Press the Submit button.
In this example, we used the <PropertyIsNotEqualTo>
filter to retrieve all features where the STATE_NAME
attribute, is not equal to Delaware
.
PropertyIsLessThan
The PropertyIsLessThan filter is used to filter features, based on a comparison of a numeric property with a given value. It returns all features where the specified property is less than the specified value.
An example of using this filter in a WFS getFeature request is:
outputFormat="shape-zip"
<wfs:Query typeName="topp:states">
<wfs:PropertyName>topp:STATE_NAME</wfs:PropertyName>
<wfs:PropertyName>topp:LAND_KM</wfs:PropertyName>
<ogc:Filter>
<PropertyIsLessThan>
<PropertyName>STATE_FIPS</PropertyName>
<Literal>18</Literal>
</PropertyIsLessThan>
</ogc:Filter>
Press the Submit button.
In this example, we used the <PropertyIsLessThan>
filter to get all features in a shapefile format where the value of the STATE_FIPS
attribute is less than 18
. The query only retrieves the STATE_NAME
and LAND_KM
fields, instead of all the attributes.
In this session, we took a brief journey through the various types of filters, with a particular focus on “Binary comparison operators in GeoServer”. If you want to access the complete tutorial, simply click on the link.
Vulnerability
- CVE-2024-36401 Remote Code Execution (RCE) vulnerability in evaluating property name expressions
- GeoServer 2.25.2 Release
- GeoServer 2.24.4 Release
- GeoServer 2.23.6 Release
- GeoServer 2.25.1 Release
- GeoServer 2.25.0 Release
- GeoServer 2.23.5 Release
- GeoServer 2.24.2 Release
- GeoServer 2.23.4 Release
- GeoServer 2.24.1 Release