Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
16 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
A server-side template injection (SSTI) vulnerability exist that allows an authenticated administrator to upload FreeMarker templates containing malicious content that can execute OS commands and read from or write to arbitrary files on the server. These FreeMarker templates are used in a plain GeoServer instance (no extension or community modules) for WMS GetFeatureInfo HTML and JSON and WMS GetMap KML and GeoRSS output formats. Details The org.geoserver.template.TemplateUtils.getSafeConfiguration() method attempts to block access to the class freemarker.template.utility.Execute but it is still possible to gain access to it and other sensitive functionality by chaining a specific sequence of method calls. Impact This vulnerability can lead to executing arbitrary code and reading and writing arbitrary files. Resolution GeoServer 2.27.0 addresses this vulnerability with several new application properties: GEOSERVERFREEMARKERBLOCKLIST GEOSERVERFREEMARKERALLOWLIST…
Recommended action: Upgrade to 2.27.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A GeoServer that uses ENTITYRESOLUTIONALLOWLIST may allow attacker to perform unauthenticated Server-Side Request Forgery (SSRF). Details This vulnerability requires that GeoServer is set up to use a proxy base URL and the ENTITYRESOLUTIONALLOWLIST (default since 2.25.0): Impact This vulnerability allows an attacker to cause GeoServer to make requests to an unintended location. Workaround GeoServer installations are only affected by this vulnerability if they use a proxy base URL that does not contain a URL path or end with a slash (e.g., https://somesite.org instead of https://somesite.org/ or https://somesite.org/geoserver). If the proxy base URL does not contain a path, adding a slash to the end of the URL will mitigate this vulnerability. Resources https://osgeo-org.atlassian.net/browse/GEOS-11867 https://github.com/geoserver/geoserver/pull/8622 Credits: - Le Mau Anh Phong at Verichains Cyber Force
Recommended action: Upgrade to 2.27.3 or 2.26.4 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A vulnerability exists that allows an authenticated administrator with access to GeoServer's security system to pass arbitrary file names to the Master Password Dump web page and create files containing the master password in plaintext. The provided file name must be an absolute path to the target file, the target file can not already exist and all parent directories must already exist. Details When dumping the master password, GeoServer will use the provided file name with minimal validation as long as it is a java.io.File path. The only limitation is that the fix for a previous, unrelated vulnerability prevents relative path traversal here but absolute paths can be used to access arbitrary files. GeoServer does not enforce a maximum password length by default which allows an administrator to place malicious code into their password which could then be dumped into a JSP file. Impact Remote Code Execution (High severity) This vulnerability can lead to executing arbitrary code…
Recommended action: Upgrade to 2.27.3 or 2.26.4 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An XML External Entity (XXE) vulnerability was identified. The application accepts XML input through a specific endpoint /geoserver/wms operation GetMap. However, this input is not sufficiently sanitized or restricted, allowing an attacker to define external entities within the XML request. An XML External Entity attack is a type of attack that occurs when XML input containing a reference to an external entity is processed by a weakly configured XML parser. This attack may lead to the disclosure of confidential data, denial of service, port scanning from the perspective of the machine where the parser is located, and other system impacts. By exploiting this vulnerability, an attacker can: - Read arbitrary files from the server's file system. - Conduct Server-Side Request Forgery (SSRF) to interact with internal systems. - Execute Denial of Service (DoS) attacks by exhausting resources. Resolution Update to GeoServer 2.25.6, GeoServer 2.26.3, or GeoServer 2.27.0. Impact…
Recommended action: Upgrade to 2.26.2 or 2.25.6 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A reflected cross-site scripting (XSS) vulnerability exists in the WMS GetFeatureInfo HTML output format that enables a remote attacker to execute arbitrary JavaScript code in a victim's browser through specially crafted SLDBODY parameters. Details The WMS service setting that controls HTML auto-escaping is either disabled by default, or completely missing, in the affected versions (see workarounds). Impact If an attacker can control a script that is executed in the victim's browser, then they can typically fully compromise that user. Amongst other things, the attacker can: 1. Perform any action within the application that the user can perform. 2. View any information that the user is able to view. 3. Modify any information that the user is able to modify. 4. Initiate interactions with other application users, including malicious attacks, that will appear to originate from the initial victim user. Workarounds Changing any of the following WMS service settings should mitigate…
Recommended action: Upgrade to 2.25.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
GeoServer Web Feature Service (WFS) web service was found to be vulnerable to GeoTools CVE-2025-30220 XML External Entity (XXE) processing attack. It is possible to trigger the parsing of external DTDs and entities, bypassing standard entity resolvers. This allows for Out-of-Band (OOB) data exfiltration of local files accessible by the GeoServer process, and Service Side Request Forgery (SSRF). Details While direct entity resolution is managed by application property ENTITYRESOLUTIONALLOWLIST for XML Parsing, this restriction was not being used by the GeoTools library when building an in-memory XSD Library Schema representation. This bypasses GeoServer's AllowListEntityResolver enabling XXE attacks. PoC No public PoC is provided but this vulnerability has been confirmed to be exploitable through WFS service. Impact Information Disclosure: This vulnerability allows unauthenticated attackers to read arbitrary files from the server's filesystem that are accessible to the…
Recommended action: Upgrade to 2.27.1, 2.26.3 or 2.25.7 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Malicious Jiffle scripts can be executed by GeoServer, either as a rendering transformation in WMS dynamic styles or as a WPS process, that can enter an infinite loop to trigger denial of service. Details The Jiffle language supports multiple loop constructs that will cause its code block to be continuously executed until a certain condition is met. The Jiffle runtime should be updated to throw an exception if the script exceeds a certain number of loop iterations. Impact This vulnerability allows attackers to conduct denial-of-service attacks. Mitigation This vulnerability can be mitigated by disabling WMS dynamic styling (see WMS Settings). If the WPS extension is installed, the Jiffle process must also be disabled to mitigate this vulnerability (see WPS Settings) References https://github.com/geosolutions-it/jai-ext/pull/307 https://osgeo-org.atlassian.net/browse/GEOS-11778
Recommended action: Upgrade to 2.26.3 or 2.25.7 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
It is possible to bypass the default REST API security and access the index page. Details The REST API security handles rest and its subpaths but not rest with an extension (e.g., rest.html). Impact The REST API index can disclose whether certain extensions are installed. Workaround In ${GEOSERVERDATADIR}/security/config.xml, change the paths for the rest filter to /rest.,/rest/ and change the paths for the gwc filter to /gwc/rest.,/gwc/rest/ and restart GeoServer. References https://osgeo-org.atlassian.net/browse/GEOS-11664 https://osgeo-org.atlassian.net/browse/GEOS-11776 https://github.com/geoserver/geoserver/pull/8170
Recommended action: Upgrade to 2.26.3 or 2.25.6 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The Coverage rest api /workspaces/{workspaceName}/coveragestores/{storeName}/{method}.{format} allow to upload file with a specified url (with {method} equals 'url') with no restrict. Details The Coverage rest api /workspaces/{workspaceName}/coveragestores/{storeName}/{method}.{format} allow to upload file with a specified url (with {method} equals 'url'). But this url has not been check with URL Checks feature. For example, should add the code below to check fileURL: The vulnerable code was RESTUtils.java Impact This vulnerability presents the opportunity for Server Side Request Forgery. References - https://osgeo-org.atlassian.net/browse/GEOS-11468 - https://osgeo-org.atlassian.net/browse/GEOS-11717
Recommended action: Upgrade to 2.26.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The GeoWebCache home page includes version and revision information about the software in use. This information is sensitive from a security point of view because it allows software used by the server to be easily identified. Details org.geowebcache.GeoWebCacheDispatcher.handleFrontPage(HttpServletRequest, HttpServletResponse) has no check to hide potentially sensitive information from users except for a hidden system property to hide the storage locations that defaults to showing the locations. PoC Just open http://localhost:8080/geoserver/gwc/ Impact In addition to exposing the version and revision information, the home page will expose the config file and storage locations which may expose the system's temp directory location and whether or not GeoServer is running in a Windows operating system. The approximate server start time and some basic GWC usage information is also exposed. References https://osgeo-org.atlassian.net/browse/GEOS-11677…
Recommended action: Upgrade to 2.26.2 or 2.25.6 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An improper URI validation vulnerability exists that enables an unauthorized attacker to perform XML External Entities (XEE) attack, then send GET request to any HTTP server. Attacker can abuse this to scan internal networks and gain information about them then exploit further. Moreover, attacker can read limited .xsd file on system. Details By default, GeoServer use PreventLocalEntityResolver class from GeoTools to filter out malicious URIs in XML entities before resolving them. The URI must match the regex (?i)(jar:file|http|vfs)[^?#;]\\.xsd. But the regex leaves a chance for attackers to request to any HTTP server or limited file. Impact An unauthenticated attacker can: 1. Scan internal network to gain insight about it and exploit further. 2. SSRF to endpoint ends with .xsd. 3. Read limited .xsd file on system. Mitigation 1. Define the system property ENTITYRESOLUTIONALLOWLIST to limit the supported external schema locaitons. 2. The built-in allow list covers the locations…
Recommended action: Upgrade to 2.25.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The welcome and about page includes version and revision information about the software in use (including library and components used). This information is sensitive from a security point of view because it allows software used by the server to be easily identified. Proof of Concept 1. Welcome page footer: <img width="432" alt="image" src="https://github.com/geoserver/geoserver/assets/629681/a7fd5151-55d5-432b-9d5d-79136833609f" 2. About page build information. <img width="401" alt="image" src="https://github.com/geoserver/geoserver/assets/629681/59fcd8dd-eaee-4bf8-9578-a2a94b2864db" Patches No patch presently available. Workarounds No workaround available, although the ADMINCONSOLE can be disabled completely. References About GeoServer
Recommended action: Upgrade to 2.25.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Multiple OGC request parameters allow Remote Code Execution (RCE) by unauthenticated users through specially crafted input against a default GeoServer installation due to unsafely evaluating property names as XPath expressions. Details The GeoTools library API that GeoServer calls evaluates property/attribute names for feature types in a way that unsafely passes them to the commons-jxpath library which can execute arbitrary code when evaluating XPath expressions. This XPath evaluation is intended to be used only by complex feature types (i.e., Application Schema data stores) but is incorrectly being applied to simple feature types as well which makes this vulnerability apply to ALL GeoServer instances. PoC No public PoC is provided but this vulnerability has been confirmed to be exploitable through WFS GetFeature, WFS GetPropertyValue, WMS GetMap, WMS GetFeatureInfo, WMS GetLegendGraphic and WPS Execute requests. Impact This vulnerability can lead to executing arbitrary code.…
Recommended action: Upgrade to 2.25.2, 2.24.4, 2.23.6 or 2.22.6 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact If GeoServer is deployed in the Windows operating system using an Apache Tomcat web application server, it is possible to bypass existing input validation in the GeoWebCache ByteStreamController class and read arbitrary classpath resources with specific file name extensions. If GeoServer is also deployed as a web archive using the data directory embedded in the geoserver.war file (rather than an external data directory), it will likely be possible to read specific resources to gain administrator privileges. However, it is very unlikely that production environments will be using the embedded data directory since, depending on how GeoServer is deployed, it will be erased and re-installed (which would also reset to the default password) either every time the server restarts or every time a new GeoServer WAR is installed and is therefore difficult to maintain. An external data directory will always be used if GeoServer is running in standalone mode (via an installer or a binary).…
Recommended action: Upgrade to 2.24.3 or 2.23.5 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
GeoServer's Server Status page and REST API (at /geoserver/rest/about/status) lists all environment variables and Java properties to any GeoServer user with administrative rights as part of those modules' status message. These variables/properties can also contain sensitive information, such as database passwords or API keys/tokens, for example: Data stores defined with [parameterized catalog settings][catalog] (-DALLOWENVPARAMETRIZATION=true) which need a password or access key. GeoServer's official Docker image [uses environment variables to configure PostgreSQL JNDI resources, including credentials][docker-jndi] (POSTGRESHOST, POSTGRESUSERNAME, POSTGRESPASSWORD) Additionally, many community-developed GeoServer container images export other credentials from their start-up scripts as environment variables to the GeoServer (java) process, such as: GeoServer admin and master (root) passwords Tomcat management application password HTTPS/TLS certificate key store password AWS S3 bucket…
Recommended action: Upgrade to 2.25.1 or 2.24.4 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The WMS specification defines an sld=<url parameter for GetMap, GetLegendGraphic and GetFeatureInfo operations for user supplied "dynamic styling". Enabling the use of dynamic styles, without also configuring URL checks, provides the opportunity for Service Side Request Forgery. It is possible to use this for "Blind SSRF" on the WMS endpoint to steal NetNTLMv2 hashes via file requests to malicious servers. Details This vulnerability requires: WMS Settings dynamic styling being enabled Security URL checks to be disabled, or to be enabled and allowing file:\\ access Impact This vulnerability can be used to steal user NetNTLMv2 hashes which could be relayed or cracked externally to gain further access. Mitigation The ability to reference an external URL location is defined by the WMS standard GetMap, GetFeatureInfo and GetLegendGraphic operations. These operations are defined by an Industry and International standard and cannot be redefined by the GeoServer application in…
Recommended action: Upgrade to 2.23.2 or 2.22.5 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.