ghsa

Roles for system users are stored as generic `Ident` values and converted as strings and into the `Role` enum whenever IAM operations are to be performed that require processing the user roles. This conversion expects those identifiers to only contain the values `owner`, `editor` and `viewer` and will return an error otherwise. However, the `unwrap()` method would be called on this result when implementing `std::convert::From<&Ident> for Role`, which would result in a panic where a nonexistent role was used. ### Impact A privileged user with the `owner` role at any level in SurrealDB would be able to define a user with `DEFINE USER` with an nonexistent role, which would panic when being converted to a `Role` enum in order to perform certain IAM operations with that user. These operations included signing in with the user. This would crash the server, leading to denial of service. ### Patches Unexistent roles are no longer accepted during parsing when defining a user. Even when succ...

The `rand::time()` function in SurrealQL generates a random time from an optional range of two Unix timestamps. Due to the underlying use of `timestamp_opt` from the `chrono` crate, this function could potentially return `None` in some instances, leading to a panic when `unwrap` was called on its result in order to return a SurrealQL `datetime` type to the caller of the function. ### Impact A client that is authorized to run queries in a SurrealDB server would be able to make repeated (in the order of millions) calls to `rand::time()` in order to reliably trigger a panic. This would crash the server, leading to denial of service. ### Patches The function has been updated in to guarantee that some `datetime` is returned or that an error is otherwise gracefully handled. - Version 2.1.0 and later are not affected by this issue. ### Workarounds Affected users who are unable to update may want to limit the ability of untrusted clients to run the `rand::time()` function in the affecte...

### Impact One powerful feature of SFTPGo is the ability to have the EventManager execute scripts or run applications in response to certain events. This feature is very common in all software similar to SFTPGo and is generally unrestricted. However, any SFTPGo administrator with permission to run a script has access to the underlying OS/container with the same permissions as the user running SFTPGo. This is unexpected for some SFTPGo administrators who think that there is a clear distinction between accessing the system shell and accessing the SFTPGo WebAdmin UI. ### Patches To avoid this confusion, running system commands is now disabled by default, and an allow list has been added so that system administrators configuring SFTPGo must explicitly define which commands are allowed to be configured from the WebAdmin UI. https://github.com/drakkan/sftpgo/commit/88b1850b5806eee81150873d4e565144b21021fb https://github.com/drakkan/sftpgo/commit/b524da11e9466d05fe03304713ee1c61bb276ec...

### Summary A server side request forgery vuln was found within geonode when testing on a bug bounty program. Server side request forgery allows a user to request information on the internal service/services. ### Details The endpoint /proxy/?url= does not properly protect against SSRF. when using the following format you can request internal hosts and display data. /proxy/?url=http://169.254.169.254\@whitelistedIPhere. This will state wether the AWS internal IP is alive. If you get a 404, the host is alive. A non alive host will not display a response. To display metadata, use a hashfrag on the url /proxy/?url=http://169.254.169.254\@#whitelisteddomain.com or try /proxy/?url=http://169.254.169.254\@%23whitelisteddomain.com ### Impact Port scan internal hosts, and request information from internal hosts.

### Impact Flowise allows developers to inject configuration into the Chainflow during execution through the `overrideConfig` option. This is supported in both the frontend web integration and the backend Prediction API. This has a range of fundamental issues that are a **major** security vulnerability. While this feature is intentional, it should have strong protections added and be disabled by default. These issues include: 1. Remote code execution. While inside a sandbox this allows for 1. Sandbox escape 2. DoS by crashing the server 3. SSRF 2. Prompt Injection, both System and User 1. Full control over LLM prompts 2. Server variable and data exfiltration And many many more such as altering the flow of a conversation, prompt exfiltration via LLM proxying etc. These issues are self-targeted and do not persist to other users but do leave the server and business exposed. All issues are shown with the API but also work with the web embed. ### Workarounds - `overrideC...

## Summary A critical remote OS command injection vulnerability has been identified in the Llama Factory training process. This vulnerability arises from improper handling of user input, allowing malicious actors to execute arbitrary OS commands on the host system. The issue is caused by insecure usage of the `Popen` function with `shell=True`, coupled with unsanitized user input. Immediate remediation is required to mitigate the risk. ## Affected Version Llama Factory versions **<=0.9.0** are affected by this vulnerability. ## Impact Exploitation of this vulnerability allows attackers to: 1. Execute arbitrary OS commands on the server. 2. Potentially compromise sensitive data or escalate privileges. 3. Deploy malware or create persistent backdoors in the system. This significantly increases the risk of data breaches and operational disruption. ## Root Cause The vulnerability originates from the training process where the `output_dir` value, obtained from the user input, is in...

### Impact First noticed in Opencast 13 and 14, Opencast's Elasticsearch integration may generate syntactically invalid Elasticsearch queries in relation to previously acceptable search queries. From Opencast version 11.4 and newer, Elasticsearch queries are retried a configurable number of times in the case of error to handle temporary losses of connection to Elasticsearch. These invalid queries would fail, causing the retry mechanism to begin requerying with the same syntactically invalid query immediately, in an infinite loop. This causes a massive increase in log size which can in some cases cause a denial of service due to disk exhaustion. ### Patches Opencast 13.10 and Opencast 14.3 contain patches (https://github.com/opencast/opencast/pull/5150, and https://github.com/opencast/opencast/pull/5033) which address the base issue, with Opencast 16.7 containing changes which harmonize the search behaviour between the admin UI and external API. Users are strongly recommended to up...

### Summary Litestar offers multiple methods to return a parsed representation of the request body, as well as extractors that rely on those parsers to map request content to structured data types. Multiple of those parsers do not have size limits when reading the request body into memory, which allows an attacker to cause excessive memory consumption on the server by sending large requests. ### Details The `Request` methods to parse json, msgpack or form-data all read the entire request stream into memory via `await self.body()` without a prior size check or size limit. There may be other places (e.g. extractors) where this can happen. For most formats, a configurable size limit would be sufficient to mitigate this issue. The total request size can also be limited by a proxy (e.g. nginx) in front of the actual application as a workaround. However, for applications that actually want to accept large file uploads via `multipart/form-data`, a simple size limit would not be practical. T...

Querydsl 5.1.0 allows SQL/HQL injection in orderBy in JPAQuery.

### Impact cert-manager packages which call the standard library `pem.Decode()` function can take a long time to process specially crafted invalid PEM data. If an attacker is able to modify PEM data which cert-manager reads (e.g. in a Secret resource), they may be able to use large amounts of CPU in the cert-manager controller pod to effectively create a denial-of-service (DoS) vector for cert-manager in the cluster. Secrets are limited in size to [1MiB](https://kubernetes.io/docs/concepts/configuration/secret/#restriction-data-size), which reduces the impact of this issue; it was discovered through an ~856kB fuzz test input which causes `pem.Decode` to take roughly 750ms to reject the input on an M2 Max Macbook Pro. By way of comparison, a valid PEM-encoded 4096-bit RSA key takes roughly 70µs to parse on the same machine. Given the required size of PEM data needed to present a realistic DoS vector, an attacker would need to create or insert many different large sized resources in...