ghsa

### Summary An arbitrary file renaming vulnerability exists that enables an authenticated administrator with permissions to modify stores through the REST Coverage Store or Data Store API to rename arbitrary files and directories with a name that does not end in ".zip". ### Details Store file uploads rename zip files to have a ".zip" extension if it doesn't already have one before unzipping the file. This is fine for file and url upload methods where the files will be in a specific subdirectory of the data directory but, when using the external upload method, this allows arbitrary files and directories to be renamed. ### PoC Coverage Store Example (workspace and store name are irrelevant and any valid coverage format can be used): curl -XPUT -H"Content-Type:application/zip" -u"admin:geoserver" -d"/file/to/move" "http://localhost:8080/geoserver/rest/workspaces/a/coveragestores/b/external.geotiff" Data Store Example (workspace and store name and data store format are irrelevant): curl...

### Summary A stored cross-site scripting (XSS) vulnerability exists that enables an authenticated administrator with workspace-level privileges to store a JavaScript payload in uploaded style/legend resources that will execute in the context of another administrator's browser when viewed in the REST Resources API. Access to the REST Resources API is limited to full administrators by default and granting non-administrators access to this endpoint should be carefully considered as it may allow access to files containing sensitive information. ### Details Upload a new Legend via the New Style page if user has permissions for this. This file is then not checked and is uploaded to the backend system. This file can then be viewed directly by requesting it via the API which will then view the file in its raw format without sanitisation.  ![image](https://user-images.githubusercont...

### Summary An arbitrary file upload vulnerability exists that enables an authenticated administrator with permissions to modify coverage stores through the REST Coverage Store API to upload arbitrary file contents to arbitrary file locations which can lead to remote code execution. ### Details Coverage stores that are configured using relative paths use a GeoServer Resource implementation that has validation to prevent path traversal but coverage stores that are configured using absolute paths use a different Resource implementation that does not prevent path traversal. ### PoC Step 1 (create sample coverage store): curl -vXPUT -H"Content-type:application/zip" -u"admin:geoserver" --data-binary @polyphemus.zip "http://localhost:8080/geoserver/rest/workspaces/sf/coveragestores/filewrite/file.imagemosaic" Step 2 (switch store to absolute URL): curl -vXPUT -H"Content-Type:application/xml" -u"admin:geoserver" -d"<coverageStore><url>file:///{absolute path to data directory}/data/sf/filewr...

### Impact This vulnerability requires GeoServer Administrator with access to the admin console to misconfigured the **Global Settings** for **log file location** to an arbitrary location. This can be used to read files via the admin console **GeoServer Logs** page. It is also possible to leverage RCE or cause denial of service by overwriting key GeoServer files. ### Patches As this issue requires GeoServer administrators access, often representing a trusted party, the vulnerability has not yet attracted a volunteer or resources. Interested parties are welcome to contact [email protected] for recommendations on developing a fix. ### Workarounds A system administrator responsible for running GeoServer can define the ``GEOSERVER_LOG_FILE`` parameter, preventing the global setting provided from being used. The ``GEOSERVER_LOG_LOCATION`` parameter can be set as system property, environment variable, or servlet context parameter. Environmental variable: ```bash e...

### Impact Calling an invalid Parse Server Cloud Function name or Cloud Job name crashes server and may allow for code injection. ### Patches Added string sanitation for Cloud Function name and Cloud Job name. ### Workarounds Sanitize the Cloud Function name and Cloud Job name before it reaches Parse Server. ### References - https://github.com/parse-community/parse-server/security/advisories/GHSA-6hh7-46r2-vf29 - https://github.com/parse-community/parse-server/releases/tag/7.0.0-alpha.29 (Fix for Parse Server 7 alpha) - https://github.com/parse-community/parse-server/releases/tag/6.5.5 (Fix for Parse Server 6 LTS)

### Impact Users running containers with root privileges allowing a container to run with read/write access to the host system files when selinux is not enabled. With selinux enabled, some read access is allowed. ### Patches From @nalind ``` # cat /root/cve-2024-1753.diff --- internal/volumes/volumes.go +++ internal/volumes/volumes.go @@ -11,6 +11,7 @@ import ( "errors" + "github.com/containers/buildah/copier" "github.com/containers/buildah/define" "github.com/containers/buildah/internal" internalParse "github.com/containers/buildah/internal/parse" @@ -189,7 +190,11 @@ func GetBindMount(ctx *types.SystemContext, args []string, contextDir string, st // buildkit parity: support absolute path for sources from current build context if contextDir != "" { // path should be /contextDir/specified path - newMount.Source = filepath.Join(contextDir, filepath.Clean(string(filepath.Separator)+newMount.Source)) + evaluated, err := copier.Eval(contextDir, newMount.Source, cop...

An error in the evaluation of the fetch metadata headers could allow a bypass of the CSRF protection in Apache Wicket. This issue affects Apache Wicket: from 9.1.0 through 9.16.0, and the milestone releases for the 10.0 series. Apache Wicket 8.x does not support CSRF protection via the fetch metadata headers and as such is not affected. Users are recommended to upgrade to version 9.17.0 or 10.0.0, which fixes the issue.

Improper Input Validation vulnerability in Apache Hop Engine. This issue affects Apache Hop Engine: before 2.8.0. Users are recommended to upgrade to version 2.8.0, which fixes the issue. When Hop Server writes links to the PrepareExecutionPipelineServlet page one of the parameters provided to the user was not properly escaped. The variable not properly escaped is the "id", which is not directly accessible by users creating pipelines making the risk of exploiting this low. This issue only affects users using the Hop Server component and does not directly affect the client.

Versions of the package livewire/livewire from 3.3.5 and before 3.4.9 are vulnerable to Cross-site Scripting (XSS) when a page uses [Url] for a property. An attacker can inject HTML code in the context of the user's browser session by crafting a malicious link and convincing the user to click on it.

Versions of the package black before 24.3.0 are vulnerable to Regular Expression Denial of Service (ReDoS) via the lines_with_leading_tabs_expanded function in the strings.py file. An attacker could exploit this vulnerability by crafting a malicious input that causes a denial of service. Exploiting this vulnerability is possible when running Black on untrusted input, or if you habitually put thousands of leading tab characters in your docstrings.