ghsa

### Summary 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](https://docs.geoserver.org/latest/en/user/services/wms/webadmin.html#disabling-usage-of-dynamic-styling-in-getmap-getfeatureinfo-and-getlegendgraphic-requests)). If the WPS extension is installed, the Jiffle process must also be disabled to mitigate this vulnerability (see [WPS Settings](https://docs.geoserver.org/latest...

### Summary 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 `${GEOSERVER_DATA_DIR}/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

Erxes <1.6.1 is vulnerable to Incorrect Access Control. An attacker can bypass authentication by providing a "User" HTTP header that contains any user, allowing them to talk to any GraphQL endpoint.

In Erxes <1.6.2, an authenticated attacker can write to arbitrary files on the system using a Path Traversal vulnerability in the importHistoriesCreate GraphQL mutation handler.

In Erxes <1.6.2, an unauthenticated attacker can read arbitrary files from the system using a Path Traversal vulnerability in the /read-file endpoint handler.

### Summary 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](https://docs.geoserver.org/latest/en/user/security/urlchecks.html#url-checks). For example, should add the code below to check fileURL: ```java URLCheckers.confirm(fileURL) ``` The vulnerable code was [RESTUtils.java](https://github.com/geoserver/geoserver/blob/main/src/rest/src/main/java/org/geoserver/rest/util/RESTUtils.java#L176) ### 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

### Summary 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 https://g...

### Summary 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 ``ENTITY_RESOLUTION_ALLOWLIST`` to limit the supported external schema locaitons. 2. The buil...

### Summary It possible to achieve Service Side Request Forgery (SSRF) via the Demo request endpoint if Proxy Base URL has not been set. ### Details A unauthenticated user can supply a request that will be issued by the server. This can be used to enumerate internal networks and also in the case of cloud instances can be used to obtain sensitive data. ### Mitigation 1. When using GeoServer with a proxy, manage the proxy base value as a system administrator, use the application property ``PROXY_BASE_URL`` to provide a non-empty value that cannot be overridden by the user interface or incoming request. 2. When using GeoServer directly without a proxy, block all access to TestWfsPost by editing the web.xml file. Adding this block right before the end: ```xml <security-constraint> <web-resource-collection> <web-resource-name>BlockDemoRequests</web-resource-name> <url-pattern>/TestWfsPost/*</url-pattern> </web-resource-coll...

A possible security vulnerability has been identified in Apache Kafka. This requires access to a alterConfig to the cluster resource, or Kafka Connect worker, and the ability to create/modify connectors on it with an arbitrary Kafka client SASL JAAS config and a SASL-based security protocol, which has been possible on Kafka clusters since Apache Kafka 2.0.0 (Kafka Connect 2.3.0). When configuring the broker via config file or AlterConfig command, or connector via the Kafka Kafka Connect REST API, an authenticated operator can set the `sasl.jaas.config` property for any of the connector's Kafka clients to "com.sun.security.auth.module.LdapLoginModule", which can be done via the `producer.override.sasl.jaas.config`, `consumer.override.sasl.jaas.config`, or `admin.override.sasl.jaas.config` properties. This will allow the server to connect to the attacker's LDAP server and deserialize the LDAP response, which the attacker can use to execute java deserialization gadget chains on the Kafka ...