ghsa

### 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.

GraphQL Java (aka graphql-java) before 21.5 does not properly consider ExecutableNormalizedFields (ENFs) as part of preventing denial of service via introspection queries. 20.9 and 19.11 are also fixed versions.

A stored cross-site scripting (XSS) vulnerability exists in aimhubio/aim version 3.19.3. The vulnerability arises from the improper neutralization of input during web page generation, specifically in the logs-tab for runs. The terminal output logs are displayed using the `dangerouslySetInnerHTML` function in React, which is susceptible to XSS attacks. An attacker can exploit this vulnerability by injecting malicious scripts into the logs, which will be executed when a user views the logs-tab.

### Summary A ReDOS exists on currency.js was discovered by Gauss Security Labs R&D team. ### Details https://github.com/NaturalIntelligence/fast-xml-parser/blob/master/src/v5/valueParsers/currency.js#L10 contains a vulnerable regex ### PoC pass the following string '\t'.repeat(13337) + '.' ### Impact Denial of service during currency parsing in experimental version 5 of fast-xml-parser-library https://gauss-security.com

### Summary The `twisted.web.util.redirectTo` function contains an HTML injection vulnerability. If application code allows an attacker to control the redirect URL this vulnerability may result in Reflected Cross-Site Scripting (XSS) in the redirect response HTML body. ### Details Twisted’s `redirectTo` function generates an `HTTP 302 Redirect` response. The response contains an HTML body, built for exceptional cases where the browser doesn’t properly handle the redirect, allowing the user to click a link, navigating them to the specified destination. The function reflects the destination URL in the HTML body without any output encoding. ```python # https://github.com/twisted/twisted/blob/trunk/src/twisted/web/_template_util.py#L88 def redirectTo(URL: bytes, request: IRequest) -> bytes: # ---snip--- content = b""" <html> <head> <meta http-equiv=\"refresh\" content=\"0;URL=%(url)s\"> </head> <body bgcolor=\"#FFFFFF\" text=\"#000000\"> <a href=\"%(url)...

### Impact _What kind of vulnerability is it? Who is impacted?_ Low permission users using the "Set .dme Path" privilege could potentially set malicious .dme files existing on the host machine to be compiled and executed. These .dme files could be uploaded via tgstation-server (requiring a separate, isolated privilege) or some other means. A server configured to execute in BYOND's trusted security level (requiring a third separate, isolated privilege OR being set by another user) could lead to this escalating into remote code execution via BYOND's shell() proc. The ability to execute this kind of attack is a known side effect of having privileged TGS users, but normally requires multiple privileges with known weaknesses. This vector is not intentional as it does not require control over the where deployment code is sourced from and _may_ not require remote write access to an instance's `Configuration` directory. ### Patches _Has the problem been patched? What versions should user...

### Impact This XSS vulnerability is about the system configs * design/header/welcome * design/header/logo_src * design/header/logo_src_small * design/header/logo_alt They are intended to enable admins to set a text in the two cases, and to define an image url for the other two cases. But because of previously missing escaping allowed to input arbitrary html and as a consequence also arbitrary JavaScript. While this is in most usage scenarios not a relevant issue, some people work with more restrictive roles in the backend. Here the ability to inject JavaScript with these settings would be an unintended and unwanted privilege. ### Patches _Has the problem been patched? What versions should users upgrade to?_ The problem is patched with Version 20.10.1 or higher. ### Workarounds _Is there a way for users to fix or remediate the vulnerability without upgrading?_ Possible mitigations are * Restricting access to the System Configs * checking templates where these settings are u...