Source
ghsa
### 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: ![image](https://github.com/user-attachments/assets/08ba940e-33a8-408d-9a1e-9cd1504b95c5) ### 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...
A flaw was found in Feedback. Bulk messaging in the activity's non-respondents report did not verify message recipients belonging to the set of users returned by the report.
The bulk message sending feature in Moodle's Feedback module's non-respondents report had an incorrect CSRF token check, leading to a CSRF vulnerability.
A flaw was found in moodle. A local file may include risks when restoring block backups.
To address a cache poisoning risk in Moodle, additional validation for local storage was required.
A flaw was found in pdfTeX. Insufficient sanitizing in the TeX notation filter resulted in an arbitrary file read risk on sites where pdfTeX is available, such as those with TeX Live installed.
A flaw was found in Moodle. Additional restrictions are required to avoid a remote code execution risk in calculated question types. Note: This requires the capability to add/update questions.
A vulnerability was found in Moodle. Insufficient capability checks made it possible to delete badges that a user does not have permission to access.