ghsa

### Summary The app uses sha-256 as the hash for passwords. The app should switch to bcrypt. ### Details SHA-256 is a message digest hash, and not classified as secure for password hashing. Message digest hashes are designed to be fast, while password hashing mechanisms are designed with certain cryptographic properties (e.g. slow) to protect against vulnerabilities. Refer to the links below for more information: - https://security.stackexchange.com/questions/195563/why-is-sha-256-not-good-for-passwords - https://stackoverflow.com/questions/11624372/best-practice-for-hashing-passwords-sha256-or-sha512 - https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#pre-hashing-passwords-with-bcrypt ### PoC N/A ### Impact It leaves users susceptible to rainbow table attacks

An information disclosure vulnerability exists in open-webui version 0.3.8. The vulnerability is related to the embedding model update feature under admin settings. When a user updates the model path, the system checks if the file exists and provides different error messages based on the existence and configuration of the file. This behavior allows an attacker to enumerate file names and traverse directories by observing the error messages, leading to potential exposure of sensitive information.

An Insecure Direct Object Reference (IDOR) vulnerability exists in open-webui/open-webui version v0.3.8. The vulnerability occurs in the API endpoint `http://0.0.0.0:3000/api/v1/memories/{id}/update`, where the decentralization design is flawed, allowing attackers to edit other users' memories without proper authorization.

In version v0.3.8 of open-webui/open-webui, the endpoint /api/pipelines/upload is vulnerable to arbitrary file write and delete due to unsanitized file.filename concatenation with CACHE_DIR. This vulnerability allows attackers to overwrite and delete system files, potentially leading to remote code execution.

### Impact Under certain concurrent event orderings, a `wasmtime::Engine`'s internal type registry was susceptible to double-unregistration bugs due to a race condition, leading to panics and potentially type registry corruption. That registry corruption could, following an additional and particular sequence of concurrent events, lead to violations of WebAssembly's control-flow integrity (CFI) and type safety. Users that do not use `wasmtime::Engine` across multiple threads are not affected. Users that only create new modules across threads over time are additionally not affected. Reproducing this bug requires creating and dropping multiple type instances (such as `wasmtime::FuncType` or `wasmtime::ArrayType`) concurrently on multiple threads, where all types are associated with the same `wasmtime::Engine`. **Wasm guests cannot trigger this bug.** See the "References" section below for a list of Wasmtime types-related APIs that are affected. Wasmtime maintains an internal registry o...

### Impact Wasmtime's implementation of WebAssembly tail calls combined with stack traces can result in a runtime crash in certain WebAssembly modules. The runtime crash may be undefined behavior if Wasmtime was compiled with Rust 1.80 or prior. The runtime crash is a deterministic process abort when Wasmtime is compiled with Rust 1.81 and later. [WebAssembly tail calls](https://github.com/webassembly/tail-call) are a proposal which relatively recently reached stage 4 in the [standardization process](https://github.com/WebAssembly/proposals/). Wasmtime first enabled support for tail calls by default [in Wasmtime 21.0.0](https://github.com/bytecodealliance/wasmtime/pull/8540), although that release contained a bug where it was only on-by-default for some configurations. In [Wasmtime 22.0.0](https://github.com/bytecodealliance/wasmtime/pull/8682) tail calls were enabled by default for all configurations. The specific crash happens when an exported function in a WebAssembly module (or ...

A vulnerability was found in Buildah. Cache mounts do not properly validate that user-specified paths for the cache are within our cache directory, allowing a `RUN` instruction in a Container file to mount an arbitrary directory from the host (read/write) into the container as long as those files can be accessed by the user running Buildah.

The `heap-buffer-overflow` is triggered in the `strlen()` function when handling the `c_chars_to_str` function in the dbn crate. This vulnerability occurs because the `CStr::from_ptr()` function in Rust assumes that the provided C string is null-terminated. However, there is no guarantee that the input chars array passed to the c_chars_to_str function is properly null-terminated. If the chars array does not contain a null byte (\0), strlen() will continue to read beyond the bounds of the buffer in search of a null terminator. This results in an out-of-bounds memory read and can lead to a heap-buffer-overflow, potentially causing memory corruption or exposing sensitive information.

Improper Restriction of XML External Entity Reference ('XXE') vulnerability in Apache XML Graphics FOP. This issue affects Apache XML Graphics FOP: 2.9. Users are recommended to upgrade to version 2.10, which fixes the issue.

Due to the order in which permissions were processed, some statements, filters and computations could lead to leaking field values or record contents to users without the required permissions. This behavior could be triggered in different scenarios: - When performing a `SELECT` operation on a table, the values that would be returned were iterated over, field permissions would be validated and any unauthorized value would be removed from the result returned. However, performing a `SELECT VALUE` operation (e.g. `SELECT VALUE private FROM data`) would result in a non-iterable value, which would not be removed from the returned result. - When aliasing a field (e.g. `SELECT private AS public FROM data`) for which the user did not have `SELECT` permissions within a `SELECT` query, permissions would be checked against the field of the resulting document containing the aliased field instead of the original document containing the original field. As a consequence, the original field value wou...