ghsa

During proof generation, the prover must observe all values sent to the verifier to generate valid Fiat-Shamir challenges. Prior to v3.0.0 the cumulative sum of the permutation argument was not observed when sampling zeta, which is a random challenge sampled to force the constraints to be true. In v3.0.0, this is fixed by observing the cumulative sum into the challenger, which can is done by observing the commit to the entire permutation trace. While this vulnerability is theoretically present in v2.0.0 and below, exploiting it is quite a difficult task as the cumulative sum one can get from manipulation is essentially random. It requires practically infeasible amount of computation and deep knowledge of cryptographic attacks to carry out. This issue was discovered during the audit of SP1 V3.0.0 and was officially fixed on October 17th. Out of abundance of caution, we will be deprecating all versions of SP1 before 3.0.0.

Airflow versions before 2.10.3 have a vulnerability that allows authenticated users with audit log access to see sensitive values in audit logs which they should not see. When sensitive variables were set via airflow CLI, values of those variables appeared in the audit log and were stored unencrypted in the Airflow database. While this risk is limited to users with audit log access, it is recommended to upgrade to Airflow 2.10.3 or a later version, which addresses this issue. Users who previously used the CLI to set secret variables should manually delete entries with those variables from the log table.

### Summary The validation for the file URI scheme falls short, and results in an attacker being able to read any file on the system. This issue only affects instances with a webdriver enabled, and `ALLOW_FILE_URI` false or not defined. ### Details The check used for URL protocol, `is_safe_url`, allows `file:` as a URL scheme: https://github.com/dgtlmoon/changedetection.io/blob/e0abf0b50507a8a3d0c1d8522ab23519b3e4cdf4/changedetectionio/model/Watch.py#L11-L13 It later checks if local files are permitted, but one of the preconditions for the check is that the URL starts with `file://`. The issue comes with the fact that the file URI scheme is not required to have double slashes. > A valid file URI must therefore begin with either `file:/path` (no hostname), `file:///path` (empty hostname), or `file://hostname/path`. > — [Wikipedia](https://en.wikipedia.org/wiki/File_URI_scheme#Number_of_slash_characters) https://github.com/dgtlmoon/changedetection.io/blob/e0abf0b50507a8a3d0c1d8522...

### Impact HTTP Clients created by `AddUserAccessTokenHttpClient` may use a different user's access token after a token refresh. This occurs because a refreshed token will be captured in pooled `HttpClient` instances, which may be used by a different user. ### Workarounds Instead of using `AddUserAccessTokenHttpClient` to create an `HttpClient` that automatically adds a managed token to outgoing requests, you can use the `HttpConext.GetUserAccessTokenAsync` extension method or the `IUserTokenManagementService.GetAccessTokenAsync` method. ### Patches This issue is fixed in Duende.AccessTokenManagement.OpenIdConnect 3.0.1.

### Impact The vulnerability may allow a remote attacker to terminate the application with a stack overflow error resulting in a denial of service only by manipulating the processed input stream when XStream is configured to use the BinaryStreamDriver. ### Patches XStream 1.4.21 detects the manipulation in the binary input stream causing the the stack overflow and raises an InputManipulationException instead. ### Workarounds The only solution is to catch the StackOverflowError in the client code calling XStream if XStream is configured to use the BinaryStreamDriver. ### References See full information about the nature of the vulnerability and the steps to reproduce it in XStream's documentation for [CVE-2024-47072](https://x-stream.github.io/CVE-2024-47072.html). ### Credits Alexis Challande of Trail Of Bits found and reported the issue to XStream and provided the required information to reproduce it.

Nomad Community and Nomad Enterprise ("Nomad") volume specification is vulnerable to arbitrary cross-namespace volume creation through unauthorized Container Storage Interface (CSI) volume writes. This vulnerability, identified as CVE-2024-10975, is fixed in Nomad Community Edition 1.9.2 and Nomad Enterprise 1.9.2, 1.8.7, and 1.7.15.

PHPExcel XXE Vulnerability

### Summary An authenticated user (with minimum permission) could utilize and exploit SQL Injection to allow the execution of malicious SQL queries via CreateUser API (/orchestrator/user). ### Details The API is CreateUser (/orchestrator/user). The function to read user input is: https://github.com/devtron-labs/devtron/blob/4296366ae288f3a67f87e547d2b946acbcd2dd65/api/auth/user/UserRestHandler.go#L96-L104 The userInfo (line 104) parameter can be controlled by users. The SQL injection can happen in the code: https://github.com/devtron-labs/devtron/blob/4296366ae288f3a67f87e547d2b946acbcd2dd65/pkg/auth/user/repository/UserAuthRepository.go#L1038 The query (line 1038) parameter can be controlled by a user to create and execute a malicious SQL query. The user should be authenticated but only needs minimum permissions:  ### PoC Demonstrate a blind SQL injection to retrieve the database name: `...

### Impact Specially crafted Git repositories can cause `jj` to write files outside the clone. ### Patches Fixed in 0.23.0. ### Workarounds Not much other than to not clone repositories from untrusted sources. ### References Here's the original report from @joernchen: > When cloning a crafted Git repository it is possible to let `jj` write > into arbitrary directories. This can be achieved by having file objects > which contain path traversals. > > Reproduction steps: > > Apply the following patch to Git version v.2.47.0: > > ```diff > diff --git a/path.c b/path.c > index 93491bab14..2f47e69fd1 100644 > --- a/path.c > +++ b/path.c > @@ -44,11 +44,11 @@ struct strbuf *get_pathname(void) > > static const char *cleanup_path(const char *path) > { > - /* Clean it up */ > + /* Clean it up > if (skip_prefix(path, "./", &path)) { > while (*path == '/') > path++; > - } > + }*/ > return path; > } > > ...

### Summary All Filament features that interact with storage use the `default_filesystem_disk` config option. This allows the user to easily swap their storage driver to something production-ready like `s3` when deploying their app, without having to touch multiple configuration options and potentially forgetting about some. The default disk is set to `public` when you first install Filament, since this allows users to quickly get started developing with a functional disk that allows features such as file upload previews locally without the need to set up an S3 disk with temporary URL support. However, some features of Filament such as exports also rely on storage, and the files that are stored contain data that should often not be public. This is not an issue for the many deployed applications, since many use a secure default disk such as S3 in production. However, [CWE-1188](https://cwe.mitre.org/data/definitions/1188.html) suggests that having the `public` disk as the default dis...