ghsa

### Impact When uploading an attachment with a malicious filename, malicious JavaScript code could be executed. This requires a social engineering attack to get the victim into uploading a file with a malicious name. The malicious code is solely executed during the upload and affects only the user uploading the attachment. While this allows performing actions in the name of that user, it seems unlikely that a user wouldn't notice the malicious filename while uploading the attachment. In order to reproduce, as any user, create a file named `"><img src=1 onerror=alert(1)>.jpg`. Then go to any page where you have edit rights and upload the file in the attachments tab. If alerts appear and display "1", then the instance is vulnerable. ### Patches This has been patched in XWiki 14.10.21, 15.5.5, 15.10.6 and 16.0.0. ### Workarounds We're not aware of any workaround except upgrading. ### References * https://jira.xwiki.org/browse/XWIKI-19611 * https://jira.xwiki.org/browse/XWIKI-21769 * h...

### Impact When a user has edit but not view right on a page in XWiki, that user can delete the page and replace it by a page with new content without having delete right. The previous version of the page is moved into the recycle bin and can be restored from there by an admin. As the user is recorded as deleter, the user would in theory also be able to view the deleted content, but this is not directly possible as rights of the previous version are transferred to the new page and thus the user still doesn't have view right on the page. From all we examined, it therefore doesn't seem to be possible to exploit this to gain any rights. To reproduce, just replace `view` by `edit` in the URL of a page that you cannot view but edit and save. This should send the page to the recycle bin and replace it by an empty one if the XWiki installation is vulnerable. After the fix, an error is displayed when saving. ### Patches This has been patched in XWiki 14.10.21, 15.5.5 and 15.10.6 by cancelli...

Prototype Pollution in 75lb deep-merge 1.1.1 allows attackers to execute arbitrary code or cause a Denial of Service (DoS) and cause other impacts via merge methods of lodash to merge objects.

# Brief/Intro The typescript SDK has no awareness of to-be-spent transactions causing some transactions to fail or silently get pruned as they are funded with already used UTXOs. The `Typescript SDK` provides the `fund` function which retrieves `UTXOs`, which belong to the owner and can be used to fund the request in question, from fuel's graphql api. These then get added to the request making it possible to send it to the network as it now has inputs which can be spent by its outputs. Now this works when a user only wants to fund one transaction per block as in the next block, the spent UTXO will not exist anymore. However if a user wants to fund multiple transactions within one block, the following can happen: It is important to note, that the graphql API will return a random UTXO which has enough value to fund the transaction in question. - user has 2 spendable `UTXOs` in their wallet which can cover all expenses - user funds transaction `tA` with an input gotten from the API `i...

### Impact `array_ops.upper_bound` causes a segfault when not given a rank 2 tensor. ### Patches We have patched the issue in GitHub commit [915884fdf5df34aaedd00fc6ace33a2cfdefa586](https://github.com/tensorflow/tensorflow/commit/915884fdf5df34aaedd00fc6ace33a2cfdefa586). The fix will be included in TensorFlow 2.13. We will also cherrypick this commit in TensorFlow 2.12.1. ### For more information Please consult [our security guide](https://github.com/tensorflow/tensorflow/blob/master/SECURITY.md) for more information regarding the security model and how to contact us with issues and questions. ### Attribution This vulnerability has been reported by dmc1778

Studio 42 elFinder 2.1.64 is vulnerable to Incorrect Access Control. Copying files with an unauthorized extension between server directories allows an arbitrary attacker to expose secrets, perform RCE, etc.

### Summary Probably jwt bypass + sql injection or what i'm doing wrong? ### PoC (how to reproduce) 1. Create following files: docker-compose.yml: ``` services: postgres: image: postgres container_name: postgres_container_mre environment: POSTGRES_USER: test_user_pg POSTGRES_PASSWORD: test_pass_pg POSTGRES_DB: test_db prest: image: prest/prest build: . volumes: - ./queries:/queries - ./migrations:/migrations ports: - "3000:3000" ``` Dockerfile: ``` from prest/prest:latest COPY ./prest.toml prest.toml ``` prest.toml: ``` debug=false migrations = "./migrations" [http] port = 3000 [jwt] default = true key = "secret" algo = "HS256" [auth] enabled = true type = "body" encrypt = "MD5" table = "prest_users" username = "username" password = "password" [pg] URL = "postgresql://test_user_pg:test_pass_pg@postgres:5432/test_db/?sslmode=disable" [ssl] mode = "disable" sslcert = "./PATH" sslkey = "./PATH" sslrootcert = "....

### Summary Navigating to `/admin/index/statistics` with a **logged in Pimcore user** (not an XmlHttpRequest because of this check: [IndexController:125](https://github.com/pimcore/admin-ui-classic-bundle/blob/1.x/src/Controller/Admin/IndexController.php#L125C24-L125C40)) exposes information about the Pimcore installation, PHP version, MYSQL version, installed bundles and all database tables and their row count in the system. > The web server should not return any product and version information of the components used. The table names and row counts should not be exposed. ### Details `/admin/index/statistics` returns the following JSON-response: ``` { { "instanceId": "...", "pimcore_major_version": 11, "pimcore_version": "v11.3.1", "pimcore_hash": "3ecd39f21dbdd25ffdf4bec6e2c860eccfd3d008", "pimcore_platform_version": "v2024.2", "php_version": "8.3.8", "mysql_version": "10.11.8-MariaDB-ubu2204", "bundles": [ //...

A security vulnerability has been detected in certain versions of Docker Engine, which could allow an attacker to bypass [authorization plugins (AuthZ)](https://docs.docker.com/engine/extend/plugins_authorization/) under specific circumstances. The base likelihood of this being exploited is low. This advisory outlines the issue, identifies the affected versions, and provides remediation steps for impacted users. ### Impact Using a specially-crafted API request, an Engine API client could make the daemon forward the request or response to an [authorization plugin](https://docs.docker.com/engine/extend/plugins_authorization/) without the body. In certain circumstances, the authorization plugin may allow a request which it would have otherwise denied if the body had been forwarded to it. A security issue was discovered In 2018, where an attacker could bypass AuthZ plugins using a specially crafted API request. This could lead to unauthorized actions, including privilege escalation. A...

Web Authentication vulnerability in Apache SeaTunnel. Since the jwt key is hardcoded in the application, an attacker can forge any token to log in any user. Attacker can get secret key in /seatunnel-server/seatunnel-app/src/main/resources/application.yml and then create a token. This issue affects Apache SeaTunnel: 1.0.0. Users are recommended to upgrade to version 1.0.1, which fixes the issue.