Aatomical

**Name of the Vulnerable Software and Affected Versions** Stable Diffusion WebUI (affected versions not specified) **Description** The `is path trusted` function in `scripts/iib/api.py` improperly validates requested paths by using `path.startswith(parent path)` without appending a path separator. This allows access to directories that start with the same name as an allowed parent directory, such as accessing `/data/images private/secret.txt` when only `/data/images` is permitted. This flaw leads to unauthorized file disclosure via `FileResponse`. The issue affects network-exposed deployments where access control is enabled via `IIB ACCESS CONTROL` or when the host is started with `share`, `ngrok`, `listen`, or `server name` options. The `get enable access control` function in `scripts/iib/tool.py` determines if this confinement check is active. **Recommendations** Update the `is path trusted` function to compare the requested path against the `parent path` joined with `os.sep` to ensure proper directory confinement.

**Name of the Vulnerable Software and Affected Versions** Stable Diffusion WebUI (affected versions not specified) **Description** The `to abs path` function in `scripts/iib/tool.py` uses `os.path.normpath` to normalize requested paths. This method collapses dot segments but fails to resolve symbolic links. Consequently, a symlink placed within a scanned directory can bypass the containment check performed by the `is path trusted` function in `scripts/iib/api.py` while pointing to a location outside that directory. When `FileResponse` serves the response, it follows the link, potentially disclosing sensitive files such as `/etc/passwd`. This issue affects network-exposed deployments where access control is enabled via `IIB ACCESS CONTROL` or when the host is started with `share`, `ngrok`, `listen`, or `server name` options. **Recommendations** Update the software to a version where the `to abs path` function in `scripts/iib/tool.py` uses `os.path.realpath` to resolve paths.

**Name of the Vulnerable Software and Affected Versions** LMDeploy (affected versions not specified) **Description** LMDeploy contains an issue where disaggregated-serving peer messages are deserialized using the pickle module. The `handle zmq recv` coroutine in `lmdeploy/pytorch/disagg/conn/engine conn.py` uses the `recv pyobj()` function to read peer-to-peer cache-free requests, which invokes `pickle.loads()` on the received bytes. Because the type check for `DistServeCacheFreeRequest` occurs only after deserialization, a remote attacker can exploit this by controlling the peer that supplies the bytes. The `p2p connect` function passes the `remote engine endpoint info.zmq address` from the request body to the ZMQ PULL socket. Furthermore, the endpoints 'POST /distserve/p2p initialize' and 'POST /distserve/p2p connect' in `lmdeploy/serve/openai/api server.py` do not require authentication by default. This allows an attacker to direct an engine to pull data from a malicious ZMQ endpoint and execute arbitrary code within the engine process. This issue only affects deployments with disaggregated serving enabled. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability. Start the server with `api keys` enabled to ensure authentication for the affected endpoints. Disable disaggregated serving if it is not required for the deployment.

**Name of the Vulnerable Software and Affected Versions** Open WebUI versions prior to 0.9.6 **Description** A path traversal issue exists in the cache file serving endpoint '/cache/{path:path}' that allows authenticated users with the role of `user` or `admin` to read files from sibling directories outside the intended cache directory. The problem occurs in the `serve cache file()` function within `open webui/main.py` due to an incomplete containment check using `startswith()` that lacks a trailing path separator. This allows any path resolving to a sibling directory whose name begins with the word cache (such as `cache sibling`, `cache backup`, or `cached models`) to pass validation. Deep traversal and absolute paths are correctly blocked. **Recommendations** Update to version 0.9.6. As a temporary workaround, restrict access to the '/cache/{path:path}' endpoint to only trusted administrative users until the update is applied.

**Name of the Vulnerable Software and Affected Versions** Ormar versions 0.9.9 through 0.22.0 **Description** Ormar is an async mini ORM for Python. Versions 0.9.9 through 0.22.0 are susceptible to a SQL injection flaw when performing aggregate queries. The `min()` and `max()` methods in the `QuerySet` class accept arbitrary string input as the column parameter without validation. This allows an attacker to embed raw SQL inside the aggregate function call, potentially enabling them to read the entire database content, including unrelated tables, by injecting a subquery. The vulnerability arises because `sqlalchemy.text()` is used to construct SQL expressions directly from user-supplied column names without sanitization. The `sum()` and `avg()` methods have partial protection with a type check, but `min()` and `max()` do not. The vulnerability was discovered through the ability to execute subqueries via the `min()` and `max()` aggregate functions. An attacker can enumerate database tables, extract schemas, and dump credentials without authentication. **Recommendations** Update to version 0.23.0 or later.